Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

BlueHat v18 || First strontium uefi rootkit unveiled

Jean-Ian Boutin, ESET
Frédéric Vachon, ESET

BIOS rootkits have been researched and discussed heavily in the past few years, but sparse evidence has been presented of real campaigns actively trying to compromise a system at this level. Our talk will reveal such a campaign successfully executed by STRONTIUM.

Earlier this year, there was a public report stating that the infamous Sofacy/APT28/Sednit APT group successfully trojanized a userland LoJack agent and used it against their targets. LoJack, a controversial anti-theft software, was scrutinized by security researchers in the past because of its unusual persistence method: a module preinstalled in many computers' UEFI/BIOS software. Several security risks were found through the years in their product, but no large in-the-wild activity was ever detected until the discovery of the STRONTIUM group leveraging some of these vulnerabilities affecting the userland agent. However, through our research, we now know that they did not stop there: they also tried, and succeeded, in installing a custom UEFI module directly in the systems' SPI flash memory.

In this talk, we will detail the full infection chain showing how STRONTIUM was able to install their custom UEFI module on key targets' computers.
Additionally, we will provide an in-depth analysis of their UEFI module and the associated trojanized LoJack agent.

  • Sé el primero en comentar

BlueHat v18 || First strontium uefi rootkit unveiled

  1. 1. First STRONTIUM UEFI Rootkit Unveiled BlueHat v18 Jean-Ian Boutin | Senior Malware Researcher Frédéric Vachon | Malware Researcher
  2. 2. Jean-Ian Boutin Senior Malware Researcher Frédéric Vachon Malware Researcher @jiboutin @Freddrickk_
  3. 3. Agenda •What is LoJack? •Past research •Digging in •Descending through the rings
  4. 4. Computrace/LoJack
  5. 5. Absolute Software
  6. 6. LoJack capabilities in a nutshell •Locate •Lock •Delete •Recover
  7. 7. Past Research
  8. 8. Black Hat USA 2009 •Exposed design vulnerabilities in agent
  9. 9. LoJack Architecture back then
  10. 10. Configuration file vulnerability
  11. 11. Configuration file vulnerability
  12. 12. Configuration file vulnerability
  13. 13. Configuration file vulnerability •IP and URL • search.namequery.com • xd1x35x71x17 -> 209.53.113.23
  14. 14. Silent activation?
  15. 15. Small Agent attack surface •Local attack • Modify configuration •Remote attack • Malicious server set up
  16. 16. Digging in
  17. 17. LoJax - Cat is out of the bag •Document small agent modifications •Links old Sednit domains to Lojax domains
  18. 18. Where is the attack?
  19. 19. Where is the attack?
  20. 20. Changed only configuration file? •Almost, and used only one agent version to do so…
  21. 21. Changed only configuration file? •Almost, and used only one agent version to do so… •Bulk detection now possible – time to dive in
  22. 22. The Balkans, Central and Eastern Europe victims •Few organizations hit •Military and diplomatic organizations •Presence of several Sednit tools in the organization
  23. 23. Typical infection •XAgent v3 •Xtunnel •XAgent v4 •Lojax <insert somewhere above>
  24. 24. Standalone infection •In one case, lojax was the only Sednit-related detection on the machine
  25. 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. 26. Links to Sednit •Targets •Tooling •Domain re-use
  27. 27. Analyst ramblings
  28. 28. Clairvoyance?
  29. 29. Clairvoyance?
  30. 30. Clairvoyance?
  31. 31. RWEverything •Uefi read tool
  32. 32. RWEverything •Legitimate software using legitimate kernel driver •Not the first time it is reused for other purposes
  33. 33. RWEverything •Found on some organizations with LoJax compromise •info_efi.exe
  34. 34. autochk.exe mechanism?
  35. 35. autochk.exe mechanism?
  36. 36. autochk.exe vs. autoche.exe
  37. 37. autochk.exe vs. autoche.exe
  38. 38. autochk.exe vs. autoche.exe
  39. 39. autochk.exe vs. autoche.exe
  40. 40. autochk.exe vs. autoche.exe
  41. 41. autochk.exe vs. autoche.exe
  42. 42. Down the rings we go
  43. 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. 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. 45. Reading from the SPI Flash Memory
  46. 46. Reading from the SPI Flash Memory
  47. 47. Reading from the SPI Flash Memory
  48. 48. Reading from the SPI Flash Memory
  49. 49. Reading from the SPI Flash Memory
  50. 50. Reading from the SPI Flash Memory
  51. 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
  52. 52. Patching the UEFI firmware
  53. 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. 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. 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. 56. SPI flash memory layout
  57. 57. SPI flash memory layout
  58. 58. SPI flash memory layout
  59. 59. SPI flash memory layout
  60. 60. BIOS region layout
  61. 61. BIOS region layout
  62. 62. BIOS region layout
  63. 63. BIOS region layout
  64. 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. 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. 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. 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. 68. Write the compromised firmware to the SPI Flash memory
  69. 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. 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. 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. 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. 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. 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. 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. 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. 77. Writing process decision tree
  78. 78. Writing process decision tree
  79. 79. Writing process decision tree
  80. 80. Writing process decision tree
  81. 81. Writing to the SPI Flash Memory
  82. 82. Writing to the SPI Flash Memory
  83. 83. Writing to the SPI Flash Memory
  84. 84. Writing to the SPI Flash Memory
  85. 85. Writing to the SPI Flash Memory
  86. 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…
  87. 87. UEFI Rootkit
  88. 88. UEFI Rootkit: SecDxe •DXE Driver loaded by the DXE Dispatcher •Unsigned •File GUID • 682894B5-6B70-4EBA-9E90-A607E5676297
  89. 89. UEFI Rootkit workflow
  90. 90. UEFI Rootkit workflow
  91. 91. UEFI Rootkit workflow
  92. 92. UEFI Rootkit: SecDxe •Notify function • Installs NTFS driver • Drops autoche.exe and rpcnetp.exe • Patch a value in the Windows Registry
  93. 93. 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
  94. 94. UEFI Rootkit: Dropping files
  95. 95. UEFI Rootkit: Dropping files
  96. 96. UEFI Rootkit: Dropping files
  97. 97. UEFI Rootkit: Patching Windows Registry Value •Modifies Windows Registry via %WINDIR%System32configSYSTEM •Changes “autocheck autochk *” to “autocheck autoche *” •HKLMSYSTEMCurrentControlSetControl Session ManagerBootExecute
  98. 98. UEFI Rootkit workflow
  99. 99. Prevention and Remediation
  100. 100. 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
  101. 101. Remediation •You need to reflash your UEFI firmware •If it’s not an option for you then…
  102. 102. Remediation •You need to reflash your UEFI firmware •If it’s not an option for you then…
  103. 103. Conclusion
  104. 104. Thanks! Questions? White paper available at welivesecurity.com @jiboutin @Freddrickk_

    Sé el primero en comentar

    Inicia sesión para ver los comentarios

  • nkokkoon

    Oct. 30, 2018

