BlueHat v18 || First strontium uefi rootkit unveiled
2 likes3,480 views
The document discusses the first strontium UEFI rootkit, known as Lojax, focusing on its functionalities like location tracking, locking down devices, and data deletion. It outlines past research findings, including design vulnerabilities and the threat landscape, along with technical details about the rootkit installation process and its interaction with UEFI firmware. Prevention and remediation strategies are also suggested, emphasizing the importance of secure boot and firmware updates.
BlueHat v18 || First strontium uefi rootkit unveiled
- 1. First STRONTIUM UEFI Rootkit Unveiled BlueHat v18 Jean-Ian Boutin | Senior Malware Researcher Frédéric Vachon | Malware Researcher
- 2. Jean-Ian Boutin Senior Malware Researcher Frédéric Vachon Malware Researcher @jiboutin @Freddrickk_
- 3. Agenda •What is LoJack? •Past research •Digging in •Descending through the rings
- 6. LoJack capabilities in a nutshell •Locate •Lock •Delete •Recover
- 8. Black Hat USA 2009 •Exposed design vulnerabilities in agent
- 9. LoJack Architecture back then
- 13. Configuration file vulnerability •IP and URL • search.namequery.com • xd1x35x71x17 -> 209.53.113.23
- 15. Small Agent attack surface •Local attack • Modify configuration •Remote attack • Malicious server set up
- 16. Digging in
- 17. LoJax - Cat is out of the bag •Document small agent modifications •Links old Sednit domains to Lojax domains
- 18. Where is the attack?
- 19. Where is the attack?
- 20. Changed only configuration file? •Almost, and used only one agent version to do so…
- 21. Changed only configuration file? •Almost, and used only one agent version to do so… •Bulk detection now possible – time to dive in
- 22. The Balkans, Central and Eastern Europe victims •Few organizations hit •Military and diplomatic organizations •Presence of several Sednit tools in the organization
- 23. Typical infection •XAgent v3 •Xtunnel •XAgent v4 •Lojax <insert somewhere above>
- 24. Standalone infection •In one case, lojax was the only Sednit-related detection on the machine
- 25. Agent update •In one case, lojax agent config was updated Old Agent C&C server New Agent C&C server remotepx.net rdsnet.com 103.41.177.43 185.86.148.18
- 26. Links to Sednit •Targets •Tooling •Domain re-use
- 28. Clairvoyance?
- 29. Clairvoyance?
- 30. Clairvoyance?
- 32. RWEverything •Legitimate software using legitimate kernel driver •Not the first time it is reused for other purposes
- 33. RWEverything •Found on some organizations with LoJax compromise •info_efi.exe
- 42. Down the rings we go
- 43. ReWriter_read.exe •Tool to dump SPI flash memory content found alongside LoJax sample IOCTL code Description 0x22280c Writes to memory mapped I/O space 0x222808 Reads from memory mapped I/O space 0x222840 Reads a dword from given PCI Configuration Register 0x222834 Writes a byte to given PCI Configuration Register
- 44. ReWriter_read.exe •Contains *lots* of debug strings •Consists of the following operations • Log information on BIOS_CNTL register • Locate BIOS region base address • Read UEFI firmware content and dump it to a file
- 45. Reading from the SPI Flash Memory
- 46. Reading from the SPI Flash Memory
- 47. Reading from the SPI Flash Memory
- 48. Reading from the SPI Flash Memory
- 49. Reading from the SPI Flash Memory
- 50. Reading from the SPI Flash Memory
- 51. ReWriter_binary.exe •Contains *lots* of debug strings •Uses RWEverything’s driver •Consists of the following operations • Add the rootkit to the firmware • Write it back to the SPI flash memory
- 53. Unified Extensible Firmware Interface (UEFI) • Replacement for the legacy BIOS • New standard for firmware development • Provides a set of services to UEFI applications • Boot services • Runtime services • No more MBR/VBR
- 54. Driver Execution Environment (DXE) Drivers • PE/COFF images • Abstract the hardware • Produce UEFI standard interface • Register new services (protocols) • Loaded during the DXE phase of the Platform initialization • Loaded by the DXE dispatcher (DXE Core)
- 55. UEFI firmware layout • Located in the BIOS region of the SPI flash memory • Contains multiple volumes • Volumes contain files identified by GUIDs • File contain sections • One of these sections is the actual UEFI image • It’s more complex than that but it suffices for our purpose
- 56. SPI flash memory layout
- 57. SPI flash memory layout
- 58. SPI flash memory layout
- 59. SPI flash memory layout
- 64. Parsing the firmware volumes • Parses all the firmware volumes of the UEFI firmware • Looks for 4 specific files • Ip4Dxe (8f92960f-2880-4659-b857-915a8901bdc8) • NtfsDxe (768bedfd-7b4b-4c9f-b2ff-6377e3387243) • SmiFlash (bc327dbd-b982-4f55-9f79-056ad7e987c5) • DXE Core
- 65. Ip4Dxe and DXE Core • Used to find the firmware volume to install the rootkit • DXE drivers are usually all in the same volume • DXE Core may be in a different volume • The chosen volume will be the one with enough free space available
- 66. NtfsDxe and SmiFlash • NtfsDxe the AMI NTFS driver • Will be removed if found • SmiFlash metadata are not used • SmiFlash is a known-vulnerable DXE driver
- 67. Adding the rootkit • Creates a FFS file header (EFI_FFS_FILE_HEADER) • Append the Rootkit file • Write it at the end of the DXE drivers volume or the DXE Core volume • Checks if there’s enough free space available
- 68. Write the compromised firmware to the SPI Flash memory
- 69. BIOS Write Protection Mechanisms • Platform exposes write protection mechanisms • Need to be properly configured by the firmware • We’ll only cover relevant protections to our research • Won’t cover Protected Range Registers • Exposed via the BIOS Control Register (BIOS_CNTL)
- 70. BIOS Write Protection Mechanisms • To write to the BIOS region BIOS Write Enable (BIOSWE) must be set to 1 • BIOS Lock Enable (BLE) allows to lock BIOSWE to 0
- 71. BIOS Write Protection Mechanisms • To write to the BIOS region BIOS Write Enable (BIOSWE) must be set to 1 • BIOS Lock Enable (BLE) allows to lock BIOSWE to 0
- 72. BIOS Write Protection Mechanisms • The implementation of BLE is vulnerable • When BIOSWE is set to 1, its value change in BIOS_CNTL • A System Management Interrupt (SMI) is triggered • The SMI handler sets BIOSWE back to 0 • The SMI handler must be implemented by the firmware
- 73. BIOS Write Protection Mechanisms • What if we write to the SPI flash memory before the SMI handler sets BIOSWE to 0? • Race condition vulnerability (Speed racer) • A thread continuously set BIOSWE to 1 • Another thread tries to write data • Works on multicore processors and single core processors with hyper-threading enabled
- 74. BIOS Write Protection Mechanisms • Platform Controller Hub family of Intel chipsets introduces a fix for this issue • The firmware must set this bit
- 75. BIOS Write Protection Mechanisms • Platform Controller Hub family of Intel chipsets introduces a fix for this issue • The firmware must set this bit
- 76. ReWriter_Binary.exe • ReWriter_Binary.exe checks these settings • Checks if the platform is properly configured • Implements the exploit for the race condition
- 77. Writing process decision tree
- 78. Writing process decision tree
- 79. Writing process decision tree
- 80. Writing process decision tree
- 81. Writing to the SPI Flash Memory
- 82. Writing to the SPI Flash Memory
- 83. Writing to the SPI Flash Memory
- 84. Writing to the SPI Flash Memory
- 85. Writing to the SPI Flash Memory
- 86. Let’s take a step back •Software implementation to flash firmware remotely • Hacking Team’s UEFI rootkit needed physical access •We extracted the UEFI rootkit •Looked at ESET’s UEFI scanner telemetry •And…
- 90. UEFI Rootkit
- 91. UEFI Rootkit: SecDxe •DXE Driver loaded by the DXE Dispatcher •Unsigned •File GUID • 682894B5-6B70-4EBA-9E90-A607E5676297
- 95. UEFI Rootkit: SecDxe •Notify function • Installs NTFS driver • Drops autoche.exe and rpcnetp.exe • Patch a value in the Windows Registry
- 96. UEFI Rootkit: NTFS driver •NTFS driver needed to get file-based access to Windows’ partition •UEFI firmware don’t need an NTFS driver • Only need to read the EFI system partition •Hacking Team’s NTFS driver from HT’s leak • NtfsDxe project from vector-edk
- 97. UEFI Rootkit: Dropping files
- 98. UEFI Rootkit: Dropping files
- 99. UEFI Rootkit: Dropping files
- 100. UEFI Rootkit: Patching Windows Registry Value •Modifies Windows Registry via %WINDIR%System32configSYSTEM •Changes “autocheck autochk *” to “autocheck autoche *” •HKLMSYSTEMCurrentControlSetControl Session ManagerBootExecute
- 103. Prevention •Enable Secure Boot •Keep your UEFI firmware up-to-date •Make sure you have modern chipsets (PCH) •Hope that your firmware configure security mechanisms properly :-( •Firmware security assessments can be done with CHIPSEC
- 104. Remediation •You need to reflash your UEFI firmware •If it’s not an option for you then…
- 105. Remediation •You need to reflash your UEFI firmware •If it’s not an option for you then…
- 106. Conclusion
- 107. Thanks! Questions? White paper available at welivesecurity.com @jiboutin @Freddrickk_