How to hack a disabled Computer or run code in Intel ME

At the recent Black Hat Europe conference, Positive Technologies researchers Mark Ermolov and Maxim Goryachy spoke about the vulnerability in Intel Management Engine 11 , which opens up access to most of the data and processes on the device.

This level of access also means that any attacker exploiting this vulnerability, bypassing traditional software-based protection, will be able to conduct attacks even when the computer is turned off. Today we publish in our blog the details of the study.

1. Introduction

Intel Management Engine is a closed technology, which is a microcontroller integrated into the Platform Controller Hub (PCH) with a set of built-in 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 completely compromising the platform. Such unlimited opportunities attract researchers for several years, but now the 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 allows using the full power of the binary code analysis tools, which was previously difficult, since prior to the 11th version, a kernel with an uncommon command system (ARC) was used. Unfortunately, the analysis of Intel ME 11 version was complicated by the fact that the executable modules are packed with 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 started to study the software and hardware “stuffing” of Intel ME. Our efforts were rewarded, and as a result we got full control over the entire platform.

1.1. Intel Management Engine Overview 11

A detailed description of the internal device of Intel ME and its components can be found in the works: [1], [3], [4]. Note that, starting in 2015, PCH has integrated the LMT processor core with the x86 command set. This kernel is used in SOC Quark.

C Intel Management Engine is associated with a large number of modern Intel technologies – Intel Active Management Technology, Intel Platform Trust Technology (fTPM), Intel Software Guard Extensions, Intel Protected Audio Video Path. Also, ME is 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 ME is initial initialization of the platform, and the launch of the main processor. ME also has virtually unlimited access to data that is processed on the 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 gets the opportunity to execute his code inside the ME, this will mean a new era of malicious software, It is impossible to detect 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. Publicly known vulnerabilities in Intel ME

 

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 the Black Hat Introducing Ring-3 Rootkits. The attack was carried out by injecting the code into a specialized area of ​​UMA memory, into which ME unloads an unused page of memory.

After the announcement of the results of the research, Intel introduced UMA protection – now this area is encrypted by AES and for each page of ME stores its checksum, which is checked when the page is “returned” to the main memory of ME.

1.2.2. Zero-Touch Provisioning

In 2010, Vassilios Ververis presented an attack on the implementation of ME in GM45. Using the “zero touch” configuration mode, it was able to bypass the AMT authorization.

1.2.3. Silent Bob is Silent

In May 2017, a vulnerability in the AMT authorization system (CVE-2017-5689) was published, which allowed an unauthorized user to gain 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 executing arbitrary code inside Intel ME.

2. Attack vectors

