Superymk:Vis project v1

From Trusted Cloud Group
Jump to: navigation, search

Contents

Update Record

  • 11/25/2010 Add the Evaluation part and Future Work part
  • 11/29/2010 Add Assumption section and Discussion section
  • 11/30/2010 Add Live Forensics Problem in Problem section and part of Related Work section

Publication

  • Miao Yu, Qian Lin, Bingyu Li, Zhengwei Qi, and Haibing Guan
Vis: Virtualization Enhanced Live Acquisition for Native System
The 2nd ACM SIGOPS Asia-Pacific Workshop on Systems (APSys 2011), Shanghai, China, July 11-12 2011.

Author

How to Use

  • Vis is compatible with WIndows XP & Windows 7 x86 version
  • Disable DEP
  • Disable PAE

Overview

Vis is a late-launched agent for host-based system live forensics. It is based on virtualization technology and resides in the VMM layer. Unlike the traditional in-system modules, Vis can conceal itself at runtime. Vis requires no additional hardware or modification to any legacy OS and applications, While keeping the same or a higher effectiveness (NEED CLAIM). Vis's ability is achieved by EPT and several other technologies. Vis also eliminates the "semantic gap" problem by copy the whole OS page table, enabling refer to all kernel objects from VMM layer.

Design Docs

Current State

  • Implementing EPT support, continuing to refactor the whole code base
  • Finding related papers and conferences.

Schedule

  • Now -- 11.14.2010 Complete implementing the hypervisor code base. (done)
  • 11.14 -- 11.30 Complete implementing EPT. (done on 11/26/2010)
  • 11.26 -- 12.14 Reading related materials and finding cases
  • ...
  • Internal Deadline 01.11 Finish the paper.
  • 01.12 -- 02.10.2011 Call for public review.
  • 02.11 Submit

Paper Info

Assumption

  • Native OS booted from bare metal.
  • Not an extremely malicious kernel (e.g. OS with a detecting-and-patching driver loading function)

Problem

Why using live forensics

  • Extremely difficult to get disk image from a distributed file system[3].
  • Shut down a server to get disk image offline is not tolerable for an e-commerce system[3].
  • Offline imaging ignores volatile data like RAM's content. Nowadays, even database tries to hold data in RAM, e.g. sqlite[]
  • In other cases, live analysis is used because the investigator does not want the user being investigated to suspect an investigation is under way [5]

Why not monitoring with the help of Type-I hypervisor

  • The number of cloud computing users is small, compared with that of PC users.[]
  • It's not easy to deploy such monitor methods. [1]
  • The performance impact and the slow boot time can cause users notice [1 and some graphic performance case for Xen]

The difficulty in monitoring the host-based system

  • In traditional ways, monitor agents are lack of self protection. Even if they have one, they are still probable to be discovered and compromised since they resides at the same level with OS kernel as well as rootkits.

Live Forensics Problem

  • From the moment 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, and registry entries are queried, added, and modified. All of these activities change the state of the system, and as such may contaminate the evidence that the investigator hopes to collect. [1]
  • In addition, it is possible that a compromised host may have a rootkit installed which will deliberately attempt to hide evidence [1]
  • In the worst case a system could be configured to detect a live analysis attempt (e.g., suppose that a suspect installed a service that requires a user to hit the escape key within 5 seconds of login to maintain system configurations) and to delete incriminating data if such an attempt was detected. (Vis is aimed to solve this problem)[1]
  • Specialized hardware is available in forensics to collect the raw memory and storage data. [6,7] But it raises the total cost and difficulty in installment.

Contributions

  • To the best of our knowledge, we are the first to use late launched hypervisor to monitor the host-based system, which outweighs previous approach in much easier installation and lower performance impact.
  • We employ lightweight memory virtualization to effectively isolate Vis from untrusted host environment and support basic forensic scenarios with no user suspect.
  • We present the adoption of Vis in practical live forensics scenarios and demonstrate our advantages.

Some claims

  • Computer forensics is much concerned with rootkit detection and inspection. [9]
  • VMM-based IDS takes advantages in three points, isolation, inspection and interposition.[9]
  • Vis uses architecture properties to keep hiding after loaded.

Design

  • Two aspects of integrity need to be taken consideration: static integrity and runtime integrity.[15]
  • How to monitor (Still considering, use cr3 write as monitoring interval? Or focusing on Vis has the ability to intercept certain events?)
  • Semantic Gap Elimination (deprecated)
  • Self Protection

Implementation

Evaluation

Effectiveness Evaluation

  • 1. dd based on Vis [1]
  • 2. TDL4 rootkit detection [2] or FU Rootkit[11] detection

