Detect Me If You Can - Anti-Firmware Forensics

2022, REcon
https://cfp.recon.cx/2022/talk/RS9CWJ/
https://recon.cx/media-archive/2022/Recon2022_20_Detect_me_If_you_Can-Anti-firmware_Forensics.mp4
https://github.com/TakahiroHaruyama/SpiMitm

As firmware threats are becoming more prevalent, security companies are starting to provide UEFI firmware scanners to detect malicious firmware implants. These scanners first acquire a firmware image inside a SPI flash memory on hardware then parse and scan the image with known signatures.

Every software-based firmware acquisition on Intel platforms has a risk of being intercepted by SMM rootkits. This risk has been pointed out by security researchers for years. However, there has been no publicly-available implementation and no one has demonstrated the concept practically.

In this presentation, I'll explain about the firmware acquisition MitM attack PoC that I implemented to assess the risk correctly. I'll also show that the PoC can hide known bootkit components against both open and closed source firmware security tools. I believe that the findings from this research will be helpful for better firmware scanner implementations in the future.

Transcript

1. DETECT ME IF YOU CAN - ANTI-FIRMWARE FORENSICS TAKAHIRO HARUYAMA VMWARE THREAT ANALYSIS UNIT
2. WHO AM I? •Takahiro Haruyama (@cci_forensics) •Senior Threat Researcher at VMware Carbon Black TAU •Past Research •Anti-Forensics (e.g., exploiting EnCase’s Outside In) •RE (e.g., defeating compiler-level obfuscations) •Malware Analysis (e.g., Internet-wide C2 scanning) RECON2022 2
3. OVERVIEW •Background and Motivation •Test Environment Setup •Implementation •SpiMitm vs. Firmware Security Tools •Countermeasures •Wrap-up RECON2022 3
4. BACKGROUND AND MOTIVATION RECON2022 4
5. FIRMWARE THREATS •Bootkits • longer persistence and lower observability than OS-level implants •UEFI Secure Boot and Intel Boot Guard can detect bootkits • But they can be bypassed by vulnerability exploits • e.g., CVE-2021-0157 & CVE-2021-0158 RECON2022 5 Source: Rootkits and Bootkits Detect MoonBounce Detect Vector-EDK, LoJax
6. FIRMWARE SCANNERS •Several vendors provide an UEFI firmware scanner •AV/EDR: CrowdStrike, Microsoft, ESET, Kaspersky •firmware security: Eclypsium, Binarly •The scanner behavior 1. acquiring a firmware image inside a SPI flash memory 2. parsing and scanning the image with signatures RECON2022 6
7. SOFTWARE-BASED APPROACH FOR FIRMWARE ACQUISITION • I/O through the SPI flash interface • Port I/O (IN/OUT instructions) • Memory-Mapped I/O (MmMapIoSpace API) • Steps for firmware acquisition 1. Get SPI Base Address Register (SPIBAR) 2. Read/write SPI registers RECON2022 7 Application Kernel Driver Firmware OS user-mode OS kernel-mode SPI flash memory DeviceIoControl() IN/OUT & MmMapIoSpace()
8. SPI REGISTER ACCESS FOR FIRMWARE ACQUISITION RECON2022 8 Source: UEFI Firmware Rootkits: Myths and Reality
9. SPI FLASH READ MITM ATTACK RECON2022 9 Source: UEFI Firmware Rootkits: Myths and Reality
10. MOTIVATION •This attack possibility was pointed out by researchers for years • Xeno Kovah et al. “Copernicus 2: SENTER the Dragon!” in 2014 •But there has been no publicly-available PoC •Know our enemy! • Implement the attack PoC • Test firmware scanners against the PoC RECON2022 10
11. TEST ENVIRONMENT SETUP RECON2022 11
12. TESTED HARDWARE • UP Squared • Intel Atom x7-E3950, Apollo Lake SoC • Intel distributes the open source firmware debug image • “The UP Squared Chronicles” by Alan Sguigna • How to flash the image • How to Build the image RECON2022 12
13. HARDWARE DEBUGGING •Intel Direct Connect Interface (DCI) •DCI enables to JTAG-debug an Intel CPU over a USB port •Intel System Studio (ISS) provides the debuggers •Intel System Debugger (embedded in ISS) •Intel System Debugger (legacy, stand-alone) •WinDbg extensions RECON2022 13 recommended!
14. SMM CODE DEBUGGING TIPS • Instruction Stepping Mode • essential for step into/over • How to break the SMM code • Break by SMMEntry then enable the hardware breakpoint manually • It’s noisy if any periodic timer SMI • Insert CpuIceBreakpoint (INT1) RECON2022 14
15. IMPLEMENTATION RECON2022 15
16. SPIMITM SMM MODULE SUMMARY RECON2022 16 Root SMI handler SPI SMI handler Periodic timer SMI handler SW SMI handler Entry Point (2) Hook the BIOS lock SW SMI and register Turn on/off MitM (1) Register SPI Controller (4) SPI read MitM (3) Keep enabling FSMIE and clearing BIOS Decode Enable (BDE)
17. REGISTERING PERIODIC TIMER / SPI SMI HANDLERS •I wanted to register the SMI handlers in the late stage •Hook the BIOS Lock Software SMI before the OS boot •Triggered in the SC initialization routine ScOnReadyToBoot • 0xA9 (SW_SMI_BIOS_LOCK) • The SW SMI handler registers the TCO BIOSWR SMI handler disabling the BCR.BIOSWE bit RECON2022 17 SW_SMI_BIOS_LOCK
18. PERIODIC TIMER SMI HANDLER •The Flash SPI SMI# Enable (HSFC.FSMIE) bit can be cleared by a kernel driver using MMIO •CHIPSEC clears the bit when setting the size (FDBC) per SPI command cycle •The periodic timer SMI handler keeps enabling it RECON2022 18
19. PERIODIC TIMER SMI HANDLER (CONT.) •We can set the interval based on the definition •64ms or shorter required to generate the SPI SMI •The shorter the interval the more negative impact to system performance RECON2022 19
20. PERIODIC TIMER SMI HANDLER (CONT.) • The firmware acquisition performance in 64ms • Time overhead = 11%, Ratio of data overwritten by SPI SMI = 1.89% RECON2022 20
21. PERIODIC TIMER SMI HANDLER (CONT.) •The msec interval SMIs prevent the OS boot? •SpiMitm initally registers the 8sec handler then registers the 64 msec handler later after the boot RECON2022 21
22. SPI SMI HANDLER •Is this caused by FSMIE? •SPI SMI Status bit (SMI_STS.SPI_SMI_STS) •Flash Cycle Done bit (HSFS.FDONE) •Overwrite Flash Data (FDATA0-15) registers •Disable FSMIE to hide the MitM RECON2022 22
23. SPI SMI HANDLER (CONT.) •No SPI logic definition in the firmware L •I added the logic for the SMI RECON2022 23 ASSERT [ScSmiDispatcher] c:\work\edk2-platforms\Silicon\BroxtonSoC\BroxtonSiPkg \SouthCluster\ScSmiDispatcher\Smm\ScxSmmHelpers.c(573): ((BOOLEAN)(0==1))
24. SEQUENCING •Two types of SPI register access methods •“Hardware Sequencing” means the hardware picks the actual SPI commands that get sent for read/write • hides the details of SPI flash opcodes •“Software Sequencing” means we pick the actual SPI commands • offers a little more fine-grain control •I’ve referred to only Hardware Sequencing so far RECON2022 24 Source: Advanced x86: BIOS and System Management Mode Internals SPI Flash Programming
25. SEQUENCING (CONT.) • I also implemented the SPI SMI handler for SW Sequencing • Enable the SPI SMI# Enable (SSFC.SME) bit • Define the SPI logic for SW Sequecing • But SW Sequencing is usually disabled after POST using the FLOCKDN bit • I checked HSFS.FLOCKDN was enabled by the CHIPSEC spi_lock module • It’s not supported in Apollo Lake SoC? RECON2022 25
26. SPIMITM VS. FIRMWARE SECURITY TOOLS RECON2022 26
27. TEST STEPS 1. Build the firmware image with SpiMitm 2. Embed Hacking Team’s Vector-EDK with debug messages •rkloader and fsbg modules (no NTFS driver) 3. Acquire or scan the firmware using the security tools •Can the tools detect the Vector-EDK modules? RECON2022 27
28. VS. OPEN-SOURCE TOOL (CHIPSEC) •Demo RECON2022 28
29. VS. CLOSED-SOURCE TOOLS •4 firmware scanners including commercial products •I don’t disclose the tested scanner names :-) •The purpose of this research is not to blame any specific product, but to check the actual efficacy RECON2022 29
30. RESULT •The 3 scanners couldn’t discover Vector-EDK even if the MitM was disabled •They don’t support the Atom platform •Or simply the detection capabilities are poor •The last one detected Vector-EDK with the MitM! RECON2022 30
31. RESULT (CONT.) •I reversed the scanner then identified this had 2 methods for the firmware acquisition •Hardware Sequencing that programs a SPI flash •MMIO of the BIOS region based on the BIOS Decode Enable (BDE) register value •The latter one was not covered by SpiMitm initially RECON2022 31
32. RESULT (CONT.) •I added a code clearing BDE to SpiMitm •The improved SpiMitm could prevent the tool from detecting Vector-EDK :-) RECON2022 32 SpiMitm improved
33. COUNTERMEASURES RECON2022 33
34. HARDWARE-BASED ACQUISITION •Use a SPI programmer •not affected by SMM rootkits •but not scalable L RECON2022 34
35. SMRAM FORENSICS •Dump SMRAM using hardware debugger •It’s hard to enable the Intel DCI on normal platforms :-( •The dump takes long time (8MB SMRAM in a few hours) •Parse the SMRAM then detect malicious SMI handlers •smram_parse.py by Dmytro Oleksiuk •The SMM structures are different for different firmware L RECON2022 35 0x7b4e0c18: periodic timer SMI 0x7b530640 with Period 1000000 and SmiTickInterval 640000 (image = SpiMitm, link error = False) ... 0x7b4ebd18: Ichn/IchnEx SMI 0x7b5304c8 with context type 0x2e (image = SpiMitm, link error = False)
36. OTHER SOFTWARE-BASED DETECTIONS •Notice the MitM attack possibility •Detect the SMM code modification using Measured Boot • compare hash values of the OEM code (TPM PCR[0]) •Periodically check the FSMIE bit •Detect FV decompress/parse errrors after the acquisition •We can’t identify the malicious implants but we can recognize “something is wrong” at least RECON2022 36
37. WRAP-UP RECON2022 37
38. WRAP-UP • The reality of the firmware security tools • Only one scanner could detect VEDK without the MitM • SpiMitm could hide VEDK from the scanner • Every firmware doesn't always implement the SPI logic for the SMI • Attackers have to not only bypass BootGuard but also append the logic by the RE • Once the MitM module is installed, it’s hard to detect the threat explicitly using software-based approaches RECON2022 38
39. ACKNOWLEDGMENT •Satoshi Tanda •Alex Matrosov •Brian Baskin RECON2022 39
40. ANY QUESTIONS? •https://github.com/TakahiroHaruyama/SpiMitm RECON2022 40