Virtually all the data that ME uses in its work is either explicitly or implicitly signed by Intel. But IU still provides some opportunities for interaction with the user:

  • Local control interface – HECI
  • Network (for 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 serves 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 problems (CVE-2017-5711).

2.2. Network (vPro only)

AMT is a single large module that integrates a huge number of different network protocols of different levels, this module contains a large number of legacy-code, but it is only present on the systems of the business segment.

2.3. Hardware attack on the SPI interface

In the process of studying ME, we had an idea to bypass the verification of the signature using the SPI flash emulator. This is a specialized device that would look like a normal SPI flash for PCH, but it sends different data for different calls. Thus, if the signature of the data is controlled in the beginning, and then they are reread, then you can conduct an attack and insert your code into the IU. We could not find such errors in the firmware, the data is first read out, then the signature is checked. During repeated appeals, their identity is controlled by the data that was obtained at the first reading.

2.4. Internal file system

Intel Management Engine uses SPI flash as the primary 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 the basis of what, the file system seemed to us the most promising place to influence ME.

The next step in the vulnerability search was to select a binary module.

2.5. Selecting the module for analysis

In the ME operating system, a model of access control and demarcation, similar to that used in Unix, is implemented, with the difference that processes act as subjects of the system. For each process, its user ID, groups, list of available equipment and allowed system calls are statically assigned.

Thus, not every process in the system can load modules for execution. Moreover, the control of integrity and privileges establishes the process that triggers 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 function of initializing the Trace Hab device, we found the stack buffer overflow. The file “/ home / bup / ct” did not have a signature, and could be integrated into the ME firmware via the Flash Image Tool. This made it possible to cause buffer overflows within the BUP process using the BUP initialization file of large size. But it could only be exploited after circumventing the protection from stack buffer overflow.

2.6. Bypass of buffer overflow protection

In ME, a classic way of protecting against buffer overflow in the stack is the stack canary. This mechanism is implemented as follows:

  1. For each process, at the time of its creation, a 32-bit value is copied from the hardware random number generator to a special area (read-only);
  2. In the function prolog, this value is copied over the return address in the stack, thereby protecting it;
  3. In the epilogue of the function, the stored value is compared with the reference value. If it does not match, the program interrupt int 81h is terminated.

Thus, for operation, it is necessary either to predict the value of the canary, or to intercept the control before its integrity is verified. Further study showed that any failure in the random number generator is regarded by ME as an irremovable malfunction and leads to its inoperability.

By studying the functions that are called after the overflow and before the integrity check, we found that the function that we called bup_dfs_read_fileindirectly causes memcpy. It, in turn, uses as the value of the target address, data received from some structure, which we called TLS (Tread Local Storage). It should be noted that bup functions for reading and writing files use the services of the system library to work with shared memory. Using it, the reading and writing functions receive and record information. But nobody except BUP uses this data, so the use of this mechanism may seem questionable. 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.

As it turned out later, when the buffer overflows, this TLS area can be overwritten by the file reading function, which allows to bypass buffer overflow protection.

2.7. Tread Local Storage

All access to the TLS structure occurs through the segment register gs

The segment pointed to by gs is not available for writing, but the TLS structure itself is located on the bottom of the stack (!!!), which allows change it bypassing the restrictions. Thus, when the buffer overflows, we can rewrite the pointer to TLS and form the SYSLIB_CTX structure. And the algorithm of operation of the bup_dfs_read_file function, using this trick, allows you to get arbitrary write.

2.8. Using the implementation of the read function to get arbitrary write primitive

The function bup_dfs_read_file reads data with 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 that we generated and passes it to memcpy as the target address. This allows you to get the write primitive within the BUP process.

The absence of ASLR allows you to overwrite the return address with memcpy and intercept control. There also awaits trouble for the attacker – the stack is not executable. But taking advantage of the fact that BUP is able to create new processes and checks the signature for the modules it runs, we can create a new process with the given rights using the Return Oriented Programming (ROP).

2.9. Possible operating vectors

To successfully exploit this vulnerability, you must have write access to MFS or the entire Intel ME region. Equipment manufacturers should block access to the region from ME, but unfortunately, this is not done by all [8]. In the event that there is such a configuration error on the system, this automatically makes it vulnerable.

Intel ME provides a standard capability to provide write access to the ME region by sending a special HMR-FPO message on HECI from the BIOS [9]. The attacker can send such a message using a vulnerability in the BIOS or DMA attack.
In 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 hacking of the platform.

One of the most pressing issues is the question of the possibility of remote operation. It seems to us that such a possibility exists if the following conditions are fulfilled:

  1. The platform with the activated AMT is attacked.
  2. The attacker knows the AMT administrator password or uses a vulnerability to bypass authorization.
  3. The BIOS does not have a password (or it is known to an attacker).
  4. The BIOS has the option to allow write access to the ME region.

Fulfilling these conditions allows an attacker to gain access to the ME region remotely.

Note also that ROM does not control the Intel ME version at startup, which makes it possible to upgrade to the old version containing the vulnerability.

2.10. Vulnerability Overview CVE-2017-5705,6,7

The vulnerability was identified by 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 went up an 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 found the vulnerability of Intel ME, which allows you to execute arbitrary code. This threatens all technologies such technologies 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 found in the bup module, we managed to turn on a mechanism called PCH red unlock, which opens full access to all PCH devices, for use through 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 executed on ME, read the memory of all processes and the kernel, and also manage all the devices inside the PCH. We counted in aggregate about 50 internal devices, full access to which has only ME, and the main processor only to a very limited subset.

We do not claim that there are no mistakes 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.

Leave a Reply