Linux Kernel Rootkit Detection and Analysis during Incident Response

1
Linux Kernel Rootkit Detection and Analysis
during Incident Response

• Gabriel Lawrence
• UCSD
• October 19, 2007

2
Who am I

• gabriel lawrence
• director IT security at UC San Diego
• background developing secure applications
• manage UCSD CIRT team

3
Why do we take RAM Images?

• part of our CIRT process includes live collection
  of memory contents
• we didn't really have any tools to do much with
  it
• some nice tools on Windows and Linux that do live
  things not forensically sound
• just in RAM malware is becoming more prevalent

4
Agenda

• overview of incident response
• rootkits
• rootkit fighting
• RAM analysis
• new tool - 99lb

5
Incident Response

• monitoring, detecting, and responding to security
  events
• process
• event discovered
• determine criticality of event
• assemble team
• information collection
• analysis
• remediation

6
Information Collection

• collect, preserve, and analyze event data
• should document a provable chain of custody
• live and dead data
• minimize impact to system
• document all activities on live system
• one shot at live data

7
Live data

• running processes
• open ports
• bit-image copy of RAM
• file system metadata
• file system timeline (sometimes)
• Windows event logs (annoying binary format)

8
Dead data

• bit-image copy of storage
• timeline
• logs
• malware
• hidden data
• network logs
• firewall logs
• IDS
• off system logs

9
Tools

• examples
• EnCase
• Forensic Toolkit
• Helix
• tend to focus on dead data
• only useful if malware hits the disk
• trend towards adaptive malware
• Stormworm
• Meterpreter
• RAM analysis
• strings?
• brute force searching
• no context

10
Rootkits

• malware that changes the way a system works
• obscure compromise
• clean log files
• hide processes
• hide network traffic
• hide files
• collect information
• key logging
• network traffic logging
• data collection

11
Different types

• binary replacement
• library replacement
• Kernel modification
• Interrupt Table
• Syscall Table
• Syscall Handler
• RAM modification
• other kernel structures

12
Rootkit v1

• change critical system commands
• ps, netstat, w, passwd, ssh, sshd...
• functionality of commands changed to do rootkit
  job
• change functionality of libraries
• Still very successful
• ssh/sshd
• Example LRK
• http//packetstormsecurity.org/UNIX/penetration/ro
  otkits/lrk5.src.tar.gz

13
Syscalls

• API between user space and kernel space
• implementation of system calls is architecture
  dependant
• standard x86 mechanism
• syscalls are identified by a number
• this number is stored in eax register
• software interrupt is invoked
• IDT points to syscall handler
• syscall handler runs to handle interrupt
• uses eax to dispatch to the syscall

14

• http//www.ibm.com/developerworks/linux/library/l-
  system-calls/

15
Rootkit v2

• attack the kernel
• Phrack 50 - Redirect a syscall, halflife 1997
• save the old address
• set a new one
• do nasty
• call the original code
• http//www.phrack.org/issues.html?issue50id5ar
  ticle
• Linux kernel module
• example Knark - http//packetstormsecurity.org/UNI
  X/penetration/rootkits/knark-2.4.3.tgz

16
Rootkit v3

• Runtime kernel kmem patching Silvio Cesare 1998
• /dev/kmem read/write access to kernel memory
• do whatever you want very version/platform
  specific
• http//vx.netlux.org/lib/vsc07.htmlp5
• example SucKIT http//www.phrack.org/issues.html
  ?issue58id7article

17
Rootkit v4

• SysCall redirection without modifying the
  SysCall table Silvio Cesare 1999
• http//vx.netlux.org/lib/vsc05.html
• Modify the syscall handler or the code of the
  syscall
• Linux on-the-fly kernel patching without LKM
• http//www.phrack.org/issues.html?issue58id7ar
  ticle
• Example SucKIT, enyelkm http//www.enye-sec.org

18
Rootkit v5

• Phrack 59 IDT manipulation kad 2002
• priv escalation
• key logging, etc...
• http//www.phrack.org/issues.html?issue59id4ar
  ticle

19
Rootkit v6

• mucking with other kernel data structures
• tons of different areas to play with
• networking, processes, files, whatever
• Phrack 61 Page Fault Handler buffer 2003
• stealth very small modifications
• http//www.phrack.org/issues.html?issue61id7ar
  ticle

20
Rootkit v6

• adore mucking with VFS tables
  http//lwn.net/Articles/75990/
• Proc FS
• / FS
• Phrack 63 - hiding processes ubra 2004
• http//www.phrack.org/issues.html?issue63id18
• Moving deeper into kernel structures - scheduler

21
Rootkit v7

• Hypervisor
• Example Blue Pill from Joanna Rutkowska
• shift OS from direct control to virtualized
  environment
• waits for interesting events such as key presses
  and can take action
• actions taken by hypervisor may be visible
• network traffic
• file manipulation

22
Tools to detect rootkits

• rootkit detection is an arms race
• rootkits get better, detection gets better
• different methods
• filesystem integrity checking
• malware detection
• rootkit detection

23
Filesystem Integrity

• Tripwire
• filesystem modifications
• requires known good values
• Aide http//sourceforge.net/projects/aide
• filesystem modifications
• requires known good values
• RPM -V
• filesystem modifications
• Timelines
• filesystem modifications
• National Software Reference Library
  http//www.nsrl.nist.gov/
