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

Its been an exhaustive couple of days, for you all I'm sure.

The Problem
- -----------
I've just gotten off the phone with numerous experts from the major
companies (including AV experts and CARO members) in an effort to
answer the question; "Is it possible to trust a cleansed server?"

See, due to the things Nimda does, it may well leave your machine
open to easy access. Even if the virus/worm components have been
removed/cleansed, if another attack occurs that exploits the open
shares (for example) who knows what the attack might do or leave
behind. The effects of such an attack are not going to be obvious to
an AV product.

Basically, cleansers available now do not address some of the more
insidious components of Nimda;

- - Guest account being enabled. In the case of an infected Domain
Controller, this means the account is enabled in the Domain.

- - Guest account being added to the Administrators group. Again, on
DCs the Guest user is added to the Domain Admins group.

- - Modification to registry keys. Some reports say that values under
LanManServer\Parameters are deleted, in an effort to remove any
AutoShareServer value that might prevent the availability of C$,
etc...), while other reports talk only of the creation of new shares
(C$, D$, etc...) under that key.

- - Numerous critical system files are modified, including files in the
dllcache directory, and its questionable whether or not these can be
restored to good health by an untested cleanser (the suggestion that
SSL functionality might not work after cleansing.)

Then there is the question as to whether or not all of the effects of
Nimda have actually been determined. With its buggy operation, its
possible it might do other things inconsistently, in a way that might
leave cleansers lacking.

Testing we performed today suggested that cleansers that were
available all did a reasonable job of disinfecting an infected file,
but the testing was limited to that since cleansing infected systems
would require an extremely wide variety of installations.

Additional Threats
- ------------------

With the open shares available, it would be possible for an attacker
to gain entry to your system and retrieve or deposit other tools or
data (like copying your SAM). These effects will be undetectable as
part of AV Nimda cleansing, and could only be uncovered as a result
of an extensive forensic effort.

You should seriously consider the possibility that this has already
happened to machines which might hold sensitive information if you
have left them connected, or reconnect prior to a comprehensive
cleansing and inspection.

Decision Time
- -------------

The bottom line folks is that as of the time of writing, you have to
make a decision;

a) I need the system up and running now!

Fine, disconnect it from infection vectors, restore it from tape or
reformat and install fresh, patch it. Restore the data (even if its
infected), run the currently available cleanser, and scan it again
with your AV product. If it passes, reconnect it to the 'net and
carry on.

b) I can leave the machine turned off until Friday.

Better, wait for a comprehensive cleanser from your AV Vendor
(assuming they make one.) McAfee may already have one available and
Symantec will have one shortly. Other AV Vendors may/will probably
also produce one. The complexity of this thing has been such that
multiple versions of cleansers have been required in order to do it
"right". The same may be true of these additional cleansers.

The Problem with Rebooting
- --------------------------

We noticed in our testing one cleanser that only worked if the
machine was rebooted. Problem is that with a fully infected system, a
reboot is not likely to bring up a live system. Depending on which
files have been infected, a system might fail a reboot completely,
partially, or succeed completely. Its probably safe to assume that
rebooting an infected server is going to lead to a complete system
failure and cause to re-install the OS.

Without rebooting it may not be possible to cleanse all of the files
that might cause re-infection. McAfee's recommendation is to stop IIS
and all running applications and install patches, many of those
patches require a reboot to install.

So you see the Catch-22.

Definitions
- -----------

For the purposes here, an infected system is one where Admin.dll or
readme.exe has actually run locally. In the case of servers, this is
most likely an IIS box infected from the network via one of the IIS
vulnerabilities. It may, unfortunately, be the result of surfing the
web or reading email from a server (really dumb things to do). I've
had reports of Exchange Servers, Outlook Web Access Servers, IIS
Servers, SQL Servers, Proxy Servers, SMS Servers, Domain Controllers,
and File and Print Servers all being infected.

If the box is actively TFTP'ing (inbound or outbound), issuing
numerous HTTP requests (when you're not surfing), or if your AV
product says you're infected, then you are. If the box has Admin.dll
in the /scripts or root directory, has an enabled Guest account, or
has Guest in the Administrators group (or Domain Admins group), then
you're infected.

The simple presence of .eml/.nws files, or copies of readme.exe, does
not in and of itself indicate an infected machine. If the files are
put there because of an infected client through a file share, they
may not have been run on the server yet.

Summary
- -------

More than a few people have offered perl scripts and other small
programs designed to clean out the javascript from altered web pages.
While this might seem like a good idea, the fact is that an infected
web server can/will quickly re-add the code back to those pages if
its still infected. Because of the virus behavior of Nimda, if you
don't remove it completely there's not much you can do to prevent
such re-infections. Obviously its not just a matter of removing
files.

I apologize for the delay in getting more information to those
hundreds of you who have been pleading for help in cleansing your
systems. I had hoped that the AV cleansers made available today would
have solved the problems, but as the day wore on it became clearer
that this wasn't going to happen as quickly as we all want.

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

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

iQCVAwUBO6lXDRBh2Kw/l7p5AQHrPQQAxbgWKP8rGiVfHFJVTokzJMzGi851/hOt
At1JKz8e+cTB1iLdfNb7KspV9VpbByBaI+dwZkoZe63pq4OGs1tuBB4PG9h8D4uw
A/iH7Y/OkamrPM9mm4603xougdBs7n4cxwbMvE67kmK39849LWi7SkRGZq9obfKN
dEB3tg6kYws=
=9OVI
-----END PGP SIGNATURE-----

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