dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
7269

Steve
I know your IP address

join:2001-03-10
Tustin, CA

7 recommendations

Steve

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

Link Logger
MVM
join:2001-03-29
Calgary, AB

1 recommendation

Link Logger

MVM

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

Steve
I know your IP address

join:2001-03-10
Tustin, CA

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]

Mark75
Premium Member
join:2001-11-15
Phoenix, AZ

Mark75 to Steve

Premium Member

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

groundling to Steve

Member

to Steve
F-secure is calling it Lovsan alias msblast:
»www.f-secure.com/v-descs ··· st.shtml

gameboyrom
Premium Member
join:2000-11-27

gameboyrom to Steve

Premium Member

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.

Steve
I know your IP address

join:2001-03-10
Tustin, CA

Steve

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

gameboyrom
Premium Member
join:2000-11-27

gameboyrom to Steve

Premium Member

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

Steve
I know your IP address

join:2001-03-10
Tustin, CA

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
lashmun
Premium Member
join:2002-12-14
Novi, MI

lashmun to Steve

Premium Member

to Steve
Deleted - posted in the wrong place - sorry
[text was edited by author 2003-08-11 22:48:16]

Steve
I know your IP address

join:2001-03-10
Tustin, CA

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 See Profile. 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

psloss See Profile 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)

pcdebb
birdbrain
Premium Member
join:2000-12-03
Brandon, FL
ARRIS DG1670

1 recommendation

pcdebb to Steve

Premium Member

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

Steve
I know your IP address

join:2001-03-10
Tustin, CA

Steve

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

psloss to Steve

Premium Member

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

Steve
I know your IP address

join:2001-03-10
Tustin, CA

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

swiz
@megapath.net

swiz to Steve

Anon

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 know your IP address

join:2001-03-10
Tustin, CA

1 recommendation

Steve

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

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

Khaine to Steve

Member

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

Link Logger
MVM
join:2001-03-29
Calgary, AB

Link Logger to Steve

MVM

to Steve
Scan1.zip
2,455 bytes
(Scan1.txt)
Scan2.zip
2,455 bytes
(Scan2.txt)
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

R2
R Not
MVM
join:2000-09-18
Long Beach, CA

R2 to psloss

MVM

to psloss

Re: simulated winupdate flood packets

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

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

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

Steve
I know your IP address

join:2001-03-10
Tustin, CA

Steve to R2

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

R2
R Not
MVM
join:2000-09-18
Long Beach, CA

R2

MVM

EDIT!! I forgot the MAC Header... DUH!!
[text was edited by author 2003-08-12 14:27:49]

Steve
I know your IP address

join:2001-03-10
Tustin, CA

Steve

said by R2:
EDIT!! I forgot the MAC Header... DUH!!
Thankfully, Philip and I didn't

R2
R Not
MVM
join:2000-09-18
Long Beach, CA

R2

MVM

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]

Marilla9
I Am My Own Arbiter
Premium Member
join:2002-12-06
Belpre, OH

Marilla9

Premium Member

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

Steve
I know your IP address

join:2001-03-10
Tustin, CA

Steve to R2

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.html

Steve
psloss
Premium Member
join:2002-02-24

psloss

Premium Member

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