Chipsec is an open source framework for assessing platform security. It can be used to find vulnerabilities in system firmware like BIOS, UEFI and Mac EFI. Some examples shown include exploiting S3 resume boot script vulnerabilities to gain persistence, attacking hypervisors via SMM pointers, and checking for issues with MMIO BAR registers. The tool can also detect "problems" like unlocked firmware, missing hardware protections, and analyze real-world malware implants targeting firmware like DerStarke and HackingTeam UEFI rootkits.
1. Exploring Your System Deeper
[with CHIPSEC] is Not Naughty
Presenting: Oleksandr Bazhaniuk (@ABazhaniuk), Andrew Furtak
Mikhail Gorobets (@mikhailgorobets), Yuriy Bulygin (@c7zero)
Advanced Threat Research
2. Agenda
Intro to firmware security
Finding vulnerabilities in firmware
Checking hardware protections
Finding “problems” in firmware
Finding vulnerabilities in hypervisors
Conclusions
6. Why Attack Firmware?
Getting extreme persistence
Getting stealth
Bypassing OS or VMM based security
Having unobstructed access to hardware
OS independent
Making the system unbootable
6
7. Some In-the-wild Firmware Attacks
Mebromi BIOS rootkit
EQUATION Group HDD firmware malware
] Hacking Team [ UEFI rootkit
Vault 7 Mac EFI implants (DerStarke/DarkMatter, Sonic Screwdriver)
8. CHIPSEC Framework
Open Source Platform Security Assessment Framework
https://github.com/chipsec/chipsec
OS support: Windows, Linux, UEFI Shell. Added alpha version for Mac OS
Architecture support: x86, ARM (WIP experimental)
10. Example: S3 Boot Script Vuln in PC UEFI and Mac EFI
[*] running module: chipsec.modules.common.uefi.s3bootscript
[x][ =======================================================================
[x][ Module: S3 Resume Boot-Script Protections
[x][ =======================================================================
[!] Found 1 S3 boot-script(s) in EFI variables
[*] Checking S3 boot-script at 0x00000000DA88A018
[!] S3 boot-script is in unprotected memory (not in SMRAM)
[*] Reading S3 boot-script from memory..
[*] Decoding S3 boot-script opcodes..
[*] Checking entry-points of Dispatch opcodes..
...
[-] FAILED: S3 Boot Script and entry-points of Dispatch opcodes do not appear
to be protected
Technical Details of the S3 Resume Boot Script Vulnerabilities
11. Example: exploiting flash protections via S3 boot script vuln on Mac EFI
Technical Details of the S3 Resume Boot Script Vulnerabilities
12. Example: Mac EFI leaving SMM unlocked after S3
Issue. Loosing SMRAM protections after S3 sleep
Step 1. chipsec_main –m common.smrr
PASSED
Step 2. Go to sleep. Resume from sleep
Step 3. chipsec_main –m common.smrr
FAILED
13. Testing S3 Vulnerabilities
Validate your system for S3 boot script vulnerabilities
chipsec_main –m common.uefi.s3bootscript
Also run before and after resuming from sleep!
chipsec_main –m common.smrr
chipsec_main –m common.spi_lock
[or just run all modules] chipsec_main
Manually test S3 boot script protections:
chipsec_main –m tools.uefi.s3script_modify
15. Vulnerabilities in SMM of UEFI Firmware
Phys Memory
SMI Handlers in
SMRAM
OS MemoryRAX (code)
Fake SMM comm buffer
“UEFI” ACPI
EDKII
EDKI
Via ACPI table
Directly in registers
SMI
Exploit tricks SMI handler to write to an address in SMRAM (Attacking and Defending BIOS in 2015)
Comm Buffer
RBX (pointer)
16. Example: Attacking hypervisors via SMM pointers…
Phys Memory
SMI Handlers in
SMRAM
OS MemoryRAX (code)
Fake SMM comm buffer
VMM protected page
“UEFI” ACPI
EDKII
EDKI
Via ACPI table
Directly in registers
SMI
Comm Buffer
RBX (pointer)
Even though SMI handler check pointers for overlap with SMRAM, exploit can trick it to write to VMM
protected page (Attacking Hypervisors via Firmware and Hardware)
19. MMIO BAR Issues in Coreboot and UEFI
Phys Memory
SMI Handlers in SMRAM
OS Memory
Base Address (BAR)
MMIO range
(registers)
Device PCI CFG
Firmware configures chipset and devices
through MMIO
SMI handlers communicate
with devices via MMIO registers
20. Example: MMIO BAR Issues in Coreboot and UEFI
Phys Memory
SMI Handlers in SMRAM
OS Memory
Base Address (BAR)
MMIO range
(registers)
Device PCI CFG
SMI
Exploit with PCI access can modify BAR
register and relocate MMIO range
On SMI interrupt, SMI handler firmware
attempts to communicate with device(s)
It may read or write “registers” within
relocated MMIO
21. SPI Controller MMIO BAR (Access to SPI Flash)
chipsec_util uefi var-write B 55555555-4444-3333-2211-000000000000 B.bin
chipsec_util mmio dump SPIBAR
SPI Flash Data
(Variable contents)
SPI Status and Control
SPI Flash Address (address
variable is written to in flash)
23. Testing for MMIO BAR issues
chipsec_main -i -m tools.smm.rogue_mmio_bar
Reallocating MMIO BAR to new location
Trigger SMIs and check new memory
location
28. Example: SMM Protections – Memory Sinkhole Vulnerability
chipsec_main -m tools.cpu.sinkhole
Attempting to overlap Local APIC page
with SMRR region
The Memory Sinkhole by Christopher Domas
30. Integrated Graphics Aperture
Low MMIO Range
TOLUD
4GB
DRAM
Graphics Aperture
GTT MMIO
Access to
GFx Aperture
GFx Memory
Access to GFx Aperture
(MMIO) is redirected to
DRAM per GTT PTEs
GTT PTEs
31. Software DMA Access via IGD with CHIPSEC
chipsec_util igd
chipsec_util igd dmaread <address> [width] [file_name]
chipsec_util igd dmawrite <address> <width> <value|file_name>
Cannot access certain memory ranges such as SMRAM
A way for Graphics kernel driver to access Graphics Stolen data memory
Separate graphics IOMMU/VT-d engine (controlled by GFXVTBAR)
References:
Intel Graphics for Linux – Hardware Specification – PRMs
chipsec_util igd
33. Vault7 EFI DerStarke/DarkMatter Implant
DerStarke includes DarkMatter Mac EFI firmware persistence implant with multiple
DXE and PEI executables
Doesn't just rely on unlocked flash like HackingTeam's UEFI rootkit
Re-infects EFI firmware updates with implants already in the firmware
Contains DarkDream exploit which appears to bypass firmware protections on
resume from S3 sleep to permanently unlock SPI flash
Using S3 resume in the exploit suggests exploitation of one of S3 boot script vulns
• Technical Details of the S3 Resume Boot Script Vulnerabilities
• Attacks On UEFI Security by Rafal Wojtczuk and Corey Kallenberg
• Reversing Prince Harming’s kiss of death by Pedro Vilaca
• Exploiting UEFI boot script vulnerability by Dmytro Oleksiuk
35. ]HackingTeam[ UEFI Rootkit
• rkloader is a DXE driver that is automatically executed during boot
• The module simply registers a callback on READY_TO_BOOT event to
execute the malicious payload
Analysis of the HackingTeam's UEFI Rootkit
36. The callback then loads a UEFI application, which checks for infection by looking for UEFI
variable “fTA”
Use NTFS module to drop a backdoor (scoute.exe) and RCS agent (soldier.exe) onto the
filesystem
]HackingTeam[ UEFI Rootkit
Analysis of the HackingTeam's UEFI Rootkit
37. ]HackingTeam[ UEFI Rootkit
Infection
Installed via physical access and a SPI programmer
Or by booting a USB image to erase and reprogram firmware. Requires
unlocked (vulnerable) firmware on a target system
Automatic reinfection after removal of remote access components
Detection
Can be detected by finding fTA UEFI variable with GUID
8BE4DF61-93CA-11d2-aa0d-00e098302288
chipsec_util uefi var-find fTA
Examine firmware image for additional DXE modules (see later)
38. • Installed by adding additional
sections to existing SMM driver
• Provides SMI interfaces for OS level
caller
• Direct SW SMI
• Periodic SMI with “magic” numbers in
registers to identify a call
• Provides read/write memory access.
Easily extensible
Building reliable SMM backdoor for UEFI based platforms
PoC SmmBackdoor by Dmytro Oleksiuk
40. Where to Start From? Firmware Acquisition
1. Obtain clean/original firmware image
1. Extract known good firmware image from a supposedly clean system (or from multiple
systems). For example, when purchased (beware of supply chain attack) or before travel
2. Firmware update image (UEFI “capsule” image) or full firmware image on the platform
manufacturer’s web-site
2. Get the firmware image from suspect system, periodically or when suspect (e.g. after travel)
If you have an infector sample, make firmware dumps before and after the infection
3. Firmware cane be acquired with software (e.g. CHIPSEC) or hardware tools
chipsec_util spi dump firmware.bin
Important: software based acquisition methods of firmware images can be tampered with.
Whenever possible, use hardware tools to extract firmware
4. Compare the two images (see next slides for details)
Check firmware security advisories to understand how the firmware could be compromised
and infected. This would help determining what to look for when comparing images
42. Detecting Unexpected Firmware Modifications
Check UEFI firmware image for unexpected modifications, e.g. added EFI executable binaries
chipsec_main -m tools.uefi.whitelist [-a check,<json>,<fw_image>]
Decodes UEFI firmware image and checks all EFI executable binaries
against a specified list
json JSON file with configuration of white-listed EFI executables
fw_image Full file path to UEFI firmware image. If not specified, the
module will dump firmware image directly from ROM
43. Generating Whitelist…
chipsec_main -n -m tools.uefi.whitelist -a generate,orig.json,fw.bin
Assumes there’s a way to generate clean (uninfected) list of EFI executables. For
example, from the update image downloaded from the vendor web-site
44. Checking (U)EFI Executables Against Whitelist…
chipsec_main –n –m tools.uefi.whitelist –a check,orig.json,fw.bin
Extra EFI executables belong to
HackingTeam’s UEFI rootkit
46. Blacklisting Bad (U)EFI Executables
Check UEFI firmware image for known bad (vulnerable or malicious) EFI executable binaries
chipsec_main -i -m tools.uefi.blacklist [-a <fw_image>,<blacklist>]
51. Tools
Other great tools to extract and decode UEFI firmware images
1. UEFITool: GUI software by Nikolaj Schlej
2. uefi-firmware-parser by Teddy Reed
3. flashrom to extract firmware images from SPI flash
52. Firmware Artifacts
To perform system firmware forensics, the following artifacts can be extracted
and analyzed:
1. Layout and entire contents of SPI Flash memory
2. BIOS/UEFI firmware including EFI binaries and NVRAM
3. Runtime or Boot UEFI Variables (non-volatile and volatile)
4. UEFI Secure Boot certificates (PK, KEK, db/dbx ..)
5. UEFI system and configuration tables (Runtime, Boot and DXE services)
6. UEFI S3 resume boot script table
7. PCIe option (expansion) ROMs
53. Firmware Artifacts
8. Settings stored in RTC-backed CMOS memory
9. ACPI tables
10.SMBIOS table
11.HW protection settings (e.g. SPI W/P)
12.System security settings (Secure Boot, etc.)
13.Contents of TPM Platform Configuration Registers (PCR)
14.Firmware images from other components such as HDD/SSD, NIC,
Embedded Controller, etc.
15.MBR/VBR or UEFI GUID Partition Table (GPT)
16.Files on EFI system partition (boot loaders)
54. Extracting EFI Configuration (from the image)
Firmware NVRAM configurations is extracted when UEFI firmware image is decoded
Alternatively, this command can be used:
chipsec_util uefi nvram nvar rom.dump.bin
Path to extracted/parsed NVRAM contents:
NVRAM dump: rom.dump.bin.dirnvram_nvar.nvram.bin
Decoded variables: rom.dump.bin.dirnvram_nvar.nvram.lst
Format of NVRAM and variables are platform/firmware specific.
CHIPSEC supports multiple types of NVRAM: EVSA, NVAR, VSS, VSS_AUTH, VSS_APPLE
55. Extracting EFI Configuration (on a live system)
chipsec_util uefi var-list
Secure Boot
certificates (PK,
KEK, db, dbx)
Setup Variable
BootOrder vars
AcpiGlobalVariable
61. Fuzzing and exploring hypervisors…
Hypercall fuzzers:
tools.vmm.*.hypercallfuzz
Fuzzing modules for emulated devices:
tools.vmm.*_fuzz
I/O, MSR, PCIe device, MMIO overlap, more soon …
Tools to explore VMM hardware config
chipsec_util iommu (IOMMU)
chipsec_util vmm (CPU VM extensions)
62. Fuzzing Xen Hypercalls
[x][ =======================================================================
[x][ Module: Xen Hypervisor Hypercall Fuzzer
[x][ =======================================================================
[CHIPSEC] Fuzzing HVM_OP (0x22) hypercall
[CHIPSEC]
[CHIPSEC] ********************* Hypercall status codes ********************
[CHIPSEC] Invalid argument - XEN_ERRNO_EINVAL : 578
[CHIPSEC] Function not implemented - XEN_ERRNO_ENOSYS : 170
[CHIPSEC] Status success - XEN_STATUS_SUCCESS : 114
[CHIPSEC] No such process - XEN_ERRNO_ESRCH : 89
[CHIPSEC] Operation not permitted - XEN_ERRNO_EPERM : 49
chipsec_main -i -m tools.vmm.xen.hypercallfuzz -a fuzzing,22,1000
• Some hypercalls tend to crash the guest too often
• Most tests fails on sanity checks
63. Example: Crashing Xen Host by Unprivileged Guest (XSA 188)
Finding CVE-2016-7154 by fuzzing Xen hypercalls:
chipsec_main -i -m tools.vmm.xen.hypercallfuzz -a fuzzing,20,1000000
Reproducing CVE-2016-7154:
(args_va, args_pa) = self.cs.mem.alloc_physical_mem(0x1000, 0xFFFFFFFFFFFFFFFF)
self.cs.mem.write_physical_mem(args_pa, 24, 'xFF' * 8 + 'x00' * 16)
self.vmm.hypercall64_five_args(EVENT_CHANNEL_OP, EVTCHOP_INIT_CONTROL, args_va)
self.vmm.hypercall64_five_args(EVENT_CHANNEL_OP, EVTCHOP_INIT_CONTROL, args_va)
Turns out when the PFN parameter is invalid, hypercall returns XEN_ERRNO_EINVAL
error, but doesn’t zero out internal pointer Use-After-Free
64. Fuzzing CPU Model Specific Registers…
chipsec_main –i –m tools.vmm.msr_fuzz
Low MSR range, High MSR range and
VMM synthetic MSR range
65. Issues in MSR Hypervisor Emulation
CVE-2015-0377
Writing arbitrary data to upper 32 bits of IA32_APIC_BASE MSR causes VMM and
host OS to crash on Oracle VirtualBox 3.2, 4.0.x-4.2.x
chipsec_main –m tools.vmm.vbox.vbox_crash_apicbase
XSA-108
A buggy or malicious HVM guest can crash the host or read data relating to other guests
or the hypervisor itself by reading MSR from range [0x100;0x3ff]. Discovered by Jan
Beulich
66. Fuzzing Hypervisor Emulation of I/O Ports…
chipsec_main –i –m tools.vmm.iofuzz
Fuzzer covers entire I/O port range
with 1000 writes to each port
67. Example: VENOM Vulnerability
VENOM vulnerability (discovered by CrowdStrike researchers)
chipsec_main –i –m tools.vmm.venom
Trigger Venom vulnerability by writing
to port 0x3F5 (FDC data) value 0x8E and
0x10000000 of random bytes
69. Example: Dom0 to Xen Exploit via S3 Boot Script
Found S3 boot script table in
memory accessible to Dom0
Changing the boot script to
access Xen hypervisor pages
Dumping DomU VMCS from
memory protected by EPT
72. Conclusions
• Securing the firmware or detecting firmware compromise is a complex
problem
• Sophisticated adversaries start targeting firmware with implants
• Defenders need security research available to them to understand the
threat and protect their infrastructure
• Defenders also need tools to level the field with sophisticated adversaries