King Fahd University of Petroleum and Minerals Department of Computer Engineering

1. King Fahd University of Petroleum and Minerals Department of Computer Engineering COE589: Digital Forensics Student name : Allam Fatayer Student ID: g20100372

2. Forensics Examination of Volatile System DataUsing Virtual Introspection Brian Hay Kara Nance Department of Computer Science University of Alaska Fairbanks Fairbanks, AK 99775-6670 {brian.hay, ffkln}@uaf.edu

3. Outline • Motivation • Traditional static analysis • Live analysis • Virtualization • Xen • Virtual Introspection (VI) • Virtual Introspection for Xen(VIX) • Future Work • Conclusion Virtualization

4. Motivation • There are often important system properties present only in volatile memory. • The live analysis of target systems as observation techniques are generally intrusive and can affect the system being observed.

5. Static Analysis • Traditional static analysis techniques have the ability to unearth tremendous volumes of data. • This approach typically involves powering the target system down and creating a forensically valid copy of the digital media.

6. Static Analysis • There are many system properties which cannot be retained and examined as part of a forensics analysis using these techniques. • Such as the process list, open network ports, installed kernel modules, and volatile memory contents

7. Live Analysis ( Solution) • An investigator performs a forensic examination of a system while it is in a running state. • Cannot examine a live system without making some change to it

8. Live Analysis(Challenges and Risks) • All of these activities change the state of the system, and as such may contaminate the evidence • The investigator logs on to the target system • Logs are recorded, temporary files are created and deleted • Network connections can be opened and closed • History files are updated • Registry entries are queried, added, and modified

9. Live Analysis(Challenges and Risks) • A compromised host may have a rootkit installed which will attempt to hide evidence. • Such as open network ports, user accounts, or the presence of files and folders in a file system. • A system could be configured to detect a live analysis attempt

10. Live Analysis(Hardware Solution) • Some hardware based devices are available that aim to address the danger inherent in live analysis by using the DMA controller to acquire the contents of system memory without operating system or CPU interaction • Could actually be presented with a different view of memory than that seen by the CPU

11. What is virtualization? • Virtualization is way to run multiple operating systems and user applications on the same hardware • E.g., run both Windows and Linux on the same laptop • How is it different from dual-boot? • Both OSes run simultaneously • The OSes are completely isolated from each other

12. Uses of virtualization • Server consolidation • Run a web server and a mail server on the same physical server • Easier development • Develop critical operating system components (file system, disk driver) without affecting computer stability • Testing • Testing a network product (e.g., a firewall) may require tens of computers • Try testing thoroughly a product at each pre-release milestone… and have a straight face when your boss shows you the electricity bill • Cloud computing • The modern buzz-word • Amazon sells computing power • You pay for e.g., 2 CPU cores for 3 hours plus 10GB of network traffic

13. Type 2 (hosted) Type 1 (bare-metal) VM1 VM2 Guest Process Hypervisor Guest OS VM1 VM2 Host Host Hardware Hypervisor Hardware VMware ESX, Microsoft Hyper-V, Xen VMware Workstation, Microsoft Virtual PC, Sun VirtualBox, QEMU, KVM Virt(Two types of hypervisors) • Definitions • Hypervisor (or VMM – Virtual Machine Monitor) is a software layer that allows several virtual machines to run on a physical machine • The physical OS and hardware are called the Host • The virtual machine OS and applications are called the Guest

14. Bare-metal or hosted? • Bare-metal • Has complete control over hardware • Doesn’t have to “fight” an OS • Hosted • Avoid code duplication: need not code a process scheduler, memory management system – the OS already does that • Can run native processesalongside VMs • Familiar environment – how much CPU and memory does a VM take? Use top! How big is the virtual disk? ls –l • Easy management – stop a VM? Sure, just kill it! • A combination • Mostly hosted, but some parts are inside the OS kernel for performance reasons • E.g., KVM

15. Xen’s Approach (1) • Instead of making the virtual machine 100% functionally identical to the bare hardware, Xen makes use of Para virtualization • Para virtualization is a process where the guest operating system is modified to run in parallel with other modified systems, and is designed to execute on a virtual machine that has a ‘similar’ architecture to the underlying machine. • In Xen today we have two choices • User domains may either be unmodified open-source or proprietary operating systems • modified, para-virtualized operating system with special drivers that support enhanced Xen features.

16. Xen - Structure (2) • “Domain 0” • has special access to control interface for platform management • Has back-end device drivers • Xen VMM • entirely event driven • no internal threads Xen 3.0 Architecture CS5204 – Operating Systems

17. Xen’s Design Approach (3)

18. Xen: Notation (4) • Guest Operating System • The OS software that Xen hosts • Domain • The virtual machine within which a guest operating system executes • Guest OS’es and domains are analogous to a program and a process • Hypervisor • This is the instance of Xen that handles all of the low level functionally

19. Xen (5) (how does Xen perform its magic?) • The Xen papers discusses the following areas • CPU • Virtualization of the CPU • CPU Scheduling • Time & Timers • Memory Management • Virtual Address Translation • Physical Memory • Device I/O • Network • Disk • Control Transfer

20. Xen and the CPU(6) • This undoubtedly where the most change is required by the guest OS • Xen challenges the assumption that the OS is the most privileged entity • Privileged instructions • These are paravirtualized by requiring them to be validated/executed within Xen

21. Xen and the CPU(7) • The x86 is less difficult than most systems to virtualize • This is due to the built in security levels build within the x86 (known as rings) • Most systems have the OS running on ring 0 (the most privileged) • Most user software runs on ring 3 • Ring 1 & 2 generally are not used • Xen uses this fact to modify the OS to execute on ring 1

