Attacking Hypervisors via Firmware and Hardware

Transcription

1 Attacking Hypervisors via Firmware and Hardware Alex Matrosov Mikhail Gorobets, Oleksandr Bazhaniuk Andrew Furtak, Yuriy Bulygin Advanced Threat Research

2 Agenda Hypervisor based isolation Firmware rootkit vs hypervisor Attacking hypervisors through system firmware Tools and mitigations Conclusions

3 Image source Hypervisor Based Isolation

4 Hypervisor Based Isolation Virtual Machine Virtual Machine App App App App Operating System Operating System Privilege VMM / Hypervisor System Firmware (BIOS, U/EFI firmware, SMI handlers, Coreboot ) Memory Hardware CPU Graphics I/O Network

5 Hypervisor Based Isolation Virtual Machine Virtual Machine App App App Attack Operating System Operating System Privilege VMM / Hypervisor System Firmware (BIOS, U/EFI firmware, SMI handlers, Coreboot ) Memory Hardware CPU Graphics I/O Network

6 Hypervisor Protections Software Isolation CPU / SoC: traps to hypervisor (VM Exits), MSR & I/O permissions bitmaps, rings (PV) Memory / MMIO: hardware page tables (e.g. EPT, NPT), software shadow page tables Devices Isolation CPU / SoC: interrupt remapping Memory / MMIO: IOMMU, No-DMA ranges

7 CPU Virtualization (simplified) VM Guest OS Instructions, exceptions, interrupts Access to CPU MSRs (e.g. DEBUGCTL) Access to I/O ports Access to (e.g. 0xB2) memory (EPT violations) Hypervisor Traps (VM Exits) VMM Host VM Exit Handler VM Control Structure (VMCS) MSR Bitmaps Extended Page Tables I/O Bitmaps

8 Protecting Memory with HW Assisted Paging VM Guest OS VMM Host Process Virtual Memory CR3 Guest Physical Memory GPA0 VMCS EPTP Host Physical Memory HPA0 VA0 Guest Page Tables GPA1 EPT HPA1 VA1 GPA2 GPA0 HPA3 HPA2 VA2 GPA3 GPA2 HPA5 HPA3 VA3 VA4 GPA4 GPA5 GPA6 GPA4 HPA4 (1:1 mapping) GPA6 block HPA4 HPA5 HPA6

9 Hypervisor Protections System Firmware Isolation

10 Firmware Rootkit vs Hypervisor Image source

11 What is firmware rootkit? Virtual Machine Virtual Machine App App App App Operating System Operating System Privilege VMM / Hypervisor System Firmware Rootkit (e.g. DXE driver) Memory Hardware CPU Graphics I/O Network

12 Firmware rootkit can open a backdoor for an attacker VM to access all other VMs Virtual Machine App App Operating System Attacker VM App App Operating System 3. Now using this backdoor, attacker VM can access all of memory of victim VMs VMM / Hypervisor System Firmware Backdoor Rootkit 2. During each boot rootkit installs a backdoor for an attacker controlled VM 1. At some point system firmware got infected with a rootkit staying persistent

13 Backdoor for attacker s VM 1. Firmware rootkit searches & modifies VM s VMCS(B), VMM page tables 2. Rootkit added page table entries to attacker VM which expose entire physical memory Now attacker VM has full access to physical memory of VMM and other VMs

14 So how would one install a rootkit in the firmware?

15 Using hardware SPI flash programmer

16 USB & exploiting weak firmware protections...

17 Software access and exploiting some vulnerability in firmware From privileged guest (e.g. Dom0). Requires privesc from normal guest (e.g. DomU) or remote From the host OS before/in parallel to VMM From normal guest if firmware is exposed to the guest by VMM For example, if firmware is not adequately write protected in system flash memory

18 DEMO Rootkit in System Firmware Exposes Secrets from Virtual Machines Image source

19 We flashed rootkited part of firmware image from within a root partition to install the rootkit The system doesn t properly protect firmware in SPI flash memory so we could bypass write-protection Finally more systems protect firmware on the flash memory common.bios_wp CHIPSEC module to test write-protection Malware can exploit vulnerabilities in firmware to install a rootkit on such systems Attacking and Defending BIOS in 2015

20 VMM forensics With the help of a rootkit in firmware any VM guest can extract all information about hypervisor and other VMs and just from memory VMCS structures, MSR and I/O bitmaps for each VM guest EPT for each VM guest Regular page tables for hypervisor and each VM guest IOMMU pages tables for each IOMMU device Full hypervisor memory map, VM exit handler Real hardware configuration (registers for real PCIe devices, MMIO contents )

21 VMM Hardware Page Tables

22 Attacking Hypervisors through System Firmware (with OS kernel access) Image source

23 Pointer Vulnerabilities in SMI Handlers Phys Memory RAX (code) RBX (pointer) RCX (function) RDX RSI RDI SMI SMI Handlers in SMRAM Fake structure inside SMRAM OS Memory Exploit tricks SMI handler to write to an address inside SMRAM Attacking and Defending BIOS in 2015

