How to hack a switched off computer or execute code in Intel ME
At the recent Black Hat Europe conference, Positive Technologies researchers Mark Yermolov and Maxim Goryachiy spoke about a vulnerability in the Intel Management Engine 11 , which allows attackers to access most of the data and processes on the device.
This level of access also means that any attacker who exploits this vulnerability, bypassing traditional software-based protection, will be able to launch attacks even when the computer is turned off. Today we publish in our blog the details of the study.
The Intel Management Engine is a closed technology that is a microcontroller integrated into the Platform Controller Hub (PCH) chip with a set of embedded peripherals. It is through PCH that almost all communication between the processor and external devices takes place, therefore Intel ME has access to almost all data on the computer and the ability to execute third-party code allows you to completely compromise the platform. Such endless opportunities have attracted researchers for years and years, but now interest in Intel ME technology has grown significantly. One of the reasons for this is the transition of this subsystem to a new hardware (x86) and software (modified MINIX as an operating system) architecture. The use of the x86 platform makes it possible to use all the power of binary code analysis tools, which was previously difficult, since before the 11th version, the kernel with the rare command system, ARC, was used. Unfortunately, the analysis of Intel ME 11th version was made difficult by the fact that executable modules are packed with a Huffman code with unknown tables. But our research team managed to restore them (the utility for unpacking images can be found on our page in GitHub [2]).
')
After unpacking the executable modules, we began to study the software and hardware "stuffing" of Intel ME. Our efforts were rewarded, and in the end we got full control over the entire platform.
A detailed description of the internal arrangement of Intel ME and its components can be found in [1], [3], [4]. Note that, starting in 2015, the LMT processor core was integrated into the PCH with the x86 instruction set. This core is used in SOC Quark.
LMT2 IdCode ME kernel
A large number of modern Intel technologies are associated with the Intel Management Engine - Intel Active Management Technology, Intel Platform Trust Technology (fTPM), Intel Software Guard Extensions, Intel Protected Audio Video Path. ME is also the root of trust for Intel Boot Guard technology, which does not allow an attacker to inject his code into UEFI. The main purpose of the ME is the initial initialization of the platform, and the launch of the main processor. ME also has almost limitless access to data that is processed on a computer. ME can intercept and modify network packets, the image on the video card, has full access to USB devices. Such capabilities mean that if an attacker gains the ability to execute his code inside the ME, it will mean a new era of malicious software that cannot be detected by modern means of protection. But fortunately for all 17 years of the history of this technology, only 3 vulnerabilities have been found (publicly).
The first public vulnerability in Intel ME was found in 2009. Alexander Tereshkin and Rafal Wojtczuk presented a report on Black Hat Introducing Ring-3 Rootkits. The attack was made by injecting the code into a specialized UMA memory area, into which the ME unloads the currently unused memory pages.
After the announcement of the research results, Intel implemented UMA protection - now this area is encrypted with AES and for each page IU stores its checksum, which is checked when the page “returns” to the main memory of ME.
In 2010, Vassilios Ververis introduced an attack on the implementation of ME in GM45. Using the “zero touch” configuration mode, he was able to bypass the AMT authorization.
In May 2017, a vulnerability was published in the AMT authorization system (CVE-2017-5689), which allowed unauthorized users to get full access to the main system on motherboards with vPro technology support.
Thus, until now, only one vulnerability has been found (Ring-3 rootkits), which allows the execution of arbitrary code inside Intel ME.
Virtually all the data that ME uses in its work is either directly or indirectly signed by Intel. But IU still provides some possibilities for user interaction:
HECI - is a separate PCI-device, which is a ring buffer and is used to exchange messages between the main system and the ME.
Applications located inside the ME can register their handlers for HECI. This increases the number of potential security issues (CVE-2017-5711).
AMT is a single large module that integrates a huge number of different network protocols at various levels, this module contains a large amount of legacy code, but is only present on business segment systems.
In the process of studying ME, we had an idea to bypass signature verification using an SPI flash emulator. This is a specialized device that would look like a normal SPI-flash for PCH, but with different calls it sends different data. Thus, if the signature of the data is first controlled, and then they are reread, then you can attack and inject your code inside the ME. We failed to find such errors in the firmware, the data are first read, then the signature is checked. With repeated requests, their identity is controlled by the data obtained at the first reading.
The Intel Management Engine uses SPI flash as the main file storage with its own file system. On the one hand, the file system has a rather complex structure [6], on the other hand, many privileged processes store their configuration files here. On this basis, the file system seemed to us the most promising place to influence ME.
The next step in the search for vulnerabilities was the choice of a binary module.
The operating system ME is implemented similar to that used in Unix model of differentiation and access control, with the difference that the processes are the subjects of the system. For each process, its user ID, groups, list of available equipment and allowed system calls are statically set.
An example of static rules for the process
Thus, not every process in the system can load modules for execution. Moreover, the monitoring of integrity and privileges is set by the process that launches it. He can elevate his privileges by giving the new process high access rights.
One of the processes with the ability to generate new ones is BUP (BringUP). In the process of reverse engineering of this module, in the initialization function of the Trace Hab device, we found an overflow of the stack buffer. The file “/ home / bup / ct” did not have a signature, and could be integrated into the ME firmware via the service program - Flash Image Tool. This made it possible to cause a buffer overflow inside the BUP process using a large BUP initialization file. But it was possible to use it only after bypassing the protection from stack buffer overflow.
Stack buffer overflow
ME implements a classic way to protect against buffer overflow in a stack - a stack canary. Implemented this mechanism as follows:
Thus, for operation, it is necessary either to predict the value of the canary, or to take control before the integrity check is performed. Further study has shown that any failure in the random number generator is regarded by ME as fatal failure and leads to its inoperability.
Studying the functions that are called after the overflow and before the integrity check we found that the function we called
Function call memcpy
Getting an address from TLS
As it turned out later, in the event of a buffer overflow, this TLS area can be overwritten by the file reading function, which bypasses the buffer overflow protection.
All access to the TLS structure occurs through the gs segment register. The structure itself has the following form:
TLS structure
Getting TLS fields
The segment pointed to by gs is not writable, but the TLS structure itself is located at the bottom of the stack (!!!), which allows you to change it to bypass the restriction. Thus, in the event of a buffer overflow, we can rewrite the pointer to TLS and form the SYSLIB_CTX structure. And the algorithm of operation of the algorithm of the function bup_dfs_read_file, using this trick, allows you to get an arbitrary write.
The bup_dfs_read_file function reads data from SPI-flsh blocks of 64 bytes, which allows you to first overwrite the pointer to SYSLIB_CTX and TLS. At the next iteration, the sys_write_shared_mem function retrieves the address we created and sends it to memcpy as the target address. This allows you to get a record primitive within the BUP process.
Iterative reading of the file inside bup_dfs_read_file
The absence of ASLR allows you to overwrite the return address of the memcpy function and take control. There is also waiting for trouble for the attacker - the stack is not executable. But using the fact that BUP is able to create new processes and checks the signature for the modules to be launched, we can create a new process with specified permissions using return-oriented programming (ROP).
To successfully exploit this vulnerability, write access to MFS or the entire Intel ME region is required. Equipment manufacturers should block access to the region with ME, but unfortunately, not everyone is doing it [8]. If there is such a configuration error on the system, it automatically makes it vulnerable.
Intel ME provides full-time ability to provide write access to the ME region by sending a special HMR-FPO message via HECI from the BIOS [9]. An attacker can send such a message using a vulnerability in the BIOS or DMA attack.
In the case of physical access to the attacked machine, the attacker can always rewrite to his image (via SPI programmer or using a special jumper), which leads to a complete cracking of the platform.
One of the most pressing issues is the question of the possibility of remote operation. It seems to us that this possibility exists if the following conditions are met:
Fulfillment of these conditions allows an attacker to gain access to the ME region remotely.
Note also that the ROM does not control the version of Intel ME at startup, which makes it possible to upgrade to the old version that contains the vulnerability.
The found vulnerability was assigned the number INTEL-SA-00086 (CVE-2017-5705, CVE-2017-5706, CVE-2017-5707). Here is a short excerpt from his description:
CVSSv3 Vectors:
Affected products:
Thus, we have found the vulnerability of Intel ME, which allows you to execute arbitrary code. This threatens all technologies such as Intel Protected Audio Video Path (PAVP), Intel Platform Trust Technology (PTT or fTPM), Intel BootGuard, Intel Software Guard Extention (SGX) and many others.
Exploiting the vulnerability we found in the bup module, we managed to enable a mechanism called PCH red unlock, which opens up full access to all PCH devices for using them via the DFx chain, in other words using JTAG. One of these devices is the ME core itself. This made it possible to debug the code running on ME, read the memory of all processes and the kernel, and also manage all the devices inside the PCH. We counted in the aggregate about 50 internal devices, full access to which has only ME, and the main processor only to a very limited subset of them.
We do not claim that there is no error in our study or it is exhaustive. Nevertheless, we hope that it will help other researchers interested in the security and "stuffing" of Intel ME.
Authors : Mark Yermolov and Maxim Hot
[1] Dmitry Sklyarov, Intel ME: The Way of the Static Analysis, Troopers 2017.
[2] Intel ME 11.x Firmware Images Unpacker .
[3] Xiaoyu Ruan, Platform Embedded Security Technology Revealed.
[4] Igor Skochinsky, Intel ME Secrets. Where does it exactly, does RECON 2014.
[5] Alexander Tereshkin, Rafal Wojtczuk, Introducing Ring-3 Rootkits, Black Hat USA, 2009.
[6] Dmitry Sklyarov, Intel ME: flash file system explained, Black Hat Europe, London, 2017.
[8] Alex Matrosov, Who Watch BIOS Watchers? .
[9] Mark Yermolov, Maxim Goryachiy, “ How to become the sole owner of your own computer ”, PHDays VI.
This level of access also means that any attacker who exploits this vulnerability, bypassing traditional software-based protection, will be able to launch attacks even when the computer is turned off. Today we publish in our blog the details of the study.
1. Introduction
The Intel Management Engine is a closed technology that is a microcontroller integrated into the Platform Controller Hub (PCH) chip with a set of embedded peripherals. It is through PCH that almost all communication between the processor and external devices takes place, therefore Intel ME has access to almost all data on the computer and the ability to execute third-party code allows you to completely compromise the platform. Such endless opportunities have attracted researchers for years and years, but now interest in Intel ME technology has grown significantly. One of the reasons for this is the transition of this subsystem to a new hardware (x86) and software (modified MINIX as an operating system) architecture. The use of the x86 platform makes it possible to use all the power of binary code analysis tools, which was previously difficult, since before the 11th version, the kernel with the rare command system, ARC, was used. Unfortunately, the analysis of Intel ME 11th version was made difficult by the fact that executable modules are packed with a Huffman code with unknown tables. But our research team managed to restore them (the utility for unpacking images can be found on our page in GitHub [2]).
')
After unpacking the executable modules, we began to study the software and hardware "stuffing" of Intel ME. Our efforts were rewarded, and in the end we got full control over the entire platform.
1.1. Intel Management Engine 11 Overview
A detailed description of the internal arrangement of Intel ME and its components can be found in [1], [3], [4]. Note that, starting in 2015, the LMT processor core was integrated into the PCH with the x86 instruction set. This core is used in SOC Quark.
LMT2 IdCode ME kernel
A large number of modern Intel technologies are associated with the Intel Management Engine - Intel Active Management Technology, Intel Platform Trust Technology (fTPM), Intel Software Guard Extensions, Intel Protected Audio Video Path. ME is also the root of trust for Intel Boot Guard technology, which does not allow an attacker to inject his code into UEFI. The main purpose of the ME is the initial initialization of the platform, and the launch of the main processor. ME also has almost limitless access to data that is processed on a computer. ME can intercept and modify network packets, the image on the video card, has full access to USB devices. Such capabilities mean that if an attacker gains the ability to execute his code inside the ME, it will mean a new era of malicious software that cannot be detected by modern means of protection. But fortunately for all 17 years of the history of this technology, only 3 vulnerabilities have been found (publicly).
1.2. Intel ME known vulnerabilities
1.2.1. Ring-3 Rootkits
The first public vulnerability in Intel ME was found in 2009. Alexander Tereshkin and Rafal Wojtczuk presented a report on Black Hat Introducing Ring-3 Rootkits. The attack was made by injecting the code into a specialized UMA memory area, into which the ME unloads the currently unused memory pages.
After the announcement of the research results, Intel implemented UMA protection - now this area is encrypted with AES and for each page IU stores its checksum, which is checked when the page “returns” to the main memory of ME.
1.2.2. Zero-Touch Provisioning
In 2010, Vassilios Ververis introduced an attack on the implementation of ME in GM45. Using the “zero touch” configuration mode, he was able to bypass the AMT authorization.
1.2.3. Silent Bob is Silent
In May 2017, a vulnerability was published in the AMT authorization system (CVE-2017-5689), which allowed unauthorized users to get full access to the main system on motherboards with vPro technology support.
Thus, until now, only one vulnerability has been found (Ring-3 rootkits), which allows the execution of arbitrary code inside Intel ME.
2. Attack Vectors
Virtually all the data that ME uses in its work is either directly or indirectly signed by Intel. But IU still provides some possibilities for user interaction:
- Local Management Interface - HECI
- Network (vPro only)
- Host Memory (UMA)
- SPI flash
- Internal file system
2.1. Heci
HECI - is a separate PCI-device, which is a ring buffer and is used to exchange messages between the main system and the ME.
Applications located inside the ME can register their handlers for HECI. This increases the number of potential security issues (CVE-2017-5711).
2.2. Network (vPro only)
AMT is a single large module that integrates a huge number of different network protocols at various levels, this module contains a large amount of legacy code, but is only present on business segment systems.
2.3. Hardware attack on SPI-interface
In the process of studying ME, we had an idea to bypass signature verification using an SPI flash emulator. This is a specialized device that would look like a normal SPI-flash for PCH, but with different calls it sends different data. Thus, if the signature of the data is first controlled, and then they are reread, then you can attack and inject your code inside the ME. We failed to find such errors in the firmware, the data are first read, then the signature is checked. With repeated requests, their identity is controlled by the data obtained at the first reading.
2.4. Internal file system
The Intel Management Engine uses SPI flash as the main file storage with its own file system. On the one hand, the file system has a rather complex structure [6], on the other hand, many privileged processes store their configuration files here. On this basis, the file system seemed to us the most promising place to influence ME.
The next step in the search for vulnerabilities was the choice of a binary module.
2.5. The choice of module for analysis
The operating system ME is implemented similar to that used in Unix model of differentiation and access control, with the difference that the processes are the subjects of the system. For each process, its user ID, groups, list of available equipment and allowed system calls are statically set.
An example of static rules for the process
Thus, not every process in the system can load modules for execution. Moreover, the monitoring of integrity and privileges is set by the process that launches it. He can elevate his privileges by giving the new process high access rights.
One of the processes with the ability to generate new ones is BUP (BringUP). In the process of reverse engineering of this module, in the initialization function of the Trace Hab device, we found an overflow of the stack buffer. The file “/ home / bup / ct” did not have a signature, and could be integrated into the ME firmware via the service program - Flash Image Tool. This made it possible to cause a buffer overflow inside the BUP process using a large BUP initialization file. But it was possible to use it only after bypassing the protection from stack buffer overflow.
Stack buffer overflow
2.6. Buffer overflow protection bypass
ME implements a classic way to protect against buffer overflow in a stack - a stack canary. Implemented this mechanism as follows:
- For each process at the time of its creation, a 32-bit value is copied from a hardware random-number generator to a special area (read-only);
- In the function prologue, this value is copied over the return address in the stack, thereby protecting it;
- In the epilogue of the function, the stored value is compared with the reference value. If it does not match, a software interrupt is generated; int 81h terminating the process.
Thus, for operation, it is necessary either to predict the value of the canary, or to take control before the integrity check is performed. Further study has shown that any failure in the random number generator is regarded by ME as fatal failure and leads to its inoperability.
Studying the functions that are called after the overflow and before the integrity check we found that the function we called
bup_dfs_read_file indirectly calls memcpy . She, in turn, uses as the value of the target address, the data obtained from some structure, which we called TLS (Tread Local Storage). It is worth noting that the bup functions for reading and writing files use the services of the system library for working with shared memory. Using it, the functions of reading and writing, receive and record information. But no one except BUP uses this data, so the use of this mechanism may seem dubious. We believe that this is due to the fact that part of the BUP code that interacts with MFS is copied from another module — the file system driver, where the use of shared memory is justified.
Function call memcpy
Getting an address from TLS
As it turned out later, in the event of a buffer overflow, this TLS area can be overwritten by the file reading function, which bypasses the buffer overflow protection.
2.7. Tread local storage
All access to the TLS structure occurs through the gs segment register. The structure itself has the following form:
TLS structure
Getting TLS fields
The segment pointed to by gs is not writable, but the TLS structure itself is located at the bottom of the stack (!!!), which allows you to change it to bypass the restriction. Thus, in the event of a buffer overflow, we can rewrite the pointer to TLS and form the SYSLIB_CTX structure. And the algorithm of operation of the algorithm of the function bup_dfs_read_file, using this trick, allows you to get an arbitrary write.
2.8. Using the read function implementation to get arbitrary write primitive
The bup_dfs_read_file function reads data from SPI-flsh blocks of 64 bytes, which allows you to first overwrite the pointer to SYSLIB_CTX and TLS. At the next iteration, the sys_write_shared_mem function retrieves the address we created and sends it to memcpy as the target address. This allows you to get a record primitive within the BUP process.
Iterative reading of the file inside bup_dfs_read_file
The absence of ASLR allows you to overwrite the return address of the memcpy function and take control. There is also waiting for trouble for the attacker - the stack is not executable. But using the fact that BUP is able to create new processes and checks the signature for the modules to be launched, we can create a new process with specified permissions using return-oriented programming (ROP).
2.9. Possible vectors of operation
To successfully exploit this vulnerability, write access to MFS or the entire Intel ME region is required. Equipment manufacturers should block access to the region with ME, but unfortunately, not everyone is doing it [8]. If there is such a configuration error on the system, it automatically makes it vulnerable.
Intel ME provides full-time ability to provide write access to the ME region by sending a special HMR-FPO message via HECI from the BIOS [9]. An attacker can send such a message using a vulnerability in the BIOS or DMA attack.
In the case of physical access to the attacked machine, the attacker can always rewrite to his image (via SPI programmer or using a special jumper), which leads to a complete cracking of the platform.
One of the most pressing issues is the question of the possibility of remote operation. It seems to us that this possibility exists if the following conditions are met:
- Attacked platform with activated AMT.
- The attacker knows the AMT administrator password or uses a vulnerability to bypass authorization.
- The BIOS does not have a password (or is known to the attacker).
- The BIOS has an option that allows you to open write access to the ME region.
Fulfillment of these conditions allows an attacker to gain access to the ME region remotely.
Note also that the ROM does not control the version of Intel ME at startup, which makes it possible to upgrade to the old version that contains the vulnerability.
2.10. Vulnerability Overview CVE-2017-5705,6,7
The found vulnerability was assigned the number INTEL-SA-00086 (CVE-2017-5705, CVE-2017-5706, CVE-2017-5707). Here is a short excerpt from his description:
CVSSv3 Vectors:
- 8.2 High AV: L / AC: L / PR: H / UI: N / S: C / C: H / I: H / A: H
Affected products:
- 6th, 7th & 8th Generation Intel Core Processor Family
- Intel Xeon Processor E3-1200 v5 & v6 Product Family
- Intel Xeon Processor Scalable Family
- Intel Xeon Processor W Family
- Intel Atom C3000 Processor Family
- Apollo Lake Intel Atom Processor E3900 series
- Apollo Lake Intel Pentium
- Celeron N and J series Processors
2.11. Disclosure Timeline
- June 27, 2017 - Bug reported to Intel PSIRT
- June 28, 2017 - Intel started initial investigation
- July 5, 2017 - Intel requested proof-of-concept
- July 6, 2017 - Additional information sent to Intel PSIRT
- July 17, 2017 - Intel acknowledged the vulnerability
- July 28, 2017 - Bounty payment received
- November 20, 2017 - Intel published SA-00086 security advisory
3. Conclusion
Thus, we have found the vulnerability of Intel ME, which allows you to execute arbitrary code. This threatens all technologies such as Intel Protected Audio Video Path (PAVP), Intel Platform Trust Technology (PTT or fTPM), Intel BootGuard, Intel Software Guard Extention (SGX) and many others.
Exploiting the vulnerability we found in the bup module, we managed to enable a mechanism called PCH red unlock, which opens up full access to all PCH devices for using them via the DFx chain, in other words using JTAG. One of these devices is the ME core itself. This made it possible to debug the code running on ME, read the memory of all processes and the kernel, and also manage all the devices inside the PCH. We counted in the aggregate about 50 internal devices, full access to which has only ME, and the main processor only to a very limited subset of them.
We do not claim that there is no error in our study or it is exhaustive. Nevertheless, we hope that it will help other researchers interested in the security and "stuffing" of Intel ME.
Authors : Mark Yermolov and Maxim Hot
Bibliography
[1] Dmitry Sklyarov, Intel ME: The Way of the Static Analysis, Troopers 2017.
[2] Intel ME 11.x Firmware Images Unpacker .
[3] Xiaoyu Ruan, Platform Embedded Security Technology Revealed.
[4] Igor Skochinsky, Intel ME Secrets. Where does it exactly, does RECON 2014.
[5] Alexander Tereshkin, Rafal Wojtczuk, Introducing Ring-3 Rootkits, Black Hat USA, 2009.
[6] Dmitry Sklyarov, Intel ME: flash file system explained, Black Hat Europe, London, 2017.
[8] Alex Matrosov, Who Watch BIOS Watchers? .
[9] Mark Yermolov, Maxim Goryachiy, “ How to become the sole owner of your own computer ”, PHDays VI.
Source: https://habr.com/ru/post/346974/
All Articles