Security Analysis

  • 1. Possible attack method and how Vis hypervisor defend it [Just like the one of CCS'09 HyperSafe]
  • OS directed physic memory scan
  • Force unloading
  • Force remapping GVA to another GPA (This problem originates from Vis using the same page table with the OS )(happens on swapping out and swapping in)(Solution: Disabling write permission on the corresponding ept entries of guest page table. Then if 1. someone wants to change Vis GVA to GPA mapping-->Create private page table (equivalent to copy-on-write mechanism) 2. someone wants to change other GVA to GPA mapping, update it in private page table.)

Performance Evaluation

Microbenchmark

  • 1. Clockticks for each module
  • Method: 1) Test EPT translation overhead (compared with native)
  • 2) Test flush TLB overhead
  • 3) When #VMEXIT happens, there must be overhead due to a)Dispatch event b)Handle event c)#VMResume
  • 4) It must incurs overhead when live forensics logic is implemented
  • 2. Quantify the Memory Usage ( To prove that Vis only needs a few memory space [3])
  • Method:Evaluate in these condition: Uni-processor, 2 processor, 2 processor with HT
  • Result: 1) How many pages are needed for the 1st processor 2) How many pages are needed for additional processor
  • 3. SLOC-P of each module in Vis.

Macrobenchmark

  • CPU-bound benchmark (SPECint2006)
  • IO-bound benchmark (SPECweb or (bonnie++ and netperf)) (Must test both Disk and Network performance)
  • Application benchmark (Apache httpd)

Shortage and Solution

  • Long loading time: Vis requires 8 seconds or so to build EPT table. (This has been optimized. It takes no more than 1 second in the newest version via batching mapping)

Related Work

  • Security application of logging and replay using VMM are discussed in [8]
  • With the same effectiveness, previous work uses split kernel module model [9] is much more complex and much easier to detect its in-VM agent comparing to Vis.
  • LKM-rootkit (Loadable Kernel Module) on Linux and driver based rootkit on Windows
  • [9] needs to modify kernel's source code to achieve system call extension

Discussion

  • Possible detection method
  • Timing-based detection
  • Page fault analysis(A possible solution is mentioned in [10])
  • Semantic gap problem
  • Fake symbol
  • No symbol

Future Work

Use a better way to hide Vis hypervisor's code segment

  • In order to hide the hypervisor's code segment, I use another program to trigger hypercall at current. The reason of why not add a hypercall at the end of driver initialization is quite straight forward: First, the OS driver loading function may need to do something with the driver before all is done. For example, Windows OS may read driver's PE header after DriverEntry() returns. Second, it made us had to leave some code pieces not hiding at all, leaving the possibility of fingerprint based detection in the future.
  • Since the best solution is to hide before Vis finishes its initialization, so the future solution is to leverage #PF and EPT #PF, we only allow certain address from OS to read certain memory pieces in Vis. Otherwise it will be identified as attacking from 3rd party software. But this solution will cause the Vis loading time a little longer.

How to collect all the possible PFNs(Physical frame number) on the machine

  • Luckily there are only 0xfffff PFNs on 32-bit platform. But it will be several orders of magnitude more of PFNs on 64-bit platform. The solution is to read the OS available PFNs and then mapping. But it always requires hacking when migrating Vis to commercial OSes.

It is possible to disable Vis protection mechanism on the fly by an extremely malicious kernel (deprecated)

  • No idea at the moment. Leave this problem to be solved in the future.

Q&A

How to achieve 'great tranparency'

  • The solution is to use Nested Paging (NP) and IOMMU. With NP, I can remap the hypervisor's code and data segment to dummy page by manipulating the additional level page table. Note that the origin OS page table is still in using to achieve GVA to GPA translation, while an additional page table is introduced by NP to finish the GPA to MPA (machine physical address) translation. In this way, OS (now it is a guest OS) can't detect my hypervisor in the way of address scanning, though it knows the total RAM amount and their physical address range.
  • IOMMU is mainly used to protect the hypervisor from hardware-based attack, to be specific, malicious DMA attack. Since DMA can access physical addresses directly and bypass NP due to the architecture limitations, it is possible that the attacker subverts my hypervisor's integrity via DMA polluting. IOMMU can be regarded as enabling paging mechanism in DMA operations. To solve this problem, I use IOMMU and forbid any DMA access to the hypervisor. In this way, I can ensure the hypervisor's aliveness and effectiveness.
  • In conclusion, I think my hypervisor is highly transparent to the guest OS, though it is a late launched one.

The difference in techniques between Vis and newbluepill

  • NewBluePill has the same model with Vis. Unfortunately, it doesn't implement nested paging to achieve a better transparency. Instead, it just modifies the guest OS page table, resulting in the possibility to be detected by the OS kernel. In other ways, OS can also detect NewBluePill with a physical memory scan. This problem is successfully solved in my hypervisor. So I think that NewBluePill can't completely conceal itself if its the code sources are public known. Although no hardware nested page table support is available at their time, they can still use shadow page table to solve this problem as Xen does several years ago. Even that, I admit that their work is significant in building Vis.

