OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Greg Francis (francisGONZAGA.EDU)
Date: Mon Sep 24 2001 - 13:11:12 CDT

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

    on 9/24/01 10:26 AM, Olivier Berton at obertonptc.com wrote:

    > I would like to add 3 questions to dig further in this issue:
    >
    > 1 - If the nimda code had a portion of code that could send the backed-up
    > SAM for example, wouldnt the CERT or others had found out about it?
    > The nimda and codered codes have been analysed a lot and I havent heard
    > anything about this type of threat...

    What I was suggesting is not that NIMDA itself contain the code for copying
    the SAM, but that since the server is advertising itself to the world that
    it has been infected by trying to attack other servers, that another attack
    could be waged against it that would grab the SAM, install a trojan, etc.
    NIMDA could just be one part of a two level attack.

    > 2 - If one of these worms left a trojan, there would be a port listening on
    > the compromised server that should be "fairly" easy to spot.
    > Am I right here or can a trojan hide this as well ?

    Perhaps. What if it was a trojan that took over a standard port like 137?
    That it handles everything normally until it receives a certain trigger to
    do its malicious activity. I think there are some sophisticated attacks on
    Windows servers just waiting to happen.

    > 3 - If you use a well configured Firewall, how can the attacker come back to
    > the trojan ? Most of the usual trojans for windows will rely on Netbeui
    > traffic I believe which is blocked by Firewall...

    To me, there are those people that take security seriously and have a well
    configured firewall, install security updates, monitor traffic, etc. Then
    there are those people that either don't have the resources for adequate
    security or just aren't concerned about it to implement good practices. For
    every secure network, there are probably ten insecure networks.

    I'm just trying to expect the unexpected. We're living in a pretty hostile
    network environment right now and NIMDA (and Code Red) have opened up the
    possibility of mass compromise of networks even though they don't do it
    directly.

    Greg

    > I would be interested by any comments on these as I know a lot of admins are
    > concerned about their networks being compromised.
    >
    > Thanks
    >
    > Olivier
    >
    > -----Original Message-----
    > From: Greg Francis [mailto:francisGONZAGA.EDU]
    > Sent: dimanche 23 septembre 2001 01:20
    > To: win2ksecadviceLISTSERV.NTSECURITY.NET
    > Subject: Re: Have we really cleaned up?
    >
    >
    > What you've indicated is certainly a significant danger of this worm. Once a
    > system has been compromised by the worm, you essentially have lost integrity
    > on that system, even after you've removed the worm. The CERT advisory on the
    > NIMDA worm (http://www.cert.org/advisories/CA-2001-26.html) says that the
    > only safe way to recover is to reinstall the server. However, what if that
    > server happened to be the PDC or a BDC or an Active Directory DC? In that
    > case, the SAM/AD is potentially compromised for the domain. Of course, it's
    > not good practice to have IIS running on a DC but that doesn't stop it from
    > happening. The fact that an infected server is broadcasting it's IP around
    > the world doesn't help since it merely advertises compromised systems. A
    > wily hacker could use that information to infect a system (or many) and then
    > go in later at their leisure to probe what's on that system.
    >
    > The point is, the procedures that are being documented to remove NIMDA (and
    > Code Red II) often don't discuss the potential side effects of the infection
    > other than the direct impact of the infection itself. I'd say that whole
    > networks have been compromised and won't be fixed because people aren't
    > looking beyond the obvious.
    >
    > Greg
    >
    > on 9/20/2001 8:26 PM, Poomba1 at poomba1.geoYAHOO.COM wrote:
    >
    >> One thing puzzles me with respect to all this "nimda" clean up
    >> documentation. From articles
    >> I've read here in this group and others, most couldn't resist but to map
    > a
    >> default admin share
    >> from a system that was banging away at their network. I myself used a
    >> "shutdown" utility to
    >> stop a machine on a neighboring subnet. There seems to be no concern or
    >> mention that a
    >> compromised machine could very well have it's entire SAM compromised.
    >> My theory is simple, what is to say a compromised system hasn't had it's
    >> "config" folder
    >> looked into? Maybe some alternate script used the intense scanning of it's
    >> own network
    >> to determine infected machines. Then went out and captured the SAM and has
    >> legitimate
    >> username/password info (from using a variety of utilities freely
    > available)
    >> of some 100,000
    >> machines. So 9/10 machines have people who do reset and change all
    >> passwords, that
    >> would still leave a possible 10,000 machine "zombie" force that one could
    >> have legitimate
    >> logon credentials for. Do people feel it is too far fetched? If your web
    >> server on the wire was
    >> compromised, would you be willing to take the chance? Everyone talks about
    >> how these
    >> cleanup utilities will get you back on track. Great, now someone can
    > return
    >> in a couple
    >> weeks to take control without having to break in.

    --
    Greg Francis
    Sr. System Administrator
    Gonzaga University
    francisgonzaga.edu
    509-323-6896
    

    _____________________________________________________________________ ** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice" ** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST" SEND ALL COMMANDS TO: listservlistserv.ntsecurity.net