Playing in the Devil's Playground Dominique Brezinski dbrez@cortland.com 11/21/2018

Operating in an untrustworthy environment Simple things can be technical challenges 11/21/2018

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 NT Shared 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 - Solaris Shared 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