ee579u/8 #1 spring 2004 © 2000-2004, richard a. stanley ee579u information systems security and...

Spring 2004© 2000-2004, Richard A. Stanley

EE579U/8 #1

EE579UInformation Systems Security

and Management8: Computer Forensics

Professor Richard A. Stanley


EE579U/8 #2

Overview of Today’s Class

• Review of last class• Computer forensics (adapted in part from Farmer & Venema)


EE579U/8 #3

Last time…

• The law is increasingly an issue about which information security professionals must be aware and knowledgeable

• Law is a complex topic, and expert help is needed to succeed here

• That said, you need to remain “on top of” what is going on in the legal domain


EE579U/8 #4

Computer Forensics

• Gathering and analyzing data in a manner as free from distortion or bias as possible to reconstruct data or what has happened in the past on a system

• This is the computer analogue to “CSI” or “Quincy”


EE579U/8 #5

Big Issues

• Systems are huge, complex, changing• Things can hide anywhere• Very little technical knowledge available• Not much software available to help• Knowledge & experience are important• Gathering data relatively easy, but analysis much

harder & time-consuming• Storage: what to do with what you find?


EE579U/8 #6

Requirements for Forensic Examiners

• Technical awareness

• Knowing implications of your actions

• Understand how data can be modified

• Need to be clever, open-minded, devious

• Need to be highly ethical

• Continuing education, historical knowledge

• Crawl to conclusions using redundant data


EE579U/8 #7

What to Do With a “Situation”

• Secure and isolate the affected system(s)

• Record the scene

• Conduct systematic search for evidence

• Collect and package evidence

• Maintain chain of custody!


EE579U/8 #8

Basic Considerations

• Speed is of the essence, but don’t overdo it

• Anything done to a system disturbs it

• You can never trust the system

• Your policies must always be considered

• Accept that there will be failures

• Prepare to be surprised


EE579U/8 #9

Searching for Evidence

• Preserving the system state– “Best Practices”

• You cannot know the past unless you witnessed it, and maybe not even then

• The present is tricky, too

• Always collect data in accordance with its volatility


EE579U/8 #10

Order of Volatility

• Registers, peripheral memory, caches, etc.

• Memory

• Network state

• Running processes

• Disks

• Removable magnetic media

• CD-ROMs, DVDs, printed media, etc.


EE579U/8 #11

Major Problems

• You aren’t clairvoyant

• You don’t know what happened

• You don’t know who or what you are up against

• You don’t know who or what to trust

• Harder problems require more preparation

• Heisenberg’s Principle


EE579U/8 #12

Heisenberg’s Principle Applied to System Analysis

• Real impossible to know both momentum and location of a particle; examining one affects the other.

• Computers examining or collecting one part of the system will disturb other components. It is impossible to completely capture the entire system at any point in time.


EE579U/8 #13

If You Don’t Know the System

• Know your limitations

• It is easy to damage evidence

• If automation exists, data collection is possible but not assured

• Even simple analysis can be dangerous

• Ask for help


EE579U/8 #14

Planning

• Think!– Hurrying up can speed failure

• Security policy?• Set goals• Whom to contact? (See policy)• Assume the worst• Document all your actions• Work with copies of original data as much as

possible—keep the original pristine


EE579U/8 #15

Rough TimelinesAction Taken Expertise Req’d Time Needed

Go back to work None 1+ hours

Minimal work Install sys s/w ½ - 1 day

Minimum recommended

Jr. System Administrator

1 – 2 days

Serious effort System Admin. 2+ days to weeks

Fanaticism Expert SysAdmin Weeks to months


EE579U/8 #16

Reconstruction

• Most data has time-based component

• Some times are fuzzier than others

• Construct a timeline– Determine if system times are in synch

• Examine a window in time

• Try to determine what happened in that window


EE579U/8 #17

Whom to Contact?

• Follow your security policy

• Possibilities– Organizational security staff– Management– CERT? (This makes it public)– Law enforcement?


EE579U/8 #18

Other Problem Areas

• Multiple attacks at once can be confusing

• Same incident can involve multiple parties

• Separate incidents can involve multiple or single parties

• Important to tie events to the right data

• With multiple investigators, tying the evidence together gets tricky


