CVE-2017-5689 - Intel AMT Vulnerability in Detail
At the beginning of 2017, Maxim Malyutin (Maksim Malyutin) from Embedi discovered a vulnerability in Intel AMT, which was officially announced by Intel on May 1 and received the number CVE-2017-5689 (INTEL-SA-00075 in Intel codification). The vulnerability was assigned the type of “elevation of rights” (Elevation of Privilege) and the critical level of danger. Many media outlets responded with headlines of something like “Intel server chipsets for 9 years had a vulnerability,” apparently based on the phrase “Intel-based consumer PCs” in the description. However, this is not quite the case with the transition to something completely different. Therefore, further detailed technical description of the vulnerability, its implementation and, most importantly, protection methods for systems that do not have firmware updates.
Without delving into the details of what Intel Active Management Technology (AMT) technology is, nevertheless, it should be noted that you should not confuse Intel ME and Intel AMT, since AMT is just one of the modules (relatively speaking, a plugin) running on the Intel ME engine. The major version of Intel ME changes with each generation of processors, along with it, the major version of Intel AMT also changes. The vulnerability affected all versions from Intel AMT 6 (respectively, Intel ME 6 and above) - up to the newest (Intel ME 11.6 at the time of this writing).
You also need to add that Intel Standard Manageability (ISM) is a stripped-down version of Intel AMT (with limited functionality, but this is AMT), but Intel Small Business Technology (SBT) is a technology that uses AMT functionality for its work (inaccurate definition but in general this sense), but it is not at all (this is another, separate plugin in the Intel ME engine).
')
Intel AMT requires three components:
Only the presence of all three gives full support for Intel AMT. Roughly (without very old and dividing into mobile / desktop) Intel chipsets can be divided into:
Intel AMT technology is supported only by chipsets from the 3rd and 5th paragraph, and Intel SBT technology from the 2nd - only these segments are affected by the vulnerability CVE-2017-5689. If, however, to clarify, due to the “indirect” relationship of SBT to AMT, the 2nd point can only be considered conditionally, and the 5th item that supports at the chipset level usually disappears, since server chipsets are designed to use BMC controllers for remote control, largely duplicating the functionality of Intel AMT (or vice versa), so vendors are not particularly in a hurry to implement BMC support and AMT support, while support for Intel AMT is also needed three conditions (see above).
Accordingly, almost always, if Intel AMT is available, only Qxx chipsets will be discussed.
In systems SoC (System on Chip - when the processor and chipset are integrated) it is more difficult to find out support for AMT, because It depends on the specific model. In general, processors that support Intel AMT can be found at ark.intel.com/ru/Search/Advanced?ExtendedPageTables=True , selecting the box at the bottom of the box “Intel vPro Technology” (but also you should not forget about the BIOS support requirements).
Vulnerability can be used:
In all cases, it is required that the AMT technology be already initialized / configured.
A separate unpleasant thing is the fact that an unconfigured computer, starting with Intel AMT version 7 and higher, can be programmatically initialized locally into client mode (that is, even from a configured state). Therefore, in the recommendations from Intel to combat the vulnerability CVE-2017-5689, in addition to various gestures from the “turn off everything” category, there are optional “Disable CCM” - disable client mode and “Disable HBE” - disable automatic AMT initialization (not applicable for normal computers- laptops - this is only for embedded systems). Because with the help of these features, designed to simplify software initialization, this procedure can be done on any system with AMT support (the exception is the forbidden AMT in the BIOS).
All the details of finding the vulnerability are given in the original , they are made on the example of Intel AMT 9 system. In short, there was a disassembled part that handles requests to the Intel AMT embedded web server by the characteristic headers (username, realm, nonce, etc.) of the authentication process:
When examining the output of the authorization check function (the “Authorization” header), where the passwords are compared (transferred to the set one), the password check code was found:
As a result, the third argument for the strncmp () function is the number of compared characters, the length is loaded from our answer, which means that with a zero value, strncmp will always give true .
It is clear that this is a mistake of the developer who had to specify as the password length to be checked, not the length transmitted by the authorizing user (which can be done by anyone, including transferring the value of zero length), but the set (admin) password.
The Embedi document described a simple version with local access with configured AMT without using TLS - when using the AMT port 16992. To avoid repeating, another case will be given - access to an AMT-enabled computer on the local network configured to use TLS ( Ie through AMT-port 16993).
Connect to the system with AMT support (because when connecting via TLS, the server name is checked, the FQDN is used, not the IP):
Logging in with the standard login admin and leaving the password field empty will not work (which is understandable):
Now let's manipulate the HTTP headers, for this we use the extension for Firefox HttpRequester .
We make a test request (the data is not important) in order to simply find out the realm from the answer (in the error in the WWW-Authenticate header there will be a parameter needed to compose a further request:
Now add the “Authorization” header manually:
And as the value we specify the previously obtained realm and the following parameters:
Then click Add and send the request.
We are interested in the nonce parameter, which is unique for each session. Add it to the header (for this you have to delete the old one and add a new one), something like this should turn out:
Adjusted for each time a different nonce and its realm .
The vulnerability itself is highlighted in bold — the password is empty, so that after it is checked for its zero length.
We send drawn up in this way (but quickly enough - before the session has expired):
There is a login, now you can open the page in Firefox:
There were no password requests.
Intel's recommendations for protection against CVE-2017-5689 are mainly to disable AMT on its supporting systems. But, first, many (for example, I) are happy to use and want to use this really convenient remote administration technology (especially having mastered its work through the Internet), and therefore there is no desire to refuse it, simply switching off AMT in the BIOS. Secondly, according to the experience of past problems of various vendors with disabling AMT in the BIOS, it is easy to assume similar ones in the future - when Intel AMT technology disabled in the BIOS for some reason worked or could be activated (despite “Disabled” in BIOS Setup). Knowing this, the most appropriate recommendation is always to initialize and properly configure the AMT — just to protect systems with Intel AMT support (as opposed to “disconnect and / or un-configure”). The correct configuration, including the use of certificates for authentication (in addition to password), includes how much was said about the unreliability of password protection, it's silly to repeat.
You can use various utilities for this, for example, Intel's official Manageability Commander (or another convenient one, I prefer MeshCommander ).
(You should not pay attention to “Invalid TLS”, because a self-signed certificate is used)
We close access for non-TLS connections and enable client authentication for both local (via LMS) and remote access (over the network and the Internet), having previously created and downloaded the necessary certificates.
Now when you try to log in first (before the password vulnerability) there will be a certificate request:
And only by providing the correct certificate, whose hash root was previously added to the AMT certificate store of the computer and whose DNS was registered in the list of allowed, access to the system will be obtained. Where is the next request for a password (vulnerable).
Thus, the AMT system will be protected and it can be used as usual, even if the firmware update fixing the vulnerability CVE-2017-5689 will not be released by the manufacturer of your system.
References:
Intel ME, AMT, ISM, SBT
Without delving into the details of what Intel Active Management Technology (AMT) technology is, nevertheless, it should be noted that you should not confuse Intel ME and Intel AMT, since AMT is just one of the modules (relatively speaking, a plugin) running on the Intel ME engine. The major version of Intel ME changes with each generation of processors, along with it, the major version of Intel AMT also changes. The vulnerability affected all versions from Intel AMT 6 (respectively, Intel ME 6 and above) - up to the newest (Intel ME 11.6 at the time of this writing).
You also need to add that Intel Standard Manageability (ISM) is a stripped-down version of Intel AMT (with limited functionality, but this is AMT), but Intel Small Business Technology (SBT) is a technology that uses AMT functionality for its work (inaccurate definition but in general this sense), but it is not at all (this is another, separate plugin in the Intel ME engine).
')
Hardware
Intel AMT requires three components:
- AMT support in the chipset
- AMT support in the processor
- AMT support in BIOS
Only the presence of all three gives full support for Intel AMT. Roughly (without very old and dividing into mobile / desktop) Intel chipsets can be divided into:
- Regular - Hxx and Zxx Chipsets
- Small Business - Bxx Chipsets
- Business / Corporate - Qxx Chipsets
- "For enthusiasts" - Xxx chipsets
- Server - C2xx Chipsets
Intel AMT technology is supported only by chipsets from the 3rd and 5th paragraph, and Intel SBT technology from the 2nd - only these segments are affected by the vulnerability CVE-2017-5689. If, however, to clarify, due to the “indirect” relationship of SBT to AMT, the 2nd point can only be considered conditionally, and the 5th item that supports at the chipset level usually disappears, since server chipsets are designed to use BMC controllers for remote control, largely duplicating the functionality of Intel AMT (or vice versa), so vendors are not particularly in a hurry to implement BMC support and AMT support, while support for Intel AMT is also needed three conditions (see above).
Accordingly, almost always, if Intel AMT is available, only Qxx chipsets will be discussed.
In systems SoC (System on Chip - when the processor and chipset are integrated) it is more difficult to find out support for AMT, because It depends on the specific model. In general, processors that support Intel AMT can be found at ark.intel.com/ru/Search/Advanced?ExtendedPageTables=True , selecting the box at the bottom of the box “Intel vPro Technology” (but also you should not forget about the BIOS support requirements).
Access
Vulnerability can be used:
- Locally on the AMT computer - the required AMT drivers are required, in particular, the LMS driver
- On the local network, the firewall does not protect at that; AMT technology intercepts traffic to OS processing. In addition, the computer can be turned off altogether (but connected to the network + power supply)
- On the Internet - in case the computer was configured for AMT operation via Intel MPS (plus the previously mentioned in clause 2)
In all cases, it is required that the AMT technology be already initialized / configured.
A separate unpleasant thing is the fact that an unconfigured computer, starting with Intel AMT version 7 and higher, can be programmatically initialized locally into client mode (that is, even from a configured state). Therefore, in the recommendations from Intel to combat the vulnerability CVE-2017-5689, in addition to various gestures from the “turn off everything” category, there are optional “Disable CCM” - disable client mode and “Disable HBE” - disable automatic AMT initialization (not applicable for normal computers- laptops - this is only for embedded systems). Because with the help of these features, designed to simplify software initialization, this procedure can be done on any system with AMT support (the exception is the forbidden AMT in the BIOS).
Disassembling
All the details of finding the vulnerability are given in the original , they are made on the example of Intel AMT 9 system. In short, there was a disassembled part that handles requests to the Intel AMT embedded web server by the characteristic headers (username, realm, nonce, etc.) of the authentication process:
When examining the output of the authorization check function (the “Authorization” header), where the passwords are compared (transferred to the set one), the password check code was found:
ld r1, [sp:user_response+10ch]; → r1 ( strncmp) mov r0, r13 ; - → r0 ( strncmp) ld r2, [sp:a4h] ; → r2 ( strncmp) bl strncmp ; call strncmp() As a result, the third argument for the strncmp () function is the number of compared characters, the length is loaded from our answer, which means that with a zero value, strncmp will always give true .
It is clear that this is a mistake of the developer who had to specify as the password length to be checked, not the length transmitted by the authorizing user (which can be done by anyone, including transferring the value of zero length), but the set (admin) password.
Practical verification of AMT vulnerability
The Embedi document described a simple version with local access with configured AMT without using TLS - when using the AMT port 16992. To avoid repeating, another case will be given - access to an AMT-enabled computer on the local network configured to use TLS ( Ie through AMT-port 16993).
Connect to the system with AMT support (because when connecting via TLS, the server name is checked, the FQDN is used, not the IP):
Logging in with the standard login admin and leaving the password field empty will not work (which is understandable):
Now let's manipulate the HTTP headers, for this we use the extension for Firefox HttpRequester .
We make a test request (the data is not important) in order to simply find out the realm from the answer (in the error in the WWW-Authenticate header there will be a parameter needed to compose a further request:
Now add the “Authorization” header manually:
And as the value we specify the previously obtained realm and the following parameters:
Digest username = "admin", realm = "Digest: EB580000000000000000000000000000", uri = "/ index.htm", qop = auth, nc =, cnonce = "", opaque = ""
Then click Add and send the request.
We are interested in the nonce parameter, which is unique for each session. Add it to the header (for this you have to delete the old one and add a new one), something like this should turn out:
Digest username = "admin", realm = "Digest: EB580000000000000000000000000000", nonce = "dh8jcw1CAQCTmvMOLG5UghjzJper6NvS", uri = "/ index.htm", qop = auth, nc =, cnonce = "amethropheme,", index, htm ", index) "
Adjusted for each time a different nonce and its realm .
The vulnerability itself is highlighted in bold — the password is empty, so that after it is checked for its zero length.
We send drawn up in this way (but quickly enough - before the session has expired):
There is a login, now you can open the page in Firefox:
There were no password requests.
Protection of existing AMT systems (with CVE-2017-5689 error in firmware) using certificate authentication authentication (mutual auth)
Intel's recommendations for protection against CVE-2017-5689 are mainly to disable AMT on its supporting systems. But, first, many (for example, I) are happy to use and want to use this really convenient remote administration technology (especially having mastered its work through the Internet), and therefore there is no desire to refuse it, simply switching off AMT in the BIOS. Secondly, according to the experience of past problems of various vendors with disabling AMT in the BIOS, it is easy to assume similar ones in the future - when Intel AMT technology disabled in the BIOS for some reason worked or could be activated (despite “Disabled” in BIOS Setup). Knowing this, the most appropriate recommendation is always to initialize and properly configure the AMT — just to protect systems with Intel AMT support (as opposed to “disconnect and / or un-configure”). The correct configuration, including the use of certificates for authentication (in addition to password), includes how much was said about the unreliability of password protection, it's silly to repeat.
You can use various utilities for this, for example, Intel's official Manageability Commander (or another convenient one, I prefer MeshCommander ).
(You should not pay attention to “Invalid TLS”, because a self-signed certificate is used)
We close access for non-TLS connections and enable client authentication for both local (via LMS) and remote access (over the network and the Internet), having previously created and downloaded the necessary certificates.
Now when you try to log in first (before the password vulnerability) there will be a certificate request:
And only by providing the correct certificate, whose hash root was previously added to the AMT certificate store of the computer and whose DNS was registered in the list of allowed, access to the system will be obtained. Where is the next request for a password (vulnerable).
Thus, the AMT system will be protected and it can be used as usual, even if the firmware update fixing the vulnerability CVE-2017-5689 will not be released by the manufacturer of your system.
References:
Source: https://habr.com/ru/post/328232/
All Articles