22. Xen, Scheduling, and Timers(8) • Xen currently uses an algorithm called the Borrowed Virtual Time algorithm to schedule domains • This is important to mitigate the problem of one domain executing code that can adversely affect another domain. • Xen also provides several different types of timers • Real Time (time that always advances regardless of the executing domain) • Virtual Time (time that only advances within the context of the domain) • Wall Clock Time (time that takes in to account local offsets for time zone and DST)

23. Control transfer & Eventing(9) • Exceptions and Eventing • These include memory faults and software traps • These are generally virtualized through Xen’s event handler • Typically the two most frequent exceptions that occur (enough to effect performance) • System Calls • Page Faults • These are two examples of a ‘fast’ handler (one in which bypasses the hypervisor)

24. Paravirtualization of the MMU(10) Paravirtualization Full Virtualization Diagrams provided by a presentation from the Universität Karlsruhe

25. Xen and Virtual Memory(11) • When the guest OS requires a new page table, it allocates it from its own memory reservoir • After this it is registered with Xen • The OS then gives up all direct write privleges to the memory • All subsequent updates must be validated by Xen • Guest OS’s generally batch these update requests to spread the cost of calling the hypervisor • Segmentation is virtualized in a similar way

26. Xen and Virtual Memory(12) • Xen uses a design where • Guest OS’s are responsible for allocation and managing hardware pages • Xen exists in a generally unused section at the top of every address space. This is to ensure that the Xen is never paged out • This differs from the approach that Disco takes where the Disco VMM keeps a second level of indirection. • Essentially VMM within VMM

27. Xen and Device I/O/ Management(13) • Data I/O is transferred to and from domains via Xen through the use of a buffer descriptor ring • This is a system that is based around a pair of producer consumer pointers, one set used within the guest OS, the other within the Hypervisor • This allows for the decoupling of when data arrives/is accessed and the event notification

28. Control of the Hypervisor(14) • Domain0 is given greater access to the hardware (and hypervisor). It has a guest OS running on top of it as well, but also has additional “supervisor” software to manage elements of the other existing domains. • This is different than VMWare which has the notion of a Host OS acting underneath it.

29. Building a new Domain on Xen • Domain0 is a privileged domain • New domain creation is delegated to Domain0 • This offers the advantage of reducing the complexity of the hypervisor • Additionally building new domains that originate from Domain0 allow for a better debug environment

30. Virtual Introspection • Virtual Introspection (VI) is the process by which the state of a virtual machine (VM) is observed from either the Virtual Machine Monitor (VMM), or from some virtual machine other than the one being examined.

31. VI(Investigation) • The target of an investigation is a virtual machine, or set of virtual machines. • To perform live system analysis in such a manner that the state of the target system remains unchanged. • To perform the analysis in such a way that the target system would be unable to detect the monitoring.

32. VI(Investigation) • Whether some approach could allow the target system to detect the virtual introspection monitoring • Timing analysis • Page fault analysis

33. VI(VM Determined) • In all major virtualization products available today it is possible for a user to reliably determine that the operating system is running on a VM rather than directly on physical hardware.

34. VI(Honeypot System) • VMs were used more commonly as honeypots than production systems, so that attackers may assume that they found a honeypot system rather than a production host. • It may lead the attacker to attempt to break out of the virtual environment through vulnerabilities in the VMM

35. Virtual Introspection for Xen (VIX) • Open-source software • Allow the researchers to modify the VMM (exposed by the Xen Control library) • Under current development • Supports multiple guest operating systems

36. VIX(Open Issue) • The issue of whether VMs can ever be managed by a VMM, while simultaneously being protected from a compromised VMM remains an open research problem.

37. VIX(Basic Approach) • Pauses operation of the target VM • Maps some of its memory into the Dom0 • Acquires and decodes the memory pages • Resumes operation of the target VM • Reference task_struct data structures • process ID, process name, memory map, and execution time • Traverses the list of task_structs

38. VIX(Xen Control library) • The Xen Control library is used to allow the Dom0 system to perform operations on the DomU systems • Pausing the target VM prior to analysis, and un-pausing it afterwards. • Mapping memory pages assigned to the target VM into the address space of the Dom0 system

39. VIX(VMI Functionality) • Not depend on any VM OS functionality for information • VIX application • vix-ps, vix-netstat, vix-lsof, vix-pstrings, vix-lsmod, vix-pmap, and vix-top • vix-ps • Traverse the entire task list • Output as the ps command

40. VIX(Access A Memory Address) • In order to find the appropriate physical frame in memory we must consult the page tables to determine the corresponding physical frame number. • The physical frame numbers from the perspective of the VM must be translated into the physical frame numbers for the underlying physical hardware.

42. VIX(Pseudo-Code for vix-ps)

43. VIX(Decode task_struct) • We cannot assume that data structures present in the Dom0 system match the structures used by the DomU kernel • A kernel module, named getOffsets, has been developed as part of this work, and has been used to determine the appropriate offsets for a variety of example Linux kernels.

44. VIX Example

45. VIX Example

46. Future Work • Support for multiple operating system types. • Particularly Windows • Analysis of the extent to which the virtual introspection techniques can be detected by the target virtual machine. • Timing analysis or page fault monitoring may provide some indication to the target VM • Application of these VI techniques to other virtualization platforms. • In particular the VMware • Applications of these techniques to other domains. • A domain being actively investigated at this time is honeypots. • Development of a framework to allow virtual introspection across physical hosts

47. Conclusions • Virtual Introspection techniques can be utilized by forensics investigators to perform unobtrusive live analysis on target virtual machines • A quantification of the extent to which Virtual Introspection is detectable from the target system

48. Flaws • It is clear that there is no real contribution in the work . • Poor evaluation schema. • Not clear how to collect the evidence in different situation.

49. Thank you

50. Questions