1 / 28

Lesson 13 Unix Forensics

Lesson 13 Unix Forensics . Overview. Basic MO (email sent) System Tools Files System Tools Using the Tools. Basic MO. Only use tools you can trust Consider using tools stored off-line on read-only medium Don’t forget a rogue kernel module can make a compromised system look clean

mikel
Download Presentation

Lesson 13 Unix Forensics

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. Lesson 13Unix Forensics

  2. Overview • Basic MO (email sent) • System Tools • Files System Tools • Using the Tools UTSA IS 6353 Incident Response

  3. Basic MO • Only use tools you can trust • Consider using tools stored off-line on read-only medium • Don’t forget a rogue kernel module can make a compromised system look clean • Hackers who use Unix are considered to be above average threats, innovative, and persistent UTSA IS 6353 Incident Response

  4. Basic System Response Tools(1) • vmstat: provides quick look a memory, CPU, and disk subsystem statistics • mpstat: provides processor utilization statistics • ps: process status, shows processes executing on the system and information about them • top: like ps, but also orders the processes by CPU consumption UTSA IS 6353 Incident Response

  5. Basic System Response Tools(2) • iostat: provides statistics on disk subsystem • sar: displays system perfomance data stored over-time • lastcom: displays commands that have been run on the system UTSA IS 6353 Incident Response

  6. Basic File Tools • lsof: list open files, show all files the operating system has open • file: outputs a list of hex values that indicate the file contents • readelf: displays the executable linking and format headers of a binary file so you can determine what functions the executable performs UTSA IS 6353 Incident Response

  7. Basic File Tools(2) • ldd: reads the contents of the ELF headers to show what shared object libraries the executable depends • strace: starts a process or attaches to a currently running process so you can see all the system calls the process is making(Solaris: truss, BSD: ktrace) UTSA IS 6353 Incident Response

  8. Basic Search Tools(2) • strings: shows ASCII strings >= 4 characters or longer (user specified) in a file • find: recursively searches for objects on the file system—can be useful for finding files or directories based on user specified criteria • grep: global regular expression print—searches a pattern sapce (file) for a user specified pattern UTSA IS 6353 Incident Response

  9. Basic Premise of the Hack • Target Machine is s Webserver running Apache • A Webmaster calls the Incident Response Team to say that the CPU is busy on the server which gets very few daily hits • Your job to prove or dispel that an incident has occured UTSA IS 6353 Incident Response

  10. Tool Usage to Uncover Hacker • Step One: On-line Analysis or off-line analysis? On-line! • vmstat: shows a user process is running • mpstat: memory not being taxed • iostat: very little disk activity • sar: shows CPU started being used at 03:17 • Who could use the CPU at 03:17? • SysAdmin? Easy to confirm UTSA IS 6353 Incident Response

  11. Tool Usage to Uncover Hacker(2) • lastcom: shows FTP was run by root several times • last: shows recent logins, but it doesn’t show where logged in from • top –d1: shows process Apache using CPU 100% • ps –eflcym –headers (for linux) • Shows Apache and multiple httpd processes UTSA IS 6353 Incident Response

  12. Tool Usage to Uncover Hacker(3) • lsof – p • Shows apache process has a file john.pot open • Google search on john.pot points to John the Ripper • Good enough for me to say an incident has occurred—but why stop now? • file apache • Shows apache is an ELF executable UTSA IS 6353 Incident Response

  13. Tool Usage to Uncover Hacker(4) • ldd ./apache • Shows fewer binary links • ldd /usr/sbin/httpd • Shows many more binary links • Looks like apache is a rogue process • String apache|grep – i john • Shows apache is probably the password cracker John the Ripper • So Why would the Webserver need John the Ripper? UTSA IS 6353 Incident Response

  14. So What Do We Know? • The password cracker John the Ripper found on our Web server • Hack “appears” to have occurred at 03:17 AM • But don’t be fooled by time hacks—what is server tine synced with? • Did hacker change the time? UTSA IS 6353 Incident Response

  15. Things to Consider • Tools we will use execute in user space • If root kit changed binaries then tool results could be inaccurate • Do off-line analysis if you suspect • Best approach on “live” systems is to execute from read only media • Ensures the tools aren’t modified by hacker • Knoppix Linux is another useful tool UTSA IS 6353 Incident Response

  16. Off-line Analysis • Unix allows you to mount volumes in read-only mode mount –o loop=/dev/loop0 /var/tmp/testfilesystem /mnt • To find out which file systems supported find /lib/modules/’uname – r’ /kernel/fs/* - type f|grep – v ‘n/s\/’ • To see what file systems are loaded grep –v ‘^nodev’ /proc/filesystems UTSA IS 6353 Incident Response

  17. Mounting A File System Read-Only UTSA IS 6353 Incident Response

  18. NATIVE Linux rpm –Vva Solaris (9.0) pkgchk –vn Debian (3.0) Debsums -ac 3rd Party Tools AIDE Integrit Osiris Tripwire Tools to Detect Changes Tools run periodically and rely on hashes or checksums UTSA IS 6353 Incident Response

  19. Tools to Detect in Real-time • changedfiles • dnotify • FAM • All use kernel modules or poll the file system to detect changes in near realtime UTSA IS 6353 Incident Response

  20. MAC Times • Modify, access, change times • Unix files systems sotre a set of timestamps in their file system metadata • Timestamps stored in inode • mtime, atime, ctime UTSA IS 6353 Incident Response

  21. Using ls to Display MAC times UTSA IS 6353 Incident Response

  22. So Now What? • Search filesystem for files that changed/modified around suspect time # find / \(-mtime +2 –a –mtime -7\) –a –printf “M:%t C:%c %i\t%p\n” Or # find / \(-mtime +2 –a –mtime -7\)|perl –ne ‘chomp; ($i,$m,$c)=(stat)[1,9,10]; printf “M:%s\t$i\t$_\n”,localtime($m).” C:”.localtime($c)’ • Finding broken suid or sgid binary to escalate privilege find / -perm -6000 -ls UTSA IS 6353 Incident Response

  23. Using Find UTSA IS 6353 Incident Response

  24. File System Debugger • fsdb – OpenBSD and Solaris • debugfs – ext2 and ext3 (Linux) • Debugfs <image path> UTSA IS 6353 Incident Response

  25. Steps Investigator Took • First Key Step: on-line or off-line • If off-line mount in read-only mode • Use trusted tools • Use MAC analysis • Use File System Debugger UTSA IS 6353 Incident Response

  26. Summary • Some say Unix Forensics are tougher than Windows Forensics • I agree the command usage is cryptic at time, but a tool is a tool • Tools presented are straight forward • Practice makes perfect UTSA IS 6353 Incident Response

More Related