EE579U/8 #19

What About IDS?

• Not widely used

• If properly set up, may provide some useful data

• Can mask events if not properly interpreted

• No panacea, and may make things worse


EE579U/8 #20

Primary Goal

Strive to capture as accurate a representation of the system(s), as free from distortion and

bias, as possible


EE579U/8 #21

Can You Trust Your Data If You Can’t Trust Your Tools?

• Compromised kernel = game over?

• Chain of trust

• Carrying your own toolkit

• Online versus offline


EE579U/8 #22

Chain of Trust (What happens when you run a binary)

• Shell (including environment variables)

• Command

• Dynamic libraries

• Device drivers

• Kernel

• Controllers

• Hardware


EE579U/8 #23

Portable Toolkit

• May or may not help

• Has to be ready before needed

• You must know the system

• Software tools

• O/S distribution media for O/S affected

• Laptop, media, etc.


EE579U/8 #24

Offline vs. Online

• Some things can’t be done

• Not working with original data/system

• Fewer time restrictions

• Errors in replication or interpretation of data

• Often not possible to backtrack


EE579U/8 #25

How & What to Collect (In Theory)

• Take system offline (but not power off)• Record everything you type or do• Consider space restrictions• Collect first, analyze later• Record hardware, software, system config.• Automation saves time, provides consistency• Follow order of volatility• Make copies (including tools), and safeguard them


EE579U/8 #26

Memory

• Image of memory

• Be cautious of memory-mapped devices or holes in memory


EE579U/8 #27

Power Management

• Saves most states to disk

• Very popular, especially on laptops

• Very O/S dependent

• Kernel & device driver support required

• Requires duplicate hardware to reuse

• Promising data source


EE579U/8 #28

Local Network Information

• All local states, such as– netstat– route– arp– kernel info– logfiles


EE579U/8 #29

Remote Network Information

• Router logs

• Portmasters, dialup equipment, etc.

• Sniffer/tcpdump

• Server information

• Any host data that may be interesting– All information collected for the host under

investigation


EE579U/8 #30

Processes

• What is running?

• Capture state and binary


EE579U/8 #31

Data From Disks

• NFS file data from server

• Dump all filesystems if possible

• MD all files

• Capture all directories

• Log files, system configurations, important files

• Kernel copy, dumps, core files


EE579U/8 #32

Hardware, etc.

• Image all EEPROMS

• Capture hardware revisions

• Capture software revisions– Patches, etc.


EE579U/8 #33

Auditing

• Host and network based audit– From system and externally– COPS/Tiger/SATAN/ISS, etc.

• Port scan

• Audit only after capturing all other info


EE579U/8 #34

Backups

• Recover and copy everything

• Don’t work with original data– It’s evidence– Crucial to investigation

• Costly and slow to examine


EE579U/8 #35

Reconstruct User Activity

• Want to know interesting activity

• Reconstruct what was typed/input

• Determine what happened

• Understand/determine damage done

• Have access to all files used


EE579U/8 #36

No Single Method Dominates

• Must begin with a time frame

• Combine tactics and tools to reconstruct activity– Correlation is the key to success

• Can’t get everything, but may get enough


EE579U/8 #37

Typical Intruder M.O.

• Reconnaissance

• Strike

• Do the break-in

• Hide tracks

• Get out of Dodge


EE579U/8 #38

Tools and Methods

• Network sniffing

• Shell history

• Process accounting

• Log files

• MAC times


EE579U/8 #39

Network Sniffing

• Can capture nearly all network traffic• Hard for intruder to detect• Simply logging connections is helpful• Useless against dialups, etc.• High-speed networks pose problems• Best as standalone monitoring system• Requires lots of storage for captured data• Sniffer must be protected• Encrypted/hidden connections pose problems


EE579U/8 #40

Shell History

• Some shells generate upon logout

• Command line, exactly as typed

• Fooled/bypassed by subshell or environ var

• Easily modified

• Commands within scripts not recorded

• Examine shell process memory


EE579U/8 #41

Process Accounting

• Very complete

• Hard to read without automation

• Sorted by end of execution– Will miss commands still running

• Easy to turn off, delete, change


EE579U/8 #42

