In-depth MS Blaster

[SonofGalen]

Also, I wrote this because of the last MS Blaster tutorial, which was mainly about how to get rid of it or stop yourself from getting it.

All of this is my original work, although I did research and gathered information from the following websites:
http://www.cisilion.com/news-cisco-blaster.htm
http://www.faqs.org/faqs/windows/winsock-faq/
http://www.grc.com/default.html

Attached to this tutorial is the source code for MS Blaster. At this point, that source code cannot be used for any ill, because most AV software and Firewalls are set up to block Port 135 and the Blaster virus. Also, as the person who de-compiled the source code to the Blaster, I believe it was Robert Graham, pointed out:

Disclosing the source to blaster will not help blackhats.
The Blaster worm is not very good. However, it is
useful for whitehats to have a complete dissection of the
worm.

Robert Graham's de-compilation of the Blaster also includes many conjectures he made about the person who designed it, so that he might be better understood. It is a recommended read, even for those who are not familiar with C, the language that it is displayed in.

One of the things that set the Blaster apart from other worms lately was that it didn't attack servers any more than it did desktops. In fact, instead of taking advantage of the services running there so that the creator could later gain control, he simply disabled DCOM on all of the machines that it came in contact with.

DCOM stands for Distributed Component Object Module, and, I have been told, runs over port 115, though I do not swear to this. It is used, and tied in very closely with, TCP/IP. DCOM is especially useful for sending information across several networks quickly and securely, particularly when using HTTP. From this, it becomes obvious that anyone infect with the Blaster wouldn't be able to either send or recieve web-page information, one of the main things that the internet is used for today.

While this did, in many ways, slow down the Blaster virus, it also helped it out. When my servers go down, the first thing I look for is problems within the server. A normal worm, which might have disabled the service itself or gotten inside of it to gain control of the system, would have been immediately noticed, if only by the effects that it caused.

However, Blaster, either because of the programmer's lack of talent or ingeniousness, didn't do either of these things. So many SysAdmins had problems tracking down the blaster, especially in the very beginning.

But how did the Blaster worm go about disabling DCOM, something which is vital to modern day network communication? To answer that, we must look at the source code.

#include <winsock2.h>
#include <ws2tcpip.h> /*IP_HDRINCL*/
#include <wininet.h> /*InternetGetConnectedState*/
#include <stdio.h>

This is the very beginning of the program, where we can already see that the Blaster virus is including information related to WinSock, which is short for Windows Sockets.

Winsock is vital for a Windows machine to communicate across networks. It is stored, on Windows machines, as WINSOCK.DLL. Exactly what this does, however, is very interested. It is not only vital for Windows machine to communicate across a network, it is the actual Windows TCP/IP, Transmission Control Protocol / Internet Protocol, interface. TCP/IP is, for all intents and purposes, the language of the internet.

So from just that first line of code we immediately see that the program is going to involve network communications, and deal closely with those things.

Just a few lines into the code, we see that there are ports already being defined, for later use in the program:

#define TFTP_PORT_69 69
#define MSRCP_PORT_135 135
#define SHELL_PORT_4444 444

An interesting side-note is that disabling port 69 will stop the worm from fully infecting a computer, because it stops the client from downloading the program. Also, it starts a very temporary service running there. THAT is something that should, for any SysAdmin, immediately bring up a problem.

If you ever notice that a service has suddenly started on your computer, shut it down, and ask questions later. If you don't recognize it and don't know what it is, its generally better to play it safe, rather than let yourself get caught with your pants down.

The worm inserts the following registry key into a Windows computer, which will need to be removed for full deletion of MS Blaster:

RegCreateKeyEx(
/*hKey*/ HKEY_LOCAL_MACHINE,
/*lpSubKey*/ "SOFTWARE\\Microsoft\\Windows\\"
"CurrentVersion\\Run",
/*Reserved*/ 0,
/*lpClass*/ NULL,
/*dwOptions*/ REG_OPTION_NON_VOLATILE,
/*samDesired */ KEY_ALL_ACCESS,
/*lpSecurityAttributes*/ NULL,
/*phkResult */ &hKey,
/*lpdwDisposition */ 0);
RegSetValueExA(
hKey,
"windows auto update",
0,
REG_SZ,
MSBLAST_EXE,
50);
RegCloseKey(hKey);

What this key does, basically, is check to see if the computer is already infected with the Blaster. If it isn't, they take care of that. It does this by use of the Windows Update feature, which can be quite nice, but also poses a security threat, as we see here.

The worm also checks for a location to download the virus from. This is actual a smart thing to do, because it allows for the worm to be downloaded from any location where it already exists, instead of from a single hard-coded location. Once the worm begins to spread, it can be shut down quite quickly.

If the worm were always downloaded from a limited list of hard-coded locations, looking at packet logs would discover this rather quickly, and those locations would be advertised and blocked off, thus stopping, or at least crippling, the spread of the Blaster.

The worm constantly checks for the internet connection:

while (!InternetGetConnectedState(&ThreadId, 0))
Sleep (20000);

If it doesn't find it, it goes into hibernation for exactly 20,000 milliseconds, or 20 seconds.

When it is connected, it randomly chooses IP and network addresses, using the following code:

local_class_a = (rand() % 254)+1;
local_class_b = (rand() % 254)+1;

What this does is it takes a percentage of 254 and adds one to it. These numbers were, of course, chosen for a reason. Each IP address is made up of four octets, which range from 0 to 255. Taking a random percentage of 254 and adding one allows it to be any valid IP range, up to 255.

Side-note: The programmer could have easily designed an array that would have held in the original IP Address, and built up a list of succeeding ones to scan for. It appears that instead of this, he decides later, to continue using the random generation, and converts the IP Address back and forth through strings, in an overly complicated fashion.

if (gethostname(myhostname, sizeof(myhostname)) != -1) {
HOSTENT *p_hostent = gethostbyname(myhostname);

if (p_hostent != NULL && p_hostent->h_addr != NULL) {
struct in_addr in;
const char *p_addr_item;

memcpy(&in, p_hostent->h_addr, sizeof(in));
sprintf(myhostname, "%s", inet_ntoa(in));

p_addr_item = strtok(myhostname, ".");
ClassA = atoi(p_addr_item);

p_addr_item = strtok(0, ".");
ClassB = atoi(p_addr_item);

p_addr_item = strtok(0, ".");
ClassC = atoi(p_addr_item);

This code looks for host names that it can use, either the current one used by the client it has infected, or random ones outside the network that it can use. It stores these addresses and host names in strings for later use.

srand(GetTickCount());
ClassC -= (rand() % 20);
}
local_class_a = ClassA;
local_class_b = ClassB;
scan_local = TRUE;
}

This code is what actually determines whether or not it attacks and tries to infect a computer on the local network or a computer on the remote network.

The next segment of code is what determines whether or not the Blaster will assume the computer is Windows 2K or XP. The result of this determines what type of exploits to use. Just for your own information, it assumes it is attacking XP 80% of the time, and 2K% of the time.

The reason that it checks for only 2K and XP is that later on the coding requires raw sockets, which are sockets and packets designed by the programmer, and not ones defined or built by TCP/IP. This is important because Raw Sockets were not available in Windows until Windows 2000, and then later in XP.

if (!scan_local) { <----------This checks to see if its local or not, the ! means not...
ClassA = (rand() % 254)+1;
ClassB = (rand() % 254);
ClassC = (rand() % 254);
}

This code is very similiar to what we saw above for determining random IP ranges, used only for outside IP Addresses.

The following string of code checks for the dates, according to local time, and attacks during these dates only:

#define MYLANG MAKELANGID(LANG_ENGLISH, SUBLANG_DEFAULT)
#define LOCALE_409 MAKELCID(MYLANG, SORT_DEFAULT)
GetDateFormat( LOCALE_409,
0,
NULL, /*localtime, not GMT*/
"d",
daystring,
sizeof(daystring));
GetDateFormat( LOCALE_409,
0,
NULL, /*localtime, not GMT*/
"M",
monthstring,
sizeof(monthstring));
if (atoi(daystring) > 15 && atoi(monthstring) > 8)
CreateThread(NULL, 0,
blaster_DoS_thread,
0, 0, &ThreadId);

The dates that it will attack by are:
Aug 16 through Aug 31
September 16 through September 30
October 16 through October 31
November 16 through November 30
December 16 through December 31

memset(&server, 0, sizeof(server));
server.sin_family = AF_INET;
server.sin_port = htons(TFTP_PORT_69);
server.sin_addr.s_addr = 0; /*TFTP server addr = <any>*/
if (bind(fd, (struct sockaddr*)&server, sizeof(server)) != 0)
goto closesocket_and_exit;

This checks for incoming packet requests. One thing to note is that it does not specify what packets need to come in. Any packets will do, which can cause the worm to use the wrong address, or to possibly shut down and re-start prematurely, keeping the worm busy as long as there are packets coming in. This, more than anything else, is probably what slowed down the worm, and kept it as relatively harmless as it was. It would have been much worse if the coding here had been tighter.

To stop this from happening, the creator of the worm shuts down the TFTP service and re-starts it, although this doesn't take care of everything. This is a bit of sloppy coding, I'm afraid, and could be done by any Computer Science student who has studied C++ and Computer Networking. This, more than anything else, is probably what slowed down the worm, and kept it as relatively harmless as it was. It would have been much worse if the coding here had been tighter.

The worm then goes through a process of building packets and sending them to the given address, modifying the packet size for headers and such, sending out the entire worm in a series of packets 12, before going back into sweet hibernation.

The worm will, after a time, wake up and go through a somewhatcomplicated process to determine the next IP address in the range to attack, and attempt to infect. We see this process below:

void blaster_increment_ip_address()
{
for (; {
if (ClassD <= 254) {
ClassD++;
return;
}

ClassD = 0;
ClassC++;
if (ClassC <= 254)
return;
ClassC = 0;
ClassB++;
if (ClassB <= 254)
return;
ClassB = 0;
ClassA++;
if (ClassA <= 254)
continue;
ClassA = 0;
return;
}
}

This function is orignally called in the main function. Basically, what it does is it starts at the end of the IP and begins the incrementing there. The end of the IP is also the most local address, and the beginning the most global. Because the creator starts at the end, we can see that he has decided to spread it as locally as possible, then growing from there.

This is, in theory, good because the worm can spread more quickly from one very infected network than from a few barely infected ones. The concentrated source seems to win out in the long-run here.

The worm, after more infecting and checking, will begin to send out more packets, which is where the Raw Sockets idea kicks in. The source code includes these packets, and aren't of any real interest except to the hard-core networking admin, who wants to disassemble the packets.

The designer of the worm continually uses DoS attacks after a client has been attacked, both to infect other computers and to disrupt internet communication in general. One of the things that the programmer especially liked to attack and use windowsupdate.com.

Final analysis: The MS Blaster was simple in its basic idea, and could have been thought up by almost anyone. The actual design of it required someone with several programming books and a good understanding of networking, though it was obviously not designed by an expert. It could have been built by any Middle School student who really put his mind to it.

If you're not familiar with networking, the actual full source-code of it might confuse you at first, but it could also prove to be an excellent source to use and look at.

That's the overview of the MS Blaster worm. Not very original, just somewhat well planned out in its later execution.

[ali1]

Good job.

[Datsun 260Z]

Great tutorial! Here's some greenies.
-Ben

[Tedob1]

this isn't the first worm to take advantage of the tftp client found in windows nt, 2k, xp machines to download more components. to help prevent the future spread of worms its a good idea to delete all instances of it. if you need tftp put a copy in a directory thats not in the search path.

very informative. thank you.

[Sm0kinP0t]

Great job. Really a 5star tut.

[frz]

that's a well-commented source code for the MSBlast. I'll take the time to read and understand each lines of code. I'm new in socket programming and I see here that there are bunch of lines that I need to really understand to see how those TCP/IP c codes are implemented on this particular worm. thanks for posting a good material. cheers.

[labchick64]

SonofGalen--this post was very informative. I'm no programmer by any means, but your tutorial makes understanding the code alot easier. thanks.

[SyNAcK]

A good post. I always like to see the source, I think it is benneficial in many ways. As a white hat, seeing this code right away I would've realized that I was safer than most since I have blocked ingoing and outgoing connections to port 69 (TFTP).

TFTP like NetBIOS will always be associated with windows insecurity.

[S1lv3rW3bSurf3r]

"The reason that it checks for only 2K and XP is that later on the coding requires raw sockets, which are sockets and packets designed by the programmer, and not ones defined or built by TCP/IP. This is important because Raw Sockets were not available in Windows until Windows 2000, and then later in XP."

Actually if you have read Steve Gibson's tut on Raw Sockets, you will see that the Microsoft Representative states that Raw Sockets were available in NT .......

"In other words, what Microsoft has done with Windows 2000 and Windows XP, is to add a number of powerful and completely unnecessary networking features because, they say, "some people complained about Windows lack of full Raw Socket support". However, it will ONLY be Internet-hostile malicious code that will need to use the advanced "direct access" provided by Windows' new full Raw Socket support.

With Microsoft's traditionally-limited Raw Sockets support, Windows applications were UNABLE to "forge" or "spoof" the machine's actual IP address to hide the source of any malicious traffic they might generate. This source address "spoofing" prevents effective backtracking through the Internet. Windows applications were also unable to generate deliberately malicious "SYN flooding" style attacks, which are essentially unfilterable, and are used to effectively attack any sort of Internet TCP-connection server. (Note that even if the Internet is someday able to block spoofed source IP's, the creation of fraudulent TCP connections, which is not possible using "standard sockets" but is trivial with full Raw Sockets, will remain a problem.) "


The above is a quote from Steve Gibson's site from an article from sometime during 2001. XP and 2000 Raw Sockets <-------- can be viewed here i believe?!


"But how did the Blaster worm go about disabling DCOM, something which is vital to modern day network communication?"

Actually Dcom is not an essential part of communication in essence. Typing in dcomcnfg in Start/run and disabling it takes away the response from this port 135/7, it will listen but not respond?! Check XPdite for more info , also from Steve Gibson's site.....

The winsock api is an essential part of the communication, this acts as an application broker between your layer 7 and layer 2 protocols....... Also, blocking port 4444 in TCP communication would stop infection without having to affect tftp functionality of one's network, especially if helpdesk technicians use ftp or tftp or downloading drivers or software from a central server (which is done here). Also Disabling icmp would have killed this worms ability to spread on Lan or WAN. Also using various IP tables etc would've limited if not entirely eliminated the threat of this virus from ones LAN or WAN. EIther way. I learned this the Hard way..... heehee.....

Good analogy overall, well done in the end !!!!