1 / 17

EUROSEC 2011 Gábor Pék , Boldizsár Bencsáth and Levente Buttyán

EUROSEC 2011 Gábor Pék , Boldizsár Bencsáth and Levente Buttyán Laboratory of Cryptography and Systems Security Budapest University of Technology and Economics. nEther : IN-GUEST DETECTION OF OUT-OF-THE-GUEST MALWARE ANALYSERS. Short Summary. We successfully achieved

amable
Download Presentation

EUROSEC 2011 Gábor Pék , Boldizsár Bencsáth and Levente Buttyán

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. EUROSEC 2011 Gábor Pék , Boldizsár Bencsáth and Levente Buttyán Laboratory of Cryptography and Systems Security Budapest University of Technology and Economics nEther: IN-GUEST DETECTION OF OUT-OF-THE-GUEST MALWARE ANALYSERS

  2. ShortSummary We successfully achieved • In-guest detection of an out-of-the-guest malware analysis framework (Ether) • In-guest timing attack • Detection based on CPUID information • Detecting hardware assisted virtualization (can be a bit of information for analysis ) • Detection based on errata in Intel CPUs

  3. Goalsin Malware Analysis • Analyser: dissecting and figuring out the operations of the analysed program • Author of the malware: thwarting the analysis of the code and hiding its real intents, operations, execution

  4. What is Malware Analysis? • Analysing malware • Static (entire program, thwarting disassemblers) • Dynamic (one control path)  we focus on this • Two types of dynamic analysis: Native and Virtualization based • Main tricks of detecting dynamic analyzers • Timing information • Special data structures, e.g., PEB • Single-step debugging (trap flag) • Exception handling

  5. HW AssistedVirtualization • New and higher CPU privilege level (Ring -1) • Native instruction execution • Intel VT • VMX root mode for VMM/Hypervisor • VMX non-root mode for guest OS • VMX transitions: VM Exit / VM Entry • Rich feature set and control of operation • Xen, KVM

  6. Ether – Malware analysisviaHW VirtualizationExtensions • Transparent, out-of-the-guest malware analysis platform based on Xen and Intel VT • Transparency of Ether: the malware cannot detect Ether • Transparency requirements as of the Ether paper: • Higher privilege of analyser environment • No non-privileged side effects • Same instruction execution semantics X • Identical exception handling • Identical notion of time X

  7. Advantages of Ether and challenges to detectit • No in-guest memory presence • Hide of changes made on CPU registers • Memory protection: modifies only shadow page tables • Privileged instruction handling • No instruction emulation • Controlling timing (e.g., RDTSC instruction)

  8. Contributions • Design and implementation of an application framework to detect Ether based on multiple feature tests • Feature tests for Ether and Intel VT • A practical in-guest timing attack against Ether • Detecting Ether via CPUID information • Detection of HW assisted virtualization utilizing CPU errata

  9. System Overview

  10. Varioususes of RDTSC • Different behaviour of sensitive instructions (e.g., RDTSC) in VMX non-root mode Normal operation Operation of Ether Guest OS Guest OS … Guest OS rdtsc rdtsc faketime (FT) FT+Y rdtsc TSC VM Exit VM Entry CPU Virtual CPU Virtual CPU …

  11. FactsaboutEther • Alleged operation: FT = TSC, Y = TSC_OFFSET • but TSC_OFFSET is disabled • Real operation: Monotonic increase of FT for every RDTSC call (Y =1) • There can be external RDTSC calls during an analysis • The TSC difference between two RDTSCs of the analysed program = # of RDTSCs of the Guest during analysis (~9-171)

  12. Practicalimplementation of in-guesttimingattack • Call an RDTSC and store it • Create a loop of non-sensitive instructions (e.g., nop) • Call an RDTSC and compare it with the stored value (diff) if (diff < length of theloop)Ether is presentelseEtherisnotpresent

  13. CPUID information • CPUID instruction: processor identifcation and feature information • Allegedly: Ether has no in-memory presence • Reality: The TSC bit returned by CPUID is unset under Ether • Other bits of information • PAE and PSE are disabled

  14. CPU Errata • Design deficiencies of CPUs • Some of them are unpredictable • Cause unexpected system behaviour • Several have ”No Fix ” status • Xen creates virtualized CPUs for privileged instructions • We have an erratum using MSRs (AH4) • The access of MSRs are privileged  VM exit • Errata are not emulated by virtual CPUs • Bingo, we have a new feature test

  15. Detecting Intel VT

  16. FutureWork • Fundamentality of these problems • Updating the theoretical model and practical implementation of Ether • Finding more feature tests against other out-of-the-guest approaches (e.g., Azure) • Proving that perfect transparency has practical limitations

  17. Thanks for YourAttention! Questions? pek@crysys.hu boldi@crysys.hu buttyan@crysys.hu CrySyS Lab. http://www.crysys.hu Budapest University of Technology and Economics

More Related