[WEB4LIB] Nimda on "patched" boxes

[Andrew I. Mutch]

I've seen a couple instances of Nimda exploiting "patched" boxes.  In
both cases, these boxes had the latest security updates from MS but they
were still hit.  How?  I think the common thread is that these boxes had
been previously compromised by the PoisonBox [sadmind/II] Worm. That
created a file, root.exe, in the scripts directory under Inetpub.

Applying the appropriate patch stopped PoisonBox and additional patches
prevented the various versions of Codered from further exploiting the
server.  However, with root.exe file in the scripts directory [simply a
copy of cmd.exe from Winnt), the server was still vulnerable to a direct
request to this file.  If that file was not removed, one of the exploits
attempted by the Nimda worm was able to access the server.  In fact, on
our one server that was compromised, I saw in the IIS logs every exploit
but that one blocked with either a 404 or 500 error.  Unfortunately, that
one hole was all that Nimda needed.  Fortunately, at our end, the damage
was minimal.  Running MS's CodeRedCleanup tool "rooted" out the root.exe
file which was the cause of the trouble.  Lesson learned: even with
patches applied, it's important to do a thorough scan of the system.  Even
the MS Security checklist for IIS wouldn't protect against this exploit.

Just checking CERT, they note that CodeRedII could have also dropped the
root.exe file. It's more likely that these came from PosionBox as a
"victim" of CodeRedII would have likely checked for the root.exe file.
The CERT advisory for PoisonBox doesn't reference the dropped root file
making it more likely to have been missed.

On our end, I first took the server off the Internet and copied over the
CodeRedCleanup tool from MS off a floppy:

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/redfix.asp


Next came the Cumulative IIS patch from MS01-044:

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS01-044.asp


Which was more of a just in case as we had already previously installed
IIS patches.  We checked to make sure that none of the HTML pages had been
corrupted with javascript and checked our network shares.  Apparently,
Nimda was unable to all of its dirty work as we didn't find evidence of
the problems that others have reported.  After a reboot, we hooked back up
to the Net and monitored the IIS logs.  This time, all of the exploits
were blocked and we believe things are secure.

Andrew Mutch
Library Systems Technician
Waterford Township Public Library
Waterford, MI



On Wed, 19 Sep 2001, Thomas Bennett wrote:

