04/19/23

Playing in the Devil's PlaygroundDominique Brezinskidbrez@cortland.com

04/19/23

Operating in an untrustworthy environmentSimple things can be technical challenges

Forensic Analysis Requires Integrity Integrity of data Integrity of findings Accountability for all actions

Objective Don’t cause more damage than already has

occurred Carry out necessary operations to gather

first round of evidence Preserve evidence gathered from system

state and on disk

Today’s Situation Systems are not tamper resistant Most utilities are dynamically linked Systems are very complex CD-ROM writers are cheap

Common Failures in Forensic Analysis Administrator or investigator executes

various binaries that are on the compromised host while running as superuser

Administrator or investigator modifies data inadvertently while trying to gather evidence

Investigator fails to keep an evidentiary trail or record of actions

Available Options Statically link all your tools in your forensic

toolkit and burn them to a CD Create an environment which forces your

dynamically linked utilities to only use shared code on your CD

Statically linked tools are better and easier to use, but not possible for most commercial operating systems

Example One - Windows NTShared Code Search Path: The directory from which the application loaded. The current directory. SYSTEM32. SYSTEM. The Windows directory (WINNT). The directories that are listed in the PATH

environment variable.

But Wait The system creates an in-memory cache of

commonly used DLLs at system startup The system checks the \KnownDlls object

directory first, and if the DLL is present it maps the memory cached version (section) into the processes’ memory space

Even More... Other mechanisms inject DLLs into every

running application process (see JD Glaser’s presentation for the scoop on the problem he found)

System functions can be hooked and their functionality modified

What Can We Do? Delete the sections (cached DLLs) in the \

KnownDlls object directory Remove the DLLs from HKLM/Software/microsoft/windows

nt/currentversion/windows/appinit_dlls

Put known good versions of the required DLLs in the directory on the CD where you run your tools from

Pray

What We Can Not Do Verify that system calls have not

been hooked Verify that kernel components have

not been modified (prior to doing disk analysis at least)

Recommendations for NT Create a CD with all your utilities, system

commands, cmd.exe, and all the DLLs you will need

Use dumpbin.exe /imports to identify the DLLs used by an application

Run a program off the CD that deletes the sections in the \KnownDlls directory that correspond to the DLLs you need and clean the appropriate Registry keys

Recommendations Continued Run cmd.exe off of the CD to get a shell to

work from Run as few commands as possible prior to

making a binary copy of the hard drive (two copies is even better)

Go to JD Glaser’s presentation for more specifics on NT forensic analysis

Example Two - SolarisShared code search path: colon separated directory list specified by

LD_LIBRARY_PATH environment variable runpath specified during application

compilation and linking /usr/lib

But Wait Shared objects can be modified System calls can be hooked kernel can be modified

What Can We Do? Place known good copies of all the shared

objects you need on a CD Create LD_LIBRARY_PATH in your

environment that specifies the directory on your CD that contains the shared objects (/cdrom/so for example)

What We Can Not Do Verify that system calls have not been

hooked Verify that the kernel has not been modified

Recommendations for Solaris Create a CD with all your forensic tools, system

commands, shell, and shared objects Use ldd or truss to determine shared object

dependencies (man ldd for security relevant info) Create or modify the LD_LIBRARY_PATH environment

variable to only include your CD shared object directory Execute your shell on the CD Minimize the actions you take before making a binary

image or two of the HD

Conclusions There are no truly safe solutions You can protect yourself from many user land

threats, but not all Modified kernels are the devil’s work, and you

don’t want to dance with the devil Take your time and think about the

ramifications of your actions Test out your techniques before taking them

live

Resources Http://www.rootkit.com/ Http://www.rootkit.com/papers/adding.doc Solaris man pages (ld.so.1, ldd, truss) Http://www.l0pht.com/

Thanks to Greg Hoglund, JD Glaser, LJH, Dil, and Jeremy Rauch

No thanks to Mark Russinovic