24 SMI Pointer Exploiting firmware SMI handler to attack VMM Virtual Machine (child partition) App App Operating System Root partition App Attack Operating System VMM allows VM to invoke SMI handlers (grants access to SW SMI I/O port 0xB2) Memory Hypervisor SMI Handlers System Firmware I/O Hardware CPU Network Graphics Compromised VM injects SMM payload through the input pointer vulnerability in SMI handler SMM firmware payload modifies hypervisor code or VMCS/EPT to install a backdoor

25 DEMO Attacking Hypervisor via Poisonous Pointers in Firmware SMI handlers

26 Root cause? Port B2h is open to VM in I/O bitmap

27 So this is firmware issue, right? What if firmware validates pointers?

28 Still exploitable Phys Memory RAX (code) RBX (pointer) RCX (function) RDX RSI RDI SMI SMI Handlers in SMRAM Hypervisor Memory (Protected by EPT) Firmware SMI handler validates input pointers to ensure they are outside of SMRAM preventing overwrite of SMI code/data

29 Point SMI handler to overwrite VMM page! Phys Memory RAX (code) RBX (pointer) SMI SMI Handlers in SMRAM RCX (function) RDX RSI RDI Hypervisor Memory (Protected by EPT) VMM Protected Page VMM Protections are OFF VT state and EPT protections are OFF in SMM (without STM) SMI handler writes to a protected page via supplied pointer

30 Attacking VMM by proxying through SMI handler Virtual Machine (child partition) App App Operating System Root partition App Attack Operating System VM with direct access to SMIs invokes SMI handler and supplies a pointer to some VMM page VMM / Hypervisor Memory SMI Handlers System Firmware Hardware CPU Graphics SMI handler writes to the supplied pointer overwriting contents of protected VMM page I/O Network

31 Do Hypervisors Dream of Electric Sheep? Vulnerability used in this section is VU# a.k.a. S3 Resume Boot Script Vulnerability independently discovered by ATR of Intel Security, Rafal Wojtczuk of Bromium and LegbaCore It s also used in Thunderstrike 2 by LegbaCore & Trammell Hudson

32 NORMAL BOOT S3 RESUME Waking the system from S3 sleep state Virtual Machine Apps / OS BDS VMM / Hypervisor U/EFI System Firmware DXE UEFI core & drivers S3 Boot Script Table Restores hardware config Script Engine Platform Init Platform Init

33 What is S3 boot script table? A table of opcodes in physical memory which restores platform configuration S3_BOOTSCRIPT_MEM_WRITE opcode writes some value to specified memory location on behalf of firmware S3_BOOTSCRIPT_DISPATCH/2 S3_BOOTSCRIPT_PCI_CONFIG_WRITE S3_BOOTSCRIPT_IO_WRITE

34 NORMAL BOOT S3 RESUME MODIFY Xen exposes S3 boot script table to Dom0 Privileged PV guest (Dom0) Exploit VM modifies S3 boot script table in memory Upon resume, firmware executes rogue S3 script Xen Hypervisor U/EFI System Firmware BDS DXE UEFI core & drivers S3 Boot Script Table Restores hardware config Script Engine Platform PEI 0xDBAA4000 Platform PEI

35 DEMO Attacking Xen in its sleep Image source

36 Déjà vu? Xen 0wning Trilogy (Part 3) by Invisible Things Lab

37 So these firmware vulnerabilities are exploitable from privileged guest (e.g. root partition, Dom0..) What about use cases where guests must be strongly isolated from the root partition?

38 Image sciencenews.org Tools and Mitigations

39 First things first - fix that firmware! Firmware can be tested for vulnerabilities! common.uefi.s3bootscript (tests S3 boot script protections) tools.smm.smm_ptr (tests for SMI pointer issues) Protect the firmware in system flash memory common.bios_wp common.spi_lock... (tests firmware protections in system flash memory)

40 Testing hypervisors Simple hardware emulation fuzzing modules for open source CHIPSEC tools.vmm.*_fuzz I/O, MSR, PCIe device, MMIO overlap, more soon Tools to explore VMM hardware config chipsec_util iommu (IOMMU) chipsec_util vm (CPU VM extensions)

41 Dealing with system firmware attacks.. A number of interfaces through which firmware can be attacked or relay attack onto VMM UEFI variables, SMI handlers, S3 boot script, SPI flash MMIO, FW update.. FW doesn t know memory VMM needs to protect VMM need to be careful with which of these it exposes to VMs including to administrative (privileged) guests Some need not be exposed (e.g. S3 boot script), some may be emulated and monitored

42 Conclusions Compromised firmware is bad news for VMM. Test your system s firmware for security issues Windows 10 enables path for firmware deployment via Windows Update Secure privileged/administrative guests; attacks from such guests are important Vulnerabilities in device and CPU emulation are very common. Fuzz all HW interfaces Firmware interfaces/features may affect hypervisor security if exposed to VMs. Both need to be designed to be aware of each other

43 References 1. CHIPSEC: 2. Intel s ATR Security of System Firmware 3. Attacking and Defending BIOS in 2015 by Intel ATR 4. Hardware Involved Software Attacks by Jeff Forristal 5. Xen 0wning Trilogy by Invisible Things Lab Low level PC attack papers by Xeno Kovah

44 Thank you!