-----BEGIN PGP SIGNED MESSAGE-----

Quiet a few messages have come across my desk regarding servers which
people firmly believe were not vulnerable to Nimda being infected
with it (or showing signs of infection). Let me try and summarize;

Remember, Nimda has 4 infection vectors;

IIS exploit attack
- ------------------

Not only do you have to be sure that HFNetchk reports you were fully
patched PRIOR to 9/18, but you also have to be sure that neither
PoisonBox nor Code Red had previously affected the box. Either of
these attacks would have left a ROOT.EXE in the /scripts directory,
and this is attacked by Nimda.

Also Code Red II left virtual directories behind as C and D, pointing
to the root of those two drives (if present). Nimda attempts to
exploit this fact too and call CMD.EXE directory via those web
directories. If Code Red wasn't completely removed from a system, it
won't matter how patched it was.

Many of the people I've spoken to over the last few days have
confirmed the presence of PoisonBox or CRII in evaluating their Nimda
infected box.

Vulnerable IE/OE
- ----------------

If you were keeping up on IIS patches, but hadn't been updating IE
patches (say because you're sure that no browsing is ever done from
the box), then there's a couple of ways you may have become infected.

a) If you use Explorer to highlight one of the malicious .eml/.nws
files and you haven't patched IE, then it will execute the .eml and
run README.EXE thereby infecting the box. This has nothing to do with
browsing, the program THUMBVM.DLL (thumbnail viewer for Active
Desktop) checks what files are and renders them when they're
highlighted. IE gets called and, if vulnerable, the embedded
readme.exe as an audio/x-wav will be run (has nothing to do with
Media Player if you're vulnerable).

Remember, too, that this is being done from the "My Computer" zone,
or possibly via the "Local Intranet" zone if its on another server.
These zones have much higher trust settings allowing far more to
happen automatically.

b) Do you have Terminal Server enabled on the box, and did some
Administrator use it and use IE in the process?

c) Did you use the box to go to an Intranet site (maybe because you
launched IE to see if it was vulnerable, while it had a local
infected Intranet web server set as its home page)?

d) Did someone use OE to go to a newsgroup from the server, viewing
an infected messages there via Preview Pane (may have been an
infected email, but more likely to have been an infected newsgroup
message)?

NetBIOS shares
- --------------

a) Are you sure that no Administrator in your network attached to the
administrative shares on the server? Any mapped share to the server
from an infected client could have infected the server (infected it
by putting all of the dropped files there, not necessarily causing it
to run). This could lead to infection.

b) Is there anything on the box that automatically views web pages?

Summary
- -------

All of the above are further reasons for strongly suggesting that
boxes should not be cleansed, but should be re-installed instead. A
couple more;

1. There are strong indications that the Modified Date is not
reliable for determining if a file was infected or not. Doing a find
on files modified on 9/18 may not show all of the infected files.

2. Infected files store their original counterparts as resources
within the infected file. There appears to be some bug in the method
the virus uses to do this which may cause the original file to be
named with a space in its original name. Restoring such a file might
not restore it correctly. Not sure if the AV cleansers handle this,
it may have been the reason we were seeing several versions of
cleansers yesterday. Not all files that are infected are going to be
known to the AV Vendors. You may have your own program or data files
that should have a space, or where the name isn't clear to the
cleanser, so it may not get restored correctly.

3. As I eluded to yesterday, files that are restored may not meet
their parent programs criteria for integrity. In particular, files
that are involved in encryption programs may not be usable after
restoration.

4. Cleansers may not be able to clean files that are running, like
services executables...but you also may not be able to terminate them
(some reports that Access Denied is reported if you try and kill some
infected processes). Doing a reboot in order to kill these infected
processes may well lead to a completely unstable system. If you're
going to do a reboot, make sure you've backed up data prior to doing
so. Otherwise, you may have to put the drive onto another machine in
order to access its data as part of a recovery.

5. There is a TFTPserver component to this I'm told, and it may well
be that its left up and running for anyone to connect to. Make sure
you check for any activity to/from the box and inspect it to see if
it is TFTP. TFTP normally uses UDP69, but might be using anything if
its setup by the virus/worm.

Cheers,
Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.2

iQCVAwUBO6oVNRBh2Kw/l7p5AQHLYQP/UbPD5j3APVdBSn2rGirTBapy+mIkMlvM
tZucVbzboYv3KhuYAbhIlD6KwNYABNUgak5CWjT+hLDiS0tjBJBeTijhsup1wwsf
YsOsqIW1+EBtrgmfmmIfCeqaHNeakq3h3QlsxlcdgM3oeVs72AuzwsfKD9my5HBN
Fnc2RN7HfI0=
=UU/D
-----END PGP SIGNATURE-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]