Eli M. Dow 42474 Tuesday, April 6, 2004 Graduate Networks Projects: An Email Virus Let Loose

Download 485,6 Kb.
bet	1/2
Sana	25.03.2020
Hajmi	485,6 Kb.
	#8803

1 2

Alphas Contacts

Eli M. Dow 42474 Tuesday, April 6, 2004
Graduate Networks Projects: An Email Virus Let Loose*
* Well, sort of. It was let loose onto the following simulated Internet in the manner described in detail in this document.
To begin, let us look at the network we used to simulate this virus in the wild. The network consisted of 4 computers connected together via a hub. The machines are all physically the same, yet run a gambit of operating systems. It is important to note these machines were in NO WAY connected to any external network at any time.
The 4 machines were obtained and networked together via a DHCP serving hub. Each was then formatted in turn, in order to accept a fresh operating system installation. The machines were names Alpha, Beta, Gamma, and Delta. The topology is presented below with operating system annotation:

Once the network topology was set up, and the operating systems were running smoothly, it was time to begin the actual experiment. Upon the recommendation of another participant in the course, I chose to research a virus that propagated via email. These types of virus are widespread in both reality on the Internet, and in their coverage by popular media. There is little doubt that you, the reader, may have experience the bombardment of emails from persons with infected machines, or even been the unknowing victim of such a virus yourself!

In order to simulate such a virus in the wild, each machine will need to be set up with an email client. Since the most common form of email is obtained via pop and sent via smtp we have chosen to set up one of the machines as a server for that purpose. An email account was created on the server for each machine in the simulation {alpha@fakedomain.com, beta@fakedomain.com, gamma@fakedomain.com, and delta@fakedomain.com}. The passwords were set for simplicity to be of the form "$HOSTNAME_pass". To limit the number of machines required for this simulation, one of the computers running Linux (gamma) was configured as a pop3 and SMTP server. This was done using applications called courier-pop3d and postfix.
The client setup varied from machine to machine because of the different mail clients bundled with the operating systems we chose. All machines were set up with "addressbooks" containing each of the other email accounts in the simulation.
The relationships in the addressbooks are as follows:
Alpha's Contacts:

bunsen@192.168.1.1

beaker@192.168.1.1

Beta's Contacts:

fozzie@192.168.1.1

ralph@192.168.1.1

kermit@192.168.1.1

Delta's Contacts:

gonzo@192.168.1.1

piggy@192.168.1.1
Gamma's Contacts:

scooter@192.168.1.1

skeeter@192.168.1.1

rizzo@192.168.1.1

Note: Even though no clients were configure to check the mail of fozzie, ralph, kermit, gonzo, or piggie, accounts had to be created on the mail server for them. This was done to prevent needless "bounce" messages from cluttering the ethereal trace. The accounts were confirmed working by sending mail from the client machines to each contact, then inspecting the mail servers directories for mail files.
Ethereal was installed on both machines running the windows operating systems (although, any 2 machines would have been an appropriate choice). Logging will be enabled on both machines in order to ensure proper logging has taken place, should one machine fail.
At this time additional configuration was done to Delta to provide ftp services. These services will be part of a test to compromise security via a password cracking utility. The ftp server chosen was serv-U. Serv-U was configured with anonymous accounts enabled, as well as 2 real accounts. The actual accounts configured had the usernames "statler", and "waldorf", with passwords of "jim", and "henson" respectively. Serv-U was configured to start automatically at boot as a service as was all mail services from Gamma.
At that point the stage was set to begin the trace. The next phase of the simulation was to inject the virus into the system. This could have been done in several ways, but the method chosen was to manually place the virus (BugBear_4836.doc) as an email attachment from one of the Linux mail clients and send it to one of the windows hosts.
The virus used in this particular trace was obtained from

http://www.treachery.net/~jdyson/trojans/

There is a decent listing of recent virus executables with their MD5 checksums.
An interesting facet about virus research is that I was initially unsure if I had the correct virus. The only obvious way to determine what virus I had was to execute it and either watch it be caught by anti-virus software, or observe the signature it produces manually.
A more risky method was to place the virus on a machine in the hopes that antivirus software would identify, and hopefully confirm our understanding of, the virus we obtained. Extreme caution should be taken to ensure this is done safely. The windows email worm was stored only on Linux machines while being studied and compared. The antivirus software was installed on a remote machine and all virus definitions were updated to their newest packages. The virus chosen was certainly not cutting edge.