• filesystem modifications

24
Malware Detection

• Anti-virus
• signature and/or behavior
• SELinux
• OSSEC Open Source Host-based Intrusion Detection
  System

25
Rootkit detectors

• chkrootkit http//www.chkrootkit.org/
• signatures
• anomalies in output of system tools and APIs
• rkhunter http//rkhunter.sourceforge.net/
• signatures of known good and bad software
• signatures of known LKM rootkits
• Samhain http//www.la-samhna.de/samhain/
• Filesystem modification
• IDT
• System call address
• Syscall table
• Proc
• Requires known good values

26
RKUnhooker
27
RKUnhooker
28
RKUnhooker
29
RKUnhooker
30
Problems with existing tools

• based on dead analysis
• signatures
• before the fact work required
• no evidence collection and preservation
• highly invasive
• mostly looking from the outside (Samhain is the
  exception)
• don't help establish what was done

31
Don't get me wrong...

• these tools are great and should be used by
  system administrators.
• but, they don't work for security incident
  responders
• unless they were used before the incident
• the incident is using known malware

32
Back to what started this...

• why take a RAM dump?
• delayed analysis of live system state
• analysis of unknown malware
• analysis of in memory only attack
• so far none of these tools address these needs

33
What we'd want

• Earlier work
• Finding Digital Evidence in Physical Memory
  Mariusz Burdach at 2006 Black Hat Federal
  Conference
• http//www.blackhat.com/presentations/bh-federal-0
  6/BH-Fed-06-Burdach/bh-fed-06-burdach-up.pdf
• http//forensic.seccure.net
• An Analysis Of Linux RAM Forensics - Jorge Mario
  Urrea March 2006
• http//cisr.nps.navy.mil/downloads/theses/06thesis
  _urrea.pdf

34
The basics

• Syscall Table
• IDT
• Syscall Handler
• Code of syscalls/handlers

35
More depth

• Memory Map
• Kernel modules
• Process data structures
• other critical Kernel structures
• swap

36
Collection and analysis

• minimize impact to live system
• document all activities on live system
• document state of live system for future
  analysis/corroboration
• capture as much state as possible
• platform for reverse engineering and analysis of
  compromised machines

37
Imaging RAM in linux

• /proc/kcore
• ELF formatted version of kernel memory
• access to /proc/kcore is blocked by patches in
  many distros
• /dev/mem
• device that gives read/write access to physical
  memory
• access greater then 1mb is blocked by patches in
  many distros
• In current popular distros, access to raw RAM is
  denied

38
Need more then just the bits

• Even if these worked, its just raw RAM
• Need context for running environment
• address of IDT
• Syscall handler
• address of syscall table
• address of interesting kernel structures
• System.map
• created at build time
• address of kernel methods and structures
• how do you know it reflects what is in the system
  now?

39
Finding the Syscall table

• 2.4 kernels exported the syscall_table
• 2.6 doesn't
• well known hack use IDT to find syscall handler
  and search for the address given to the call
  instruction

40
99lb part 1

• Linux loadable kernel module
• exposes kernel data through proc
• locate critical kernel structures
• Built and loaded on compromised machine
• Potentially targeted by malware
• that would be success

41
Constants

• kernel location in RAM
• PAGE_SHIFT
• memory map
• sizeof page structure
• Bunch more about processes
• whatever else makes sense over time

42
IDT

• table of addresses for interrupt handlers
• when an interrupt happens
• Linux gets source from programmable interrupt
  controllers
• translates source into offset of irq_action
  vector
• irq_action has address of handler
• linux calls handler

43
Syscall Handler Address

• interrupt 0x80 is the syscall handler
• found by looking in IDT from above
• because of its importance, pulled out into its
  own file
• pointer to the code executed to invoke a syscall

44
Syscall Table

• file that holds address and syscall number for
  every syscall
• number of entries varies by kernel version
• module uses data from kernel include file to
  figure out how many syscalls to show

45
Modules

• instrumentation of list of struct module
• module name
• module start address
• size
• exit function

46
Processes

• instrumentation of task_struct
• address of task_struct
• task command
• pid

47
Mem

• port of read portion of /dev/mem
• none of that pesky annoying security
• the bad guys dont have to deal with it, so why
  should the good guys?

48
99lb part 2

• data collection script
• Bash shell
• uses subset of on system commands
• creates log of all actions
• preserves binaries used to collect information
• collects live data outside the kernel
• useful for comparison and understanding if some
  information is being obfuscated

49
99lb part 3

• analyzer
• python/pygtk/libdisasm GUI to view and analyze
  extracted information
• point and click call graphs
• analysis of where calls go
• code branches into unknown places will reveal
  interesting things
• comparison of data from tools and from kernel
  structures

50
Demos

• view structures of healthy system
• patched syscall handler
• hidden process

51
(No Transcript)
52
(No Transcript)
53
(No Transcript)
54
(No Transcript)
55
Whats next?

• more instrumentation
• network structures
• scheduler information
• VFS structures
• strings searches
• data collection
• process memory extraction
• malware detection
• ClamAV
• signatures
• be the platform for forensic sound analysis of
  data from live systems

56

• http//sourceforge.net/projects/the99lb/