SANS ISC: MS05-019 update troubleshooting; Practicing safe forwarding in BIND; 9999/TCP spike;TCPDump Buffer Overflows; MS05-020 POC Released;Spyware Lawsuit

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

MS05-019/Win2k3 SP1 Update Troubleshooting

More information is available regarding incompatibilities and gotchas after applying this update:

http://www.sans.org/newsletters/newsbites/newsbites.php?vol=7&issue=17#307


Also

http://support.microsoft.com/default.aspx?scid=898060

Safe Forwarding

From: http://www.isc.org/index.pl?/sw/bind/

BIND4/BIND8 Unsuitable for Forwarder Use

If a nameserver -- any nameserver, whether BIND or otherwise -- is
configured to use forwarders, then none of the the target forwarders
can be running BIND4 or BIND8. Upgrade all nameservers used as forwarders to BIND9 . There is a current, wide scale Kashpureff-style DNS cache corruption attack which depends on BIND4 and BIND8 as forwarders targets.

Very useful BIND security matrix illustrating what issues affect which versions of BIND:

http://www.isc.org/sw/bind/bind-security.php

Also be sure to check out the fine template from Team CYMRU:

http://www.cymru.com/Documents/secure-bind-template.html

UPDATE:

Thanks to Paul Vixie and others for re-articulating the forwarding issue more succinctly

If a poisonable dns server uses a nameserver as a forwarder 

it should NOT be Bind4/8.  Bind4/8 are not vulnerable to 

poisoning of the cache via the Kashpureff-style DNS cache 

corruption but will pass one poisoned record for a domain 

before cleaning its own cache.

  

So just to be clear its not the case that you can poison the 

later versions of Bind4/8 its that Bind 4/8 when acting as 

forwarders don't ensure there is no additional records in the 

first forwarding instance.

TCP Port 9999 spike?

http://dshield.org/port_report.php?port=9999

A number of spike reports for this port in recent days. Anyone have a good capture?

UPDATE:

It has been suggested that the spike may be related to the proof of concept exploit for MS05-020 referenced below. Does anyone have any data to back that up?

#define RATFILE "rsaci.rat"

unsigned char shellcode[] = { // spawn a Shell on port 9999

We have also had numerous folks mail in pointers to the MySQL MaxDB Webtool exploit (from cybertronic) which also references port 9999 as well as some firewall deny logs for port 9999, but no traffic captures. The mystery continues......

#define PORT	9999

Thanks to everyone for supporting distributed data collection and analysis effort.

UPDATE:

Our friends in Europe who are seeing the port 9999 spike have pointed out they are seeing an immediate connection attempt to port 4444 afterwards which lends credibility to this spike being related to the MaxDB Webtool exploit.

TCPDump Buffer Overflows

3.8/3.9 ISIS_PRINT

3.8     RT_ROUTING_INFO

3.8     LDP_PRINT

3.8/3.9 RSVP_PRINT (Ethereal also affected)

Privilege separation is your friend:

http://taosecurity.blogspot.com/2004/02/tcpdump-with-privilege-separation-in.html

MS05-020 POC Exploit Released by FrSIRT

As detailed here: http://www.frsirt.com/english/advisories/2005/0340

Spyware Lawsuit

My hero.

Spitzer Sues Intermix over Spyware

http://www.msnbc.msn.com/id/7666890/



Anyone have a good location bar spellchecker? If it doesn't check against a dictionary it could at least check against a database of sites previously visited.
If I typed google.com correctly 999 times correctly in the past its likely thats what I wanted this time I typed goofgle[dot]com

---------------

Robert Danford/Handler-on-duty