How Open Source Project Xen Puts Security Ahead of Emerging Threats Mihai Donțu, Bitdefender Andrei Florescu, Bitdefender

In An Ideal World…

OSes would be designed differently Humans would not code

… In The Real World

OSes are flawed by design Humans (still) code

Perfect St[w]orms “Wormable” Vulnerability in widely-used services or protocols Vulnerability remotely exploitable “Wormable” Vulnerable service exposed to the outside world Both Servers and Workstations vulnerable Vulnerability affects OS Kernel

Some Examples?

MS08-067 – MS NetAPI32 Vulnerability Out-of-band patch released Infected >9mil systems including: defense, gov, commercial Vulnerability present and exploitable 09/25/2008 11/2008 1 AD… 1/2009 10/23/2008 MS caught wind of 0-day through WER* Conficker/Downadup worm released in the wild * https://blogs.technet.microsoft.com/johnla/2015/09/26/the-inside-story-behind-ms08-067/

… 9 years later

MS17-010 – MS SMB v1 Vulnerability (EternalBlue) Some bad people released a public exploit - EternalBlue NotPetya (or something) released Vulnerability present and exploitable 5/12/2017 3/14/2017 1 AD… 4/14/2017 6/27/2017 MS released patch (on a Tuesday) WannaCry Released in the wild. Over 300k systems infected in 3 days. *https://businessinsights.bitdefender.com/hypervisor-introspection-defeated-enternalblue-a-priori

So What Really Changed?

Vulns & Exploit Branding! Endpoint Detection and Response (EDR) In Reality… Next-Gen Stuff Vulns & Exploit Branding! DEP Threat-hunting OS-based Exploit Mitigation Endpoint Detection and Response (EDR) ASLR In-Guest Security Tools SafeSEH SEHOP Sandboxing ? Incident Response

? Back To The Ideal World… Vulns & Exploit Branding! Generic Exploit Prevention Isolated From Attackable Surface OS-based Exploit Mitigation No Prior Knowledge Required In-Guest Security Tools Real-Time Alerts ? Forensics Details Provided

HVI Demo: Defeating EternalBlue

Open Source Collaboration

Project History 2003 First notable academic research (by Garfinkel & Rosenblum) 2008 First proof of concept on Xen (Ether) 2010 Started working on a VMI-based security technology using a custom hypervisor 2012 First proof of concept with Xen 2014 Started working with the Xen Project community on improving and extending Xen’s VMI features 2014 Intel announced the first CPU features aimed at speeding up VMI 2016 First beta for Bitdefender’s HVI technology 2017 First commercial release with Citrix XenServer 7.0 (Xen 4.6)

How HVI Works Uses the VMI capabilities of Xen (xen-access, vm-events) Builds a "shadow" state of the OS Enforces certain access restrictions on: Code (kernel or user application) Stack Heap Data Driver Objects (Windows) IDT/GDT etc. Sensitive MSR-s (eg. MSR_LSTAR)

Architecture Overview XenServer Control Domain (dom0) Security Appliance (domU) Memory Introspection Engine Guest Critical Memory Access XenServer Hypervisor Direct Inspect APIs Networking Storage Compute

A Closer Look: EternalBlue

MS17-010: The Vulnerability Integer Overflow DWORD subtracted into a WORD Buffer Overflow memove operation in srv!SrvOs2FeaToNt Arbitrary write-what-where primitive (Classic heap spraying & grooming to gain RCE) RIP is hijacked in srvnet!SrvNetWskReceiveComplete

MS17-010 : Exploiting The Vulnerability The exploit is using MDL (Memory Descriptor Lists) to control the source & destination of arbitrary writes ASLR is bypassed by using hard-coded memory regions HalHeap is located at 0xffffffffffd00000 Fixed in Windows 10 Redstone 1 (april 2017) Page-Table addresses are also “hard-coded” Self mapped at entry 0x1ed Fixed in Windows 10 Anniversary Update (august 2016) DEP is disabled on the HalHeap region by directly editing the page-tables The payload is placed inside the HalHeap The handler for the connection-close is overwritten and offers RCE The shellcode is executed when the connection is closed

MS17-010: The Payload – Stage 1 Trick to determine if the OS is 32 or 64 bit If 32 bit then bail out else continue execution (in this example) 1 2 Read Model Specific Register (MSR) 0xC0000082 – IA32_LSTAR MSR – and save it This MSR contains the kernel address of the SYSCALL handling routine Any SYSCALL made by a user-mode app will end up running the code pointed by IA32_LSTAR Modify IA32_LSTAR MSR so that it points to the main payload inside the HalHeap 3

MS17-010: The Payload – Stage 2 As soon as an application initiates a SYSCALL, the main payload gains code execution It restores the original SYSCALL handler It does whatever the payload was programmed to do This is the main functionality of the exploit 4

MS17-010: The Payload – Stage 3 (The stage 2?3) payload: Iterates all the loaded drivers, searches for the samba drivers Overwrites a SrvTransactionNotImplemented function inside the SrvTransaction2DispatchTable => backdoor Next time someone wants to see if a system ha been compromised, it can simply “knock” and see if DoublePulsar responds

… and HVI Defeats EternalBlue

MS17-010: Preventing Exploitation Trick to determine if the OS is 32 or 64 bit If 32 bit then bail out else continue execution (in this example) 1 2 Read Model Specific Register (MSR) 0xC0000082 – IA32_LSTAR MSR – and save it This MSR contains the kernel address of the SYSCALL handling routine Any SYSCALL made by a user-mode app will end up running the code pointed by IA32_LSTAR The IA32_LSTAR MSR is protected against modifications Although the stage 1 payload may get code execution, it cannot ensure the execution of the main payload; the main payload will never run 3

MS17-010: Preventing Exploitation The samba drivers are protected against modifications and the SrvTransaction2DispatchTable is located inside such a driver (srv.sys) The backdoor cannot be installed on the system … although it never gets to this, because we already blocked it at stage 1 

Future Work Expand the protection over more OS areas (eg. HAL’s heap) Prevent credential theft from Windows LSASS Integrate more hardware features to accelerate VMI (eg. Intel’s #VE) Extract more context out of the guest to improve attack analysis (opened connections, accessed files etc.) Help create an ecosystem for VMI-based security tools to which more organizations can contribute

2 3 1 Conclusions VMI is Changing the Security Industry Commercial Implementations Are Available 1 Open-source Collaboration is Key

Time For Questions!