Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Detect Me If You Can - Anti-Firmware Forensics

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.

Takahiro Haruyama

June 05, 2022
Tweet

More Decks by Takahiro Haruyama

Other Decks in Technology

Transcript

  1. 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
  2. OVERVIEW •Background and Motivation •Test Environment Setup •Implementation •SpiMitm vs.

    Firmware Security Tools •Countermeasures •Wrap-up RECON2022 3
  3. 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
  4. 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
  5. 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()
  6. 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
  7. 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
  8. 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!
  9. 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
  10. 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)
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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))
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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)
  26. 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
  27. 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