SteveI know your IP address
join:2001-03-10 Tustin, CA
7 recommendations |
Steve
2003-Aug-11 7:10 pm
MSBLAST analysis threadI 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 |
|
1 recommendation |
From » xforce.iss.net/xforce/al ··· s/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 |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA
|
Steve
2003-Aug-11 8:36 pm
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] |
|
Mark75 Premium Member join:2001-11-15 Phoenix, AZ |
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. |
|
|
to Steve
F-secure is calling it Lovsan alias msblast: » www.f-secure.com/v-descs ··· st.shtml |
|
|
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. |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA |
Steve
2003-Aug-11 10:05 pm
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 |
|
|
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 |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA |
Steve
2003-Aug-11 10:30 pm
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 |
|
lashmun Premium Member join:2002-12-14 Novi, MI
|
to Steve
Deleted - posted in the wrong place - sorry [text was edited by author 2003-08-11 22:48:16] |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA |
Steve
2003-Aug-11 10:39 pm
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 |
|
Steve |
Steve
2003-Aug-11 10:46 pm
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) |
|
|
pcdebbbirdbrain Premium Member join:2000-12-03 Brandon, FL ARRIS DG1670
1 recommendation |
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 |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA |
Steve
2003-Aug-11 11:48 pm
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 |
|
psloss Premium Member join:2002-02-24
1 recommendation |
to Steve
Re: simulated winupdate flood packetssaid 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 |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA |
Steve
2003-Aug-12 12:07 am
Re: MSBLAST analysis threadIt 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 |
|
|
swiz to Steve
Anon
2003-Aug-12 12:53 am
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? |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA
1 recommendation |
Steve
2003-Aug-12 1:16 am
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 |
|
Steve |
Steve
2003-Aug-12 1:18 am
Dumb MSBLAST.EXE code #2: code:
sprintf( my_hostname, "%s", inet_ntoa(&ipaddr));
I guess this moron never heard of "strcpy". Steve |
|
Khaine join:2003-03-03 Australia |
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 |
|
|
to Steve
Note there are two attack scan signatures so you might want to look into the difference between the two and what causes the different scan (ie there might be two very similar but slightly different worms as I'm thinking it could be attacking a different interface or something, but there is a difference). Attached are samples of two common TCP port 135 scans we have seen thus far which are different. Both of these versions do the transfer of msblast.exe via tftp via commands issued over TCP port 4444 so we know that both scan signatures are attack signatures. Note the differences are: from scan 1 - MD5 = B112ADDE25720C42E5B55B75CDD8EACA 03D0 46 00 58 00 46 00 58 00 46 00 58 00 9F 75 18 00 F.X.F.X.F.X..u.. and from scan 2 - MD5 = 288C8038AFD9B6CC56C3F5CAAFC46659 03D0 46 00 58 00 46 00 58 00 46 00 58 00 9D 13 00 01 F.X.F.X.F.X..... Blake |
|
R2R Not MVM join:2000-09-18 Long Beach, CA |
to psloss
Re: simulated winupdate flood packetsNot that is matters, but both of those packets have the slightly different "payloads" / data fields:
00 00 00 00 00 00 50 02 40 00 3f f1 00 00 00 00 00 00 00 00
vs.
00 00 00 00 00 00 50 02 40 00 d8 c3 00 00 00 00 00 00 00 00
I am sure it means NOTHING, but these packets are not just simple 40-byte SYN packets -- a strange and variable 20-byte payload is added. Why? Probably insignificant. |
|
psloss Premium Member join:2002-02-24 |
psloss
Premium Member
2003-Aug-12 2:12 pm
said by R2: Not that is matters, but both of those packets have the slightly different "payloads" / data fields:
00 00 00 00 00 00 50 02 40 00 3f f1 00 00 00 00 00 00 00 00
vs.
00 00 00 00 00 00 50 02 40 00 d8 c3 00 00 00 00 00 00 00 00
Those are the TCP checksums, I believe. Philip Sloss |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA |
to R2
said by R2: I am sure it means NOTHING, but these packets are not just simple 40-byte SYN packets -- a strange and variable 20-byte payload is added.
Yes, they are just simple 40-byte SYN packets, and they have no payload. There are 20 bytes of IP header, 20 bytes of TCP header, and in Philip's captures you're seeing the link level (Ethernet) header too: code:
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 @.?.........
The stuff at the end is just padding on the wire. Steve |
|
R2R Not MVM join:2000-09-18 Long Beach, CA
|
R2
MVM
2003-Aug-12 2:26 pm
EDIT!! I forgot the MAC Header... DUH!! [text was edited by author 2003-08-12 14:27:49] |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA |
Steve
2003-Aug-12 2:29 pm
said by R2: EDIT!! I forgot the MAC Header... DUH!!
Thankfully, Philip and I didn't |
|
R2R Not MVM join:2000-09-18 Long Beach, CA
|
R2
MVM
2003-Aug-12 2:37 pm
That's why you guys make the big bucks!:) It is still a little weird. Ethereal calls the FRAME a "packet" and states the "packet length" is 60 bytes. However, the IP Header states the total length is 40 bytes -- that "0x28" in the second row. So... there really is no payload and the FRAME should really only be 52 bytes... OR, is there a reason why the FRAME must be padded to 60?? Not that I can see. Oh well, this is off topic. Please ignore and go onward!! [text was edited by author 2003-08-12 14:38:23] |
|
Marilla9I Am My Own Arbiter Premium Member join:2002-12-06 Belpre, OH |
Marilla9
Premium Member
2003-Aug-12 2:41 pm
R2.. you're braver than I... when these guys start talking this sort of stuff, I just nod and smile and try to look calm while I frantically look for a summary of the information |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA
|
to R2
said by R2: That's why you guys make the big bucks!:)
Actually not making any bucks on this: I've not found anybody to pay me for it yet. I'll take "Fame" and "Adulation" though quote: Ethereal calls the FRAME a "packet" and states the "packet length" is 60 bytes.
"Frame" is the term for an Ethernet packet, and the minimum payload size is 46 bytes. Payload = 46 bytes (20 IP + 20 TCP + 6 padding) MAC hdr = 14 bytes Total = 60 bytes (smallest Ethernet frame) Ref: » www.erg.abdn.ac.uk/users ··· mac.htmlSteve |
|
psloss Premium Member join:2002-02-24 |
psloss
Premium Member
2003-Aug-12 2:54 pm
said by Steve: Actually not making any bucks on this: I've not found anybody to pay me for it yet. I'll take "Fame" and "Adulation" though
I'll take money. Although if I had a paying job, I probably wouldn't have been able to do much of this "real-time." Philip Sloss |
|