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

Published: 2005-04-28
Last Updated: 2005-04-29 10:43:57 UTC
by Robert Danford (Version: 1)
0 comment(s)

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
Keywords:
0 comment(s)

Comments


Diary Archives