Jean-Ian Boutin, ESET Frédéric Vachon, ESET BIOS rootkits have been researched and discussed heavily in the past few years, but sparse evidence has been presented of real campaigns actively trying to compromise a system at this level. Our talk will reveal such a campaign successfully executed by STRONTIUM. Earlier this year, there was a public report stating that the infamous Sofacy/APT28/Sednit APT group successfully trojanized a userland LoJack agent and used it against their targets. LoJack, a controversial anti-theft software, was scrutinized by security researchers in the past because of its unusual persistence method: a module preinstalled in many computers' UEFI/BIOS software. Several security risks were found through the years in their product, but no large in-the-wild activity was ever detected until the discovery of the STRONTIUM group leveraging some of these vulnerabilities affecting the userland agent. However, through our research, we now know that they did not stop there: they also tried, and succeeded, in installing a custom UEFI module directly in the systems' SPI flash memory. In this talk, we will detail the full infection chain showing how STRONTIUM was able to install their custom UEFI module on key targets' computers. Additionally, we will provide an in-depth analysis of their UEFI module and the associated trojanized LoJack agent.

Vistas

Total de vistas

3.272

En Slideshare

0

De embebidos

0

Número de embebidos

41

Acciones

Descargas

62

Compartidos

0

Comentarios

0

Me gusta

1

×