> I agree whole heartedly in most of your information here.  "I am stuck with
> Microsoft" My problem comes when your required to use MS because of a
> proprietary resource to work with the current library system.  In my case,
> we are using Innovative Interfaces, Inc system.  Although the system itself
> does not run on MS a supplementary system for Inter Library Loan called
> ILLiad was purchased by the library.  ILLiad was designed to use on
> WinNT/2000 with IIS using MSQL.  When I first heard about the purchase my
> first question was would I be able to choose the OS (Answer: NO!).  Info on
> ILLiad can be found at
>
> http://www.illiad.oclc.org/  and from the creators of ILLiad, Atlas Systems
> at http://216.54.31.120/index.html
>
> Yesterday I found SunOS/Poison Box (code red 2) running on an NT server in
> our campus computing center.  I should say it found me.  I am running
> Personal Tiny Firewall from Tiny Software ( http://www.tinysoftware.com ) on
> my PC and the server tried to attach to my PC through MS disk sharing port
> 137-139.  Because "testing" was in the ip name of the computer, I thought
> campus networking was testing security on PCs on campus.  When I received
> calls from
> from 2 users in the library that when they shutdown their windows machine it
> said there were still users connected I knew more was going on.  I pointed
> the IE browser in a test machine to the infected server and got the default
> page ( index.html )that said "Under Construction" .  I changed http:// to
> ftp:// and a list of files in the inetpub/wwwroot directory came up and I
> clicked on index.asp which showed a screen which was somewhat derogatory
> toward government and McAfee antivirus popped up giving info on the infected
> file, index.asp, in the Temporary Internet Files folder.  McAfee would not
> clean the virus but would delete the file after closing the browser window.
>
> All in all this one has some very stealth characteristics and is not
> noticeable when it connects to your PC if you are not running a firewall or
> some type of port detection software.  With Windows its looking like, be
> careful where you click it may be your last.
>
> One last note, after notifying Campus Systems that they had a server with
> the virus, I received a reply back from the main campus NT Server
> Administrator stating that the server had all the newest patches on it, what
> now?  Since that contact they have taken that server off the network.
>
>
> Thomas
>
> -----Original Message-----
> From: web4lib at webjunction.org
> [mailto:web4lib at webjunction.org]On Behalf Of Richard L. Goerwitz
> III
> Sent: Wednesday, September 19, 2001 9:17 AM
> To: Multiple recipients of list
> Subject: [WEB4LIB] Re: alternate site for resource page on attacks
>
>
> Raymond Wood wrote:
>
> > > Because of the latest virus to strike us, our webserver is down as we
> wait
> > > for an update from Norton.
> >
> > I hear apache is immune ;>
>
> With Microsoft IIS, you have a rich, complex server that hasn't
> really been subjected to the kind of public code review that Apache
> has.  With its closed, proprietary underpinnings and smaller market
> share, there's really no way Microsoft will ever be able to compete
> with Apache on the security front.  Their strategy, therefore, is
> to work IIS into a proprietary infrastructure that includes things
> like COM, COM+, .NET, FrontPage extensions, etc. that are difficult
> to integrate with other software and operating systems.  To keep its
> revenue stream up, Microsoft is also committed to never-ending fea-
> ture creep and paradigm shift, along with new licensing models that
> look more like renting than owning.
>
> It may be time for institutions who have sunk a lot of time and
> energy into Microsoft products to look at Linux (or, to some extent,
> MacOS).  Linux is *almost* ready for the desktop.  It's cetainly
> ready for the "internet kiosk" scenario.  And at the server level
> it's more reliable and cheaper than Win2k.
>
> I hear many libraries tell me "we're stuck with Microsoft" or "our
> faculty and students have to have it".  Remember that these are the
> same folks who (well, in the case of faculty at least) were using
> things like WordPerfect and Lotus in the 80s and early 90s.  They
> aren't stupid.  They can adjust.  At the server level they don't
> even see the changes, except that you need to take steps to discour-
> age use of FrontPage (which is really intended for use with IIS).
> Introduction of limited Linux-based cluster workstations can ease
> the transition.  Many people are actually excited to see something
> new.  And many administrators are thrilled when a department actu-
> ally decides to stop bending over and getting, well, hurt, by Mic-
> rosoft and trying to find a way to cut their IT budget.
>
> With regard to IIS specifically:
>
> The typical situation in academia is that a department gets a chunk
> of money as part of a grant, or as a line item in their IT budget.
> They go out and buy a server and Microsoft IIS, set it up, then have
> a couple of graduate students, or an overworked systems administra-
> tor, keep half an eye on it.  The server has a direct internet con-
> nection, with no intervening reverse proxy.  And often there's no
> firewall to block scans for unneeded services that might have been
> left accidentally turned on.  It's kind of like capital improvement
> budgets.  Many institutions are great a building things, but lousy
> at keeping them maintained and improved.  It's partly the way they
> budget.  Especially when dealing with soft money, academic folks
> often think in terms of one-time costs.
>
> Best practice in the IT industry these days is to hide internal web-
> server(s) behind a reverse proxy and then place the reverse proxy in
> the DMZ.  The "real" server(s) are then protected by a firewall that
> blocks direct outside connections.  And the real servers are vigor-
> ously maintained with patches and software updates by someone who
> monitors the security groups and CERT announcements.
>
> Rarely done in academia, I might note.  Not done enough in industry.
>
> wasn't it Obvia (the remote-access vendor) who got hit badly by the
> Code Red virus, months after Microsoft released updates (ones that
> actually worked)?
>
> ---
>
> Richard Goerwitz                               richard at Goerwitz.COM
> tel: 401 438 8978
>






*********************************************************************
Due to deletion of content types excluded from this list by policy,
this multipart message was reduced to a single part, and from there
to a plain text message.
*********************************************************************