1 / 21

Playing in the Devil's Playground

Playing in the Devil's Playground. Dominique Brezinski dbrez@cortland.com. Operating in an untrustworthy environment. Simple things can be technical challenges. Forensic Analysis Requires Integrity. Integrity of data Integrity of findings Accountability for all actions. Objective.

ciaran-fry
Download Presentation

Playing in the Devil's Playground

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Playing in the Devil's Playground Dominique Brezinski dbrez@cortland.com

  2. Operating in an untrustworthy environment Simple things can be technical challenges

  3. Forensic Analysis Requires Integrity • Integrity of data • Integrity of findings • Accountability for all actions

  4. 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

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

  6. 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

  7. 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

  8. 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.

  9. 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

  10. 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

  11. 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

  12. 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)

  13. 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

  14. 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

  15. 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

  16. But Wait • Shared objects can be modified • System calls can be hooked • kernel can be modified

  17. 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)

  18. What We Can Not Do • Verify that system calls have not been hooked • Verify that the kernel has not been modified

  19. 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

  20. 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

  21. 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

More Related