Steve
I'm a PC, so shut up
Consultant
join:2001-03-10
Yorba Linda, CA
| MSBLAST analysis thread
I figured I'd create a new thread to get the blow-by-blow analysis of this msblast thing. I have not followed much beyond digging into the binary (IDS Pro rocks!) but the findings are interesting.
Of particular note is that on 8/16, this worm will start attacking windowsupdate.com with random packets to 80/tcp. Still digging into the details of what's there, but it looks pretty aggressive.
The string "BILLY" is in the code: this is the name of a mutex that is used to keep more than one version running at a time.
More as I find it...
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
Link Logger
Premium,MVM
join:2001-03-29
Calgary, AB
 ·Shaw
| From »xforce.iss.net/xforce/alerts/id/150
-------------
The MS Blast worm propagates by exploiting the vulnerability described
in Microsoft Security Bulletin MS03-026, titled, "Buffer Overrun In RPC
Interface Could Allow Code Execution". The worm exhibits the following
behaviors:
Spawn a new thread, checks system clock and launches a TCP-based denial
of service attack at windowsupdate.com if the date is on or after
the 16th.
Add itself to registry so the worm restarts upon a reboot.
Initializes the attack vector for Windows 2000 or Windows XP based on a
simple mathematical calculation. Each infected instance will only attack
Windows XP or Windows 2000. One out of five worm infections will attack
windows 2000, and the remaining four will target Windows XP.
There is a 40% probability that the worm picks a random IP and then scans
sequentially from the starting point. There is a 60% probability that
the worm scans sequentially from its own IP address.
If a vulnerable machine is found, the exploit is launched and the newly
infected machine connects back to the scanning machine via TFTP to obtain
the worm binary. The binary is executed and the process begins again.
-------------
This explains where there appears to be more local system scanning you there non local.
Blake
--
»www.SonicLogger.com - Logging Software for SonicWall and 3Comhttp://www.LinkLogger.com - Logging Software for Linksys, Netgear and Zyxel |
|
Steve
I'm a PC, so shut up
Consultant
join:2001-03-10
Yorba Linda, CA
| reply to Steve
The code clearly does a DoS attack against windowsupdate.com, and I'm getting close to having the attack packet figured out:code:
IP Header
+--------+--------+-----------------+
|ver |hln| tos=0 | length=40 | ver=IPv4 hlen = hdr len
+--------+--------+-----------------+
| ID = 1 |f| frag=0 | f = flags (all zero)
+--------+--------+--------+--------+
|TTL=128 |proto=6 | header checksum | proto 6 = TCP
+--------+--------+-----------------+
| source IP address | (forged)
+-----------------------------------+
| dest IP (windowsupdate) |
+-----------------------------------+
TCP header
+-----------------+-----------------+
| source port | dst port = 80 | src port = 1000..1999
+-----------------+-----------------+
| seq = random | 0..0x7FFF
+-----------------+-----------------+
| ack = 0 |
+-----------------+-----------------+
|hl| |flags=SYN| wsize=16384 |
+-----------------+-----------------+
| tcp cksum | urg ptr = 0 |
+-----------------+-----------------+
I did find a bug in the code: the author was trying to get a random 32-bit sequence number, but ended up only getting 15 bits out of it (the ID will always be 0..0x7FFF). This is the second worm that I've analyzed that got the random number code confused.code:
tcphdr.seq = htons( (rand()<<16 | rand()) & 0xFFFF );
Memo to programmers: the MSVC random number generator generates only 15 bits of random data (e.g., "RAND_MAX" is 0x7FFF), so if you need more than that you have to do this differently. If I wanted 32 bits of more or less random data, I'd do it with:code:
value = rand() | ( rand()<<15 ) | ( rand()<<30 );
Steve
[text was edited by author 2003-08-11 20:38:23] |
|
Mark
Premium
join:2001-11-15
Mesa, AZ
| reply to Steve
Perhaps the same person wrote both the worms you've analyzed.
If I were Microsoft, I'd change the DNS of windowsupdate.com to a blackhole ip, or 127.0.0.1
One could still access it from windowsupdate.microsoft.com though. Just a thought.
I'm more worried about the traffic propagating will generate, though. |
|
groundling
join:2003-02-08
canada | reply to Steve
F-secure is calling it Lovsan alias msblast:
»www.f-secure.com/v-descs/msblast.shtml |
|
gameboyrom
join:2000-11-27
| reply to Steve
Considering the mutex, couldn't some one make a very easy tool to see if you are infected and then thwart future infections.
code:
CreateMutex(NULL,NULL,"BILLY");
if(GetLastError()==ERROR_ALREADY_EXISTS)
MessageBox(NULL,"You are infected, use this link: etc etc","Warning",0);
return 0;
The mutex should stay alive if the handle to it is not closed, so effectively those 4 lines of code should thwart the attack and detect if you have been infected.
--
-GBR :)
[text was edited by author 2003-08-11 21:59:47] |
|
Steve
I'm a PC, so shut up
Consultant
join:2001-03-10
Yorba Linda, CA
| said by gameboyrom  :
The mutex should stay alive if the handle to it is not closed, so effectively those 4 lines of code should thwart the attack and detect if you have been infected.
Not quite. Though this would keep any future worms from starting as long as the mutex is held, this test is made after the code that sets up the worm to run at system startup time. So you'd get hit on the next reboot.
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
gameboyrom
join:2000-11-27
| reply to Steve
Yes but it wouldn't be used in that respect. If you are detected, it would notify you and you could go about deleting it. Otherwise until your next restart the worm shouldn't technicaly harm you. I think I'm correct anyway 
--
-GBR  |
|
Steve
I'm a PC, so shut up
Consultant
join:2001-03-10
Yorba Linda, CA
| reply to Steve
The date-based code is just wierd:code:
char dateBufferMonth[4];
char dateBufferDay[4];
DWORD locale = MAKELANGID(LANG_ENGLISH, SUBLANG_DEFAULT);
GetDateFormat(locale, 0, 0, "d", dateBufferDay, 3);
GetDateFormat(locale, 0, 0, "M". dateBufferMonth, 3);
if ( atoi(dateBufferDay) > 15
|| atoi(dateBufferMonth) > 8 )
{
launch_windowsupdate_attack_thread();
}
start_RPC_infection();
Frankly, this just looks dumb, like a lot of the other code I see. This was not produced by any kind of strong C programmer at all.
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
lashmun
Premium
join:2002-12-14
Novi, MI
| reply to Steve
Deleted - posted in the wrong place - sorry
[text was edited by author 2003-08-11 22:48:16] |
|
Steve
I'm a PC, so shut up
Consultant
join:2001-03-10
Yorba Linda, CA
| reply to Steve
The code to blast windowsupdate.com sends 40 bytes of data (a forged SYN packet to 80/tcp), then sleeps for 20 milliseconds, a timing confirmed by psloss . This is 50 packets (or 8kbit) per second: this is not much from just one computer, but when you consider all the clueless people out there, it should be one hell of a flood.
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
Steve
I'm a PC, so shut up
Consultant
join:2001-03-10
Yorba Linda, CA
| reply to Steve
psloss is performing dynamic analysis -- running and watching the binary in a test environment -- while I'm performing static analysis (reverse engineering the binary), and we're seeing the same things.
The TCP source port is always in the range 1000 .. 1999.
The TCP sequence number is always 0xXXYY0000 where XX is 0..255 and YY is 0..127 (the result of the bad use of the random number generator)
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
pcdebb
RIP dadkins
Premium
join:2000-12-03
Tampa, FL
clubs: 
|  reply to Steve
steve, psloss, and others, you guys are doing a great job picking this apart. I'm trying to learn what I can with all these big words (SYN packets?)
my logs are totally silent (or i'm looking in the wrong place for my logs?) so i'm just sitting here bored atm
--
I want to die in my sleep like my grandfather...not screaming and yelling like the passengers in his car ... (posts) ... AIM ... |
|
Steve
I'm a PC, so shut up
Consultant
join:2001-03-10
Yorba Linda, CA
| said by pcdebb :
I'm trying to learn what I can with all these big words (SYN packets?)
The TCP protocol is fairly elaborate, and when it make a connection (such as when you hit a web page), the first packet is a "synchronize" (SYN) that tells the web server that you want to get things started.
It allocates resources for your connection and responds to your request, and there is a back-and-forth between your two computers to exchange the actual data on the web page.
But if bad-ware sends this "start a connection" packet and then abandons it, the web server is stuck with allocated resources that won't ever get used: it will fill up the current-connection table very quickly. This is a clear attempt to deny service.
There are plenty of techniques that can be used to combat this (time out connections that never got completed, for instance), but it's still a serious pain in the ass to deal with.
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
psloss
Premium
join:2002-02-24
Alpharetta, GA
| reply to Steve
Re: simulated winupdate flood packets
said by Steve :
The TCP source port is always in the range 1000 .. 1999.
The TCP sequence number is always 0xXXYY0000 where XX is 0..255 and YY is 0..127 (the result of the bad use of the random number generator)
Here is the text output from Ethereal for a couple of network frames. This was just an internal LAN test with systems with IPs in the 192.168.100.xxx range. I added line breaks for a couple of lines to keep the formatting.
Edit: in order to prod the worm into doing the TCP SYN packet "flood," I also added a hosts file entry for windowsupdate.com to point to the target system (192.168.100.21) and set the system clock forward to 17 August on the "infected" system:
Frame 856 (60 bytes on wire, 60 bytes captured)
Arrival Time: Aug 12, 2003 02:00:39.602922000
Time delta from previous packet: 0.020046000 seconds
Time relative to first packet: 18.705396000 seconds
Frame Number: 856
Packet Length: 60 bytes
Capture Length: 60 bytes
Ethernet II, Src: 00:10:4b:75:54:96, Dst: 00:03:47:d9:26:60
Destination: 00:03:47:d9:26:60 (Intel_d9:26:60)
Source: 00:10:4b:75:54:96 (3Com_75:54:96)
Type: IP (0x0800)
Trailer: 000000000000
Internet Protocol, Src Addr: 192.168.247.140 (192.168.247.140),
Dst Addr: 192.168.100.21 (192.168.100.21)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0x0100
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x5cdd (correct)
Source: 192.168.247.140 (192.168.247.140)
Destination: 192.168.100.21 (192.168.100.21)
Transmission Control Protocol, Src Port: 1436 (1436),
Dst Port: http (80), Seq: 1293025280, Ack: 0, Len: 0
Source port: 1436 (1436)
Destination port: http (80)
Sequence number: 1293025280
Header length: 20 bytes
Flags: 0x0002 (SYN)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgment: Not set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
.... ...0 = Fin: Not set
Window size: 16384
Checksum: 0x3ff1 (correct)
0000 00 03 47 d9 26 60 00 10 4b 75 54 96 08 00 45 00 ..G.&`..KuT...E.
0010 00 28 01 00 00 00 80 06 5c dd c0 a8 f7 8c c0 a8 .(......\.......
0020 64 15 05 9c 00 50 4d 12 00 00 00 00 00 00 50 02 d....PM.......P.
0030 40 00 3f f1 00 00 00 00 00 00 00 00 @.?.........
Frame 857 (60 bytes on wire, 60 bytes captured)
Arrival Time: Aug 12, 2003 02:00:39.622931000
Time delta from previous packet: 0.020009000 seconds
Time relative to first packet: 18.725405000 seconds
Frame Number: 857
Packet Length: 60 bytes
Capture Length: 60 bytes
Ethernet II, Src: 00:10:4b:75:54:96, Dst: 00:03:47:d9:26:60
Destination: 00:03:47:d9:26:60 (Intel_d9:26:60)
Source: 00:10:4b:75:54:96 (3Com_75:54:96)
Type: IP (0x0800)
Trailer: 000000000000
Internet Protocol, Src Addr: 192.168.57.140 (192.168.57.140),
Dst Addr: 192.168.100.21 (192.168.100.21)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0x0100
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x1ade (correct)
Source: 192.168.57.140 (192.168.57.140)
Destination: 192.168.100.21 (192.168.100.21)
Transmission Control Protocol, Src Port: 1271 (1271),
Dst Port: http (80), Seq: 1927610368, Ack: 0, Len: 0
Source port: 1271 (1271)
Destination port: http (80)
Sequence number: 1927610368
Header length: 20 bytes
Flags: 0x0002 (SYN)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgment: Not set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
.... ...0 = Fin: Not set
Window size: 16384
Checksum: 0xd8c3 (correct)
0000 00 03 47 d9 26 60 00 10 4b 75 54 96 08 00 45 00 ..G.&`..KuT...E.
0010 00 28 01 00 00 00 80 06 1a de c0 a8 39 8c c0 a8 .(..........9...
0020 64 15 04 f7 00 50 72 e5 00 00 00 00 00 00 50 02 d....Pr.......P.
0030 40 00 d8 c3 00 00 00 00 00 00 00 00 @...........
Philip Sloss
--
Feedback? e-mail: stuff@lupwa.org
[text was edited by author 2003-08-12 00:06:37] |
|
Steve
I'm a PC, so shut up
Consultant
join:2001-03-10
Yorba Linda, CA
| reply to Steve
Re: MSBLAST analysis thread
It seems that the first two octets of the spoofed IP address will always match the first two octets of the actual machine's IP address.
This seems like a good idea: machines behind NAT (with private addresses such as 10.X.X.X or 192.168.X.X) are not likely to get infected, but machines that are "wide open" will spoof from addresses that are more likely to be within the ISP's address space. This means that even ISPs that perform egress filtering (throwing away outbound traffic that couldn't have originated on their network -- spoofed traffic) won't catch much of it.
This is the first clever thing I've seen in this program.
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
swiz
@megapath.net | reply to Steve
OK - so what tool are you guys using to pull the source code from this puppy, or do you have the actual SOURCE?
Please share? |
|
Steve
I'm a PC, so shut up
Consultant
join:2001-03-10
Yorba Linda, CA
| said by swiz:
OK - so what tool are you guys using to pull the source code from this puppy, or do you have the actual SOURCE?
Nobody that I know of has the source: I have been using the wonderful IDA Pro Disassembler to perform my analysis. It's been about 12 hours since Philip sent me the binary and it's been a very busy day.
Going from Intel assembler back to C is not a trivial task for anybody but Steve Gibson
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
Steve
I'm a PC, so shut up
Consultant
join:2001-03-10
Yorba Linda, CA
| reply to Steve
Dumb MSBLAST.EXE code #2:code:
sprintf( my_hostname, "%s", inet_ntoa(&ipaddr));
I guess this moron never heard of "strcpy".
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
Khaine
join:2003-03-03
Australia | reply to Steve
You guys are doing an amazing job. I only wish that their were lots of tutorials around so that I could help.
Best Regards
KhaineBOT |
|
