Flushing DLLs follow-up

From: H C (keydet89@yahoo.com)
Date: 10/23/01 

Message-ID: <20011023131851.66939.qmail@web20503.mail.yahoo.com>
Date: Tue, 23 Oct 2001 06:18:51 -0700 (PDT)
From: H C <keydet89@yahoo.com>
Subject: Flushing DLLs follow-up
To: forensics@securityfocus.com, focus-ms@securityfocus.com

I'd like to thank everyone who's responded to my query
thus far, both on the lists as well as directly to me.
 I also contacted some other folks off-list and I'd
like to share the outcome of what I've found, and
perhaps invite discussion...

The reason I asked the question about flushing DLLs
was some research I've been doing into conducting
'live' forensics investigations on NT/2K (and
ultimately XP). The "what to look for" issue isn't as
sticky as the "how to look for it" one. In my reading
I came across Dominique Brezinski's presentation from
Blackhat '99.

http://www.blackhat.com/html/bh-usa-99/bh3-speakers.html

This presentation went right along with Rob Lee's web
site, http://www.incident-response.org. Seeing that
so much work has been done on Linux, *BSD, and *nix, I
wanted to see if I could fill the gap for the MS
platforms...provide a Win32 TCT, of sorts.

Thanks to folks like JD Glaser, Mark Russinovich, Dave
Roth, Todd Sabin, and many, many more, tools are not a
problem. So I started to look at the issue of
statically-linked binaries. How does one go about
this without recompiling all of the tools, many of
which the source is not readily available? Well, I
decided, based on Dominique's presentation, one didn't
have to. Simply run the tool, and use either
listdlls.exe, or depends.exe from the RK, and then
copy the tools and all of the DLLs it uses to CD.
Sounds good so far.

However, when approaching a system that is to be
investigated, the current state of the machine is in
question.

At this point, I would like to point out as a matter
of distinction that I am referring to 'live' forensics
investigations...collecting volatile data from a
system. I am not referring to taking the system down
and making a bit-image copy of the drive.

An active NT/2K system has many DLLs loaded into
memory, and these libraries provide functions that the
applications can call and make use of. However, L0pht
pointed out a vulnerability that would allow an
attacker to load trojaned DLLs into memory. So this
is something we need to be careful of...if the
investigator is trying to get a process listing, for
example, perhaps a DLL could be trojaned to prevent
the investigator from viewing certain processes.

So the idea may be to flush all of the currently
loaded DLLs from memory before running any of the
investigative tools. However, thanks to JD and
others, I've come to the conclusion that this is NOT
something the investigator wants to do. JD put it
simply...removing the DLLs that the currently loaded
apps are relying on will cause GPFs...for those of you
too young to remember Win3.1, that's a "BAD
THING"(tm).

After all, doesn't the investigator want to know which
DLLs are loaded and being used? Using a combination
of pslist.exe, pulist.exe (from the RK), whoami.exe
(also from the RK), fport.exe and listdlls.exe, the
investigator can get a pretty good idea of what's
going on on the box.

Sure, if the question comes up (ie, "Is it possible
that a DLL could have been trojaned to provide false
information?"), the answer would be 'yes, it's
possible.' However, the investigator should use his
knowledge, experience, and most importantly, a
methodology to minimize the risk associated with such
things.

This, of course, also builds an excellent argument for
admins using tripwire-like utilities to build a
listing of files in the system32 dir (plus a few
others), and generate MD5 and SHA1 hashes for each of
them. Throw the appropriate ACLs and auditing into
the mix, and you've got a good chance of not only
preventing and detecting attempts to install trojaned
DLLs, but you've also provided meaningful information
for the investigator to use.

Again, thanks to all of you who responded. I really
appreciate it. If anyone wishes to pursue this
discussion, I'd be happy respond via the lists or
email...

Carv

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

Relevant Pages

  • RE: MDAC
    ... although you should check it has uninistalled correcty ... The MDAC component checker will also lists all the DLLs that may need ...
    (microsoft.public.sqlserver.server)
  • Re: Small documentation issue
    ... > states that "You will need to ship all the following files" and then ... > lists 4 DLLs. ... Prev by Date: ...
    (comp.lang.smalltalk.dolphin)
  • Re: Flushing DLLs from memory
    ... Subject: Flushing DLLs from memory ... > simple for NT/2K. ...
    (Focus-Microsoft)
  • Re: How do I install a DLL based COM server?
    ... it to find dependncies of my COM server .dll file, but all it lists is: ... separate Microsoft SDK I am using. ... Why doesn't "Depends" see those DLLs? ...
    (microsoft.public.vc.atl)
  • Re: Small documentation issue
    ... James Foster wrote: ... states that "You will need to ship all the following files" and then lists 4 ... DLLs. ... I think it should read "You may need to ship some or all of the ...
    (comp.lang.smalltalk.dolphin)