I have around 500 users, around 1000 PCs, and 6 servers. My staff
consists of me and two other people.
Am I an "admin guru"? No. Have I claimed to be? No. Are you even reading
what I'm writing? Apparently not, or you wouldn't be accusing me of
claiming to be infallible.
Below is the text of a message from NTBUGTRAQ discussing the apparent
infection methods of this worm. Having IIS and NT patched aren't
enough...
===================
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
===================
________________
John Hornbuckle
Network Manager
Taylor County School District
318 North Clark Street
Perry, FL 32347
-----Original Message-----
From: Eric Brouwer [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 20, 2001 12:43 PM
To: NT System Admin Issues
Subject: RE: Microsoft Has Nimda
How many users do you support? How many servers and PC's do you
support? How many people are on your staff?
I WAS patched against Code Red. I had several attempts to infect my
system, but it never got through. THIS did. I have NO idea how or why.
I applaud you being the admin guru that you'd have us believe that you
are.
-----Original Message-----
From: John Hornbuckle [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 20, 2001 12:08 PM
To: NT System Admin Issues
Subject: RE: Microsoft Has Nimda
I didn't say that.
What I said was that the person at Microsoft who was responsible for
maintaining such a high-profile Web site should be fired if they failed
to keep that site up-to-date. Not having properly-patched servers is a
terrible embarrassment for Microsoft (assuming that this is how NIMDA
got through the gate).
And let me turn your question around... Should there be no
accountability? Should everyone who failed to maintain proper security
be patted on the back and told they're doing a good job? Aren't we
supposed to be professionals? Aren't we paid to do our best to prevent
this sort of thing from happening?
We all screw up sometimes. I'm certainly not perfect myself, and I don't
expect anyone else to be. What I *do* expect is that system
administrators will take reasonable measures to ensure the security of
their systems. I don't think it's unrealistic for the world to be able
to rely on us to do our best to ensure that our servers don't get
infected by a worm that exploits a vulnerability that was identified a
year ago (the web server folder traversal issue was first addressed in
MS00-057 in August of 2000).
________________
John Hornbuckle
Network Manager
Taylor County School District
318 North Clark Street
Perry, FL 32347
-----Original Message-----
From: Martin Blackstone [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 20, 2001 11:52 AM
To: NT System Admin Issues
Subject: RE: Microsoft Has Nimda
So everyone who got Nimda should be fired?
http://www.sunbelt-software.com/ntsysadmin_list_charter.htm
http://www.sunbelt-software.com/ntsysadmin_list_charter.htm
http://www.sunbelt-software.com/ntsysadmin_list_charter.htm