Log Files

• Goldilocks’ problem

• Network logs

• TCP wrappers

• Daemons, program, kernel logs


EE579U/8 #43

MAC times (Unix)

• atime last access time

• mtime last modify time

• ctime last status change time

• Volatile

• If present & unaltered, these are invaluable


EE579U/8 #44

The Coroner’s Toolkit

• Collection of tools that gather and analyze data on a UNIX system

• Software tools included– grave-robber– lazarus– Other tools that help with analysis, such as unrm, which makes a copy of all free disk space


EE579U/8 #45

Grave Robber

• Automated way of collecting forensic info• Gathers, in order

– Memory– Unallocated filesystem– netstat, route, arp, etc.– All process data– Stat & MD5 on all files, strings on directories– Config, log, interesting files (cron, at, etc.)


EE579U/8 #46

Hiding Data

• Hiding in plain site

• Trivial to hide things this way

• Difficult to find

• Cryptography/steganography

• Embedded data in valid files


EE579U/8 #47

Finding Hidden Data is Slow

• Mountains of data to search

• Files and structure have a reason

• Difficult to automate analysis

• Collection slow, analysis slower


EE579U/8 #48

Types of Data

• Unallocated files

• Used filesystem

• Memory

• Swap


EE579U/8 #49

Lazarus Functionality

• Data reconstruction based on content

• Brings structure to unstructured data

• Pattern recognition

• Data broken into files

• Hypertext user interface

• Enables browsing of data


EE579U/8 #50

How Good Is It?

• It depends…

• Small files are easy

• Large files are not, unless they have a regular format or type that is easy to recognize

• Size of file vs. size filesystem

• It should get all data, which will take awhile


EE579U/8 #51

Algorithm

• Examine first 100 bytes of data block• IF(text), try regular expressions• IF(binary), use file(1)• IF(last block analyzed was same as current block),

append• ELSE create new file

• Post processing for further analysis


EE579U/8 #52

Post Processing

• Standard Unix tools

• Reconstructing mail files

• Text-based log files

• Correlator

• File sanity checking


EE579U/8 #53

Validity of Results

• Poor reliability

• Easy to miscategorize of miss data

• Analysis fraught with peril

• Conclusions based on this approach are probably most unreliable of all


EE579U/8 #54

Identifying an Unknown Program

• Run it, and see what happens

• Run it on a sacrificial machine

• Static analysis of program code

• Details will be operating system specific


EE579U/8 #55

File Analysis Tools

• strings: show cleartext strings embedded in any file

• grep: search for regular expressions• file: identify file content by looking at part of

the data• nm: display compiler and runtime linker symbol

table• ldd: identify dynamic libraries used (careful!)• Debuggers, disassemblers: if all else fails


EE579U/8 #56

Using Available Resources

• The Web is valuable resource. Many hostile exploits can be found with a mouse click or two

• Be careful of grabbing Trojan Horses


EE579U/8 #57

BEFORE an Incident• Have a good security policy• Learn your systems• Turn on logging and accounting• Create a baseline• Audit systems regularly• Learn how systems are abused• Know how to gather forensic data• Backup regularly• Know your neighbors• Know whom to contact in an emergency


EE579U/8 #58

Security Policy

• Most important element

• Well document, consistent systems

• Keep up-to-date with patches, tools, education


EE579U/8 #59

Incident Response

• Should be dealt with in your security policy• Think out all the options first

– Do you want law enforcement involved?– Must they be involved?

• Notifying agencies like CERT tends to make violations public– Weigh the public good versus your private

needs


EE579U/8 #60

Summary

• Gathering forensic information from computers is difficult and time-consuming

• You must preserve the chain of custody of evidence or your efforts are in vain

• Tools exist to help with the hard stuff

• Crawl to conclusions—it is easy to become enamored of the first theory to pop up


EE579U/8 #61

Homework

• The lecture has focused on Unix tools for data forensics. Identify and discuss the use of tools for forensic analysis of Windows 2000 systems. Compare and contrast these tools with the Unix tools described in the lecture and any other Unix forensic tools you come across.

ee579u/8 #1 spring 2004 © 2000-2004, richard a. stanley ee579u information systems security and...

Documents