Is it possible for existing OS to have some mechanism to detect Vis?

  • In my opinion, It is not probable to detect my hypervisor in theory. In one hand, all the directly timing based detection can be prevented by telling the guest with a fake time stamp value. In the other hand, caching based detection, for example, checking the TLB pollution, may only detect the existence of hypervisor. But it is hard for the detector to tell the running hypervisor is KVM or Xen or my one. But in the condition of a extremely malicious OS, it is possible to detect my hypervisor and even tamper it. For example, if the OS can directly access physical memory by controlling signals, instead of address, it can detect my hypervisor and even remove my hypervisor. Another case is that, with a x86 demoboard, the OS can know the existence of my hypervisor by directly communicating with the host (It is connected with the target board) .
  • An operable detection is based on SMM (System Management Mode) on x86. Without additional hardware, it has a higher privilege than Ring0 and EPT is not enabled when it is executing instructions in SMM. One case is that NMI is handled in SMM, if I remembered correctly. So, if the OS is succeed in putting the detector code and my hypervisor's fingerprint in SMM, the OS can trigger NMI in an interval manner to detect the existence of my hypervisor. However, it is difficult for 3 reasons: First, the size of EPROM to store SMM procs is small. Second, no SMM code is allowed after POST in commercial motherboards. Third, it incurs a significant performance impact for both the slow accessing speed of EPROM ( about 1% of the DRAM accessing speed, I remember) and the high frequency of incurring NMI. And it's still possible for my hypervisor to load and exit, as well as finishing its functionality within one single detecting interval.
  • In conclusion, it is possible but nearly not probable to detect Vis.

Can some OS prevent the insertion of Vis if it could track or investigate all pages

  • I think it is the same situation with detection. It is a normal OS driver, so OS should load it without knowing what the driver wants to do, even it can track or investigate all pages at the moment. Once loaded, Vis is cloaked from guest OS.

The possibility of erasing evidence due to loading Vis code/data into memory

  • Two possible solutions are supposed for this: 1. Vis driver should be loaded with a clean boot. 2. When user suspects that some malicious attacks will happen, he/she loads the Vis driver to monitor the system for a period of time until he/she feels the OS is safe again. I like the second solutions much more.


Bib

  • [1] Forensics examination of volatile system data using virtual introspection, SigOps'2008. [4]
  • [2] Improving host-based computer security using secure active monitoring and memory analysis, Gatech PhD Thesis, 2010. [5]
  • [3] Live forensics: diagnosing your system without killing it first, 2006
  • [4] An Enhancement of Windows Device Driver Debugging Mechanism for VMM-based Live Forensics
  • [5] Risks of live digital forensic analysis
  • [6] Carrier, B.D. and Grand, J. A. hardware-based memory acquisition procedure for digital investigations. J. Digital Investigation 1, 1 (Mar. 2004).
  • [7] Petroni, Jr., N.L., Fraser, T., Molina, J., and Arbaugh, W.A. Copilot—A coprocessor-based kernel runtime integrity monitor. In Proceedings of 13th Annual USENIX Security Symposium (Aug. 2004).
  • [8] A Virtual Machine Introspection Based Architecture for Intrusion Detection Tal Garfinkel and Mendel Rosenblum In the Internet Society’s 2003 Symposium on Network and Distributed System Security (NDSS), pages 191–206, February 2003
  • [9] Ruo Ando, Youki Kadobayashi, and Youichi Shinoda. 2007. Asynchronous pseudo physical memory snapshot and forensics on paravirtualized VMM using split kernel module. In Proceedings of the 10th international conference on Information security and cryptology (ICISC'07), Kil-Hyun Nam and Gwangsoo Rhee (Eds.). Springer-Verlag, Berlin, Heidelberg, 131-143.
  • [10] Towards the Virtual Memory Space Reconstruction for Windows Live Forensic Purposes
  • [11] J. Butler. FU rootkit. http://www.rootkit.com/project.php?id=12.
  • [12] W.J. Chisum and B. Turvey. Evidence dynamics: Locard’s exchange principle and crime reconstruction. Journal of Behavioral Profiling, 1, 2000. Paper available at: http://www.profiling.org/journal/vol1_no1/jbp_ed_january2000_1-1.html
  • [13] Xuxian Jiang, Xinyuan Wang, and Dongyan Xu. 2007. Stealthy malware detection through vmm-based "out-of-the-box" semantic view reconstruction. In Proceedings of the 14th ACM conference on Computer and communications security (CCS '07). ACM, New York, NY, USA, 128-138.
  • [14] H. Carvey. Windows Foreniscs Analysis DVD Toolkit. Addison-Wesley, Inc., 2005.
  • [15] HyperSafe: A Lightweight Approach to Provide Lifetime Hypervisor Control-Flow Integrity
Personal tools
Namespaces
Variants
Actions
Navigation
Upload file
Toolbox