Figure 1 is the confirmation received when viewing the contents of a destroyable piece of media (a floppy disk which was physically destroyed after all experiments had been run) after it had been written under Linux and evaluated with the antivirus equipped station.

Figure 1

Findings

The initial virus introduced into the system was a variant of bugbear. My attempt to make this virus work was to initially place it on the Windows Millenium Edition PC as it was the most out dated of the group of potential targets. I crafted and email on the mail server to the WinME computer and placed in the the appropriate inbox for Beta. I began the etheral trace in promiscuous mode on another PC connected to the hub. I then booted Beta , and received the pending mail (which was only the one hand crafted message). The attachment seemed in order but nothing happened. It was a bit anticlimactic to say the least. I had been planning and studying this virus with the complete hope of seeing utter smtp chaos fly by. I saw none. I thought that perhaps the virus wasnt automatically executed by viewing the mail. I deliberately chose to open the attachment. This served no purpose, as it did not affect anything. Perhaps this particular variant was unable to work with windows ME.
So, I decided to forward this on to the Windows XP machine Delta. I stopped ethereal from tracing to begin with a clean trace. I then booted up Delta to begin popping the mail. The message came in successfully, but as indicated in figure 2, Windows XP SP1 seems a bit to smart!

Figure 2

It seems that particular level of software was able to recognize the virus and foil my trace! It seemed windows XP was too smart, and would not let me harm it. But then I thought about the potential ability to disable the built in security measures of outlook express. I realize this is not something normal users would or should do, but for the sake of research and tracing this virus in action, I should see if it was even possible. Sure enough, you can disable such a desperately needed function. In my opinion, although useful for my research, this should not be possible under any normal circumstance. Figure 3 shows the preferences window from outlook express.
Figure 3

I unchecked the box with focus in the above image. This allowed me one more attempt at getting bugbear to reek havoc on my poor little mail server. But this was not meant to be. I resent the mail from the Windows ME machine to the Windows XP SP1 computer. This time the virus came in successfully as an attachment, but it failed to produce any results of note.
At this point I thought I should check to see if the virus was matching the signature I expected it to. According to sophos, an antivirus company found at http://www.sophos.com, a binary with a 3 letter name should appear in the startup folder. This was confirmed in figure 4 below. The second method of detection is to observe a new registry key placed on the infected computer. This is observable in figure 5 below.

Figure 4

Figure 5

I had confirmed the virus was installed but no activity was present with the mail system. It occurred to me at this point that the actions expected to occur as a result of the virus, might become active upon the machines next boot. I once again restarted the trace to keep it short and easy to follow.

I rebooted both machines and proceeded to pop their mail. No activity out of the ordinary was detected in the trace. I then thought, perhaps it will only send mail if I craft a real message and send it. Thus lumping in legions of fake mails with the sending of one legitimate email. This was not the case.
I had no choice at this point, it was time to move on to a different virus. I chose to find the most noxious virus I could find, according to a staff member of Clarkson University's Office of Information Technology. He promptly suggested myDoom as it had crippled out mail servers on campus when it made its Internet debut.

This virus proved to be much more interesting. It did indeed provide us with noteworthy ethereal traces.

I followed the same injection process as was originally done with bugbear. I crafted a message on the mail server with intent to deliver to the windows XP machine. I next had to set the system clock to a date prior to the 12th February 2004. This is because of an internal expiry date set in the code. After that date, W32/MyDoom-A will no longer spread, but it will still run the backdoor component.
Once the clock considerations were made, I restarted the ethereal capture for a clean trace. Keep in mind, the virus detection of outlook express, as shipped with Windows XP, was still disabled. I wanted to give this virus every opportunity to install and perform some interesting network functions. I popped the mail account, and immediately opened the mail for viewing. I clicked on the attachment to ensure the virus would be installed. Seconds later, myDoom was actively sending messages in perfect accordance to its known signature. A tell tell sign of myDoom execution is, the initial opening of a notepad text file on the desktop in plain sight of the user.
Figure 6, is the notepad file that opens automatically when the virus is first executed on your computer.

Figure 6

Interactive Examination of Virus Activity Captured in an Ethereal Trace

Download 485,6 Kb.

1 2

Download 485,6 Kb.