Intel(R) Active Management Technology MEBx Bypass
=================================================
The latest version of this advisory is available at:
https://sintonen.fi/advisories/intel-active-management-technology-mebx-bypass.txt
Overview
--------
Intel(R) Active Management Technology leaves the device susceptible to full system
compromise if not configured. Configuring the BIOS password doesn't stop exploitation.
Description
-----------
Intel(R) Active Management Technology comes initially protected with password "admin".
If the AMT is not configured, the default password will allow an attacker with physical
access to the system to enable and configure the AMT. Setting a BIOS password doesn't
prevent access to the Intel(R) Management Engine BIOS Extension (MEBx).
Impact
------
The attacker is able to gain full remote access to the system, regardless of the set
BIOS password, TPM Pin, BitLocker, user credentials and local firewall. Successful
attack leads to complete loss of confidentiality, integrity and availability.
Details
-------
The discovered vulnerabilities, described in more detail below, enable the attack
described here in brief.
In the test scenario the BIOS password is assumed to be set. An attacker briefly gains
access to the affected device ("Evil Maid" scenario). The attack involves enabling AMT
with remote access. For most systems the process is as follows:
1. Reboot the machine and enter the "Intel(R) Management Engine BIOS Extension (MEBx)"
by pressing CTRL-P during POST
Alternatively on Dell laptops you can:
1. Reboot the machine and enter the boot menu (F12 during POST)
2. Select "Intel(R) Management Engine BIOS Extension (MEBx)" from the boot menu
Once in "Intel(R) Management Engine BIOS Extension":
1. Select "MEBx Login"
2. Use password: admin
3. Enter a new password (note it needs to be at least 8 characters long, and must
include each: uppercase letter, digit and special character)
4. Select "Intel(R) AMT Configuration"
5. Select "Activate Network Access" and enable remote access
6. Select "User Consent" and change "User Opt-in" to "NONE"
7. Exit "User Consent" menu and select "MEBx Exit". Choose Y to exit
To enable access over Wi-Fi:
8. Connect to the system over ethernet (NOTE: DHCP server is required to provide IP)
9. Use a browser to visit http://TARGETIP:16992/wlan.htm (username admin, and the
password set in step 3.)
10. Change "Wireless Management" to "Enabled in S0, Sx/AC" and select "Submit"
From now on the attacker can access the system remotely from wired and wireless network
by using the password set. The access requires the attacker to gain access to the same
network segment as the victim. Typically the access is possible via Intel(R) Wi-Fi and
wired network. The access can be done with for example with the Open MDTK Tool:
http://www.meshcommander.com/open-manageability
Instead of provisioning manually, it is also possible to provision with a specially
crafted USB stick. USB provisioning may have been disabled however, in which case the
manual provisioning may be the only vector for the attacker.
In addition, it is possible to configure AMT to connect back to attacker's server by
using Client Initiated Remote Access (CIRA). This way the attack will also work even if
the attacker isn't in the same network segment, assuming the target device can connect
to the internet.
In case the AMT has already been configured, with some devices the attacker can perform
a CMOS reset. The password will then return to "admin" and the attack can proceed as
described above.
Vulnerabilities
---------------
1. Incorrect Access Control
Setting a BIOS password doesn't prevent access to the Intel(R) Management Engine BIOS
Extension (MEBx) when the AMT password hasn't been set. Not being protected by BIOS
password in this case is unexpected and surprising behaviour. As a result a number of
devices that don't have the Intel(R) Active Management Technology password configured
can be exploited even when they are thought to be protected by the BIOS password.
2. Missing Documentation Leading To Insecure Configuration
Due to missing warning about the importance of changing the password for the Intel(R)
Active Management Technology, many devices are left susceptible to attacks.
Leaving Intel(R) Active Management Technology unconfigured exposes the device to
physical attackers configuring the password and enabling remote access.
3. Intel(R) Active Management Technology password bypass
An attacker with physical access to the device can reset the Intel(R) Active Management
Technology password by removing the CMOS battery. Once reset, the attacker can then
enable AMT via the Intel(R) Management Engine BIOS Extension (MEBx) and remote access
by using the restored default password "admin". BitLocker should protect against this
attack however, if the system is equipped with a TPM chip. Once TPM is cleared, the
BitLocker can only be unlocked with the recovery key. Such prompt should be a clear
indication of foul play.
Vulnerable devices
------------------
Vulnerability 1 applies to at least Dell, Lenovo, Fujitsu and HP laptops with
Intel(R) Management Engine support. It is extremely likely this issue affects most, if
not all, devices implementing Intel(R) Active Management Technology. The following
manufacturers are potentially affected: Acer, Panasonic, Toshiba, Getac, Intel and
Samsung.
As a notable exception ASUS devices are not vulnerable: user is prompted to enter the
BIOS password before entering Intel(R) Management Engine BIOS Extension (MEBx).
Vulnerability 2 depends on the documentation of the device, and so far no documentation
has highlighted the importance of configuring the AMT password.
Vulnerability 3 has been confirmed on at least Dell devices. It is likely that some
other devices and vendors are effected as well. ASUS Kaby Lake / Skylake based devices
are not affected.
Recommendations to device vendors
---------------------------------
1. Require the BIOS password to configure/provision the AMT if BIOS password is set and
AMT password is not yet configured (AMT is unprovisioned).
2. Highlight the importance of changing the AMT password in documentation and possibly
in the BIOS itself. BIOS might for example show a warning message that must be
manually bypassed until the AMT is provisioned or AMT is disabled. This would
ensure that the configuration cannot be left in insecure state.
3. Make it more difficult to remove the AMT password. Simply removing the CMOS battery
should not make it possible to take over the device via AMT.
Recommendations to organizations
--------------------------------
1. Adjust the system provisioning process to include setting a strong AMT password,
and disabling AMT if this option is available.
2. Go thru all currently deployed devices and configure the AMT password. If the
password is already set to an unknown value consider the device suspect and initiate
incident response procedure.
End user mitigation
-------------------
1. Contact your IT service desk (if you have one) to handle the situation. If you're
an individual running your own device(s) change the AMT password to a strong one
even if you don't plan on using AMT. If there's an option to disable AMT, use it.
If the password is already set to an unknown value consider the device suspect.
Intel response
--------------
Intel has sent recommendations to vendors to protect the Intel MEBx with the system
BIOS password. Intel has also recommended that vendors provide a system BIOS option to
disable USB provisioning and to set the value to disable by default.
Reference:
https://www.intel.com/content/dam/support/us/en/documents/technologies/Intel_AMT_Security_Best_Practices_QA.pdf
Similar or prior work
---------------------
1. CERT-Bund CB-K15-1256 - https://www.cert-bund.de/advisoryshort/CB-K15-1256
This advisory covers a similar situation, however, not quite the same (for some
reason it focused on USB alone, as well as Intel's response). Nevertheless,
following the sound recommendations in the advisory would also protect against
the attack described here.
2. Parth Shukla from Google covered the issue (and many other related topics) in his
excellent 17th Oct 2017 presentation "Intel AMT: Using & Abusing the Ghost in the
Machine" - https://www.youtube.com/watch?v=aiMNbjzYMXo
3. INTEL-SA-00075 - https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075
This advisory covers an authentication bypass vulnerability in AMT implementation,
unrelated to findings described here.
4. INTEL-SA-00086 -
https://www.intel.com/content/www/us/en/support/articles/000025619/software.html
This advisory covers multiple vulnerabilities in Intel Management Engine,
unrelated to findings described here.
Credits
-------
These vulnerabilities were discovered by Harry Sintonen / F-Secure Corporation.
Other parties have discovered the issue independently as well.
Timeline
--------
2017.07.04 discovered the issues
2017.07.05 wrote a preliminary advisory
2017.07.06 contacted CERT/CC for help in coordination
2017.07.07 CERT/CC tracks the issues as VR-868
CERT/CC advised to contact all affected vendors individually
2017.07.07 revised the advisory with the CMOS battery attack vector
2017.07.07 contacted Fujitsu and ASUS for a PGP key
2017.07.07 received the PGP key from ASUS
2017.07.07 sent the advisory to Intel, Dell, Lenovo, HPE, ASUS and Panasonic
2017.07.07 Lenovo PSIRT confirmed receipt of the advisory
2017.07.07 Hewlett Packard Enterprise PSRT confirmed receipt of the advisory and
suggested to contact HP PSRT as well, which is a diffent entity
2017.07.07 Panasonic PSIRT confirmed receipt of the advisory
2017.07.08 sent "get key" message to hp-security-alert@hp.com to get a PGP key for
secure communications
2017.07.08 sent email to security@acer.com and secure@acer.com asking for secure means
of sending the advisory. both addresses were undeliverable
2017.07.08 sent email to security@toshiba.com and secure@toshiba.com asking for secure
means of sending the advisory. both addresses were undeliverable
2017.07.08 sent email to GetacSupport_US@getac.com asking for secure means of sending
the advisory
2017.07.08 sent email to security@samsung.com asking for secure means of sending the
advisory
2017.07.09 again sent "get key" message to hp-security-alert@hp.com without success.
sent manual request for the PGP key instead
2017.07.09 sent support request via https://uk.answers.acer.com/app/ask asking for
security contact
2017.07.09 sent email to Toshiba media relations contact asking for security contact
2017.07.09 sent email uk.escalations@acer.com regarding the security contact, as
directed by Acer support
2017.07.10 Fujitsu refused to reply to my PGP key request due to inability to confirm
the email S/MIME signature. attempted to explain the nature self signed
S/MIME PKI infrastructure to Fujitsu (i.e. it's at least as secure as no
no S/MIME at all)
2017.07.10 ACER Esc Support wished me to outline the vulnerabilities. asked for secure
means of doing so
2017.07.10 ASUS Security confirmed receipt of the advisory and requested further
clarification on test method. referred ASUS to Details section in this
advisory
2017.07.10 added Open MDTK Tool link to Details section
2017.07.10 received PGP key and security contact information from ACER Esc Support
2017.07.10 received PGP key from HP PSRT
2017.07.11 sent the advisory to Acer security contact and HP PSRT
2017.07.11 adjusted the advisory: some clarifications and additional comments
2017.07.11 resent the advisory credentials to HP PSRT
2017.07.11 HP PSRT assigned case number PSR-2017-0115 to this report
2017.07.11 realized I had sent the advisory to a wrong Intel email address. resent it
to correct Intel PSIRT email address
2017.07.11 received the PGP key from Fujitsu
2017.07.11 sent the advisory to Fujitsu
2017.07.11 according to ASUS Security they're not affected by vulnerability 1 and 3
2017.07.11 adjusted the advisory according to ASUS statements
2017.07.11 resent the advisory to Acer, as requested
2017.07.11 Acer confirmed receipt of the advisory
2017.07.11 Lenovo PSIRT pointed out the earlier USB Thumb Drive Provisioning
Vulnerability CB-K15/1256
2017.07.11 Dell EMC & Dell confirmed the receipt of the advisory and is tracking the
issue as PSRC-4585
2017.07.12 adjusted the advisory to cover CERT-Bund CB-K15/1256 advisory by adding a
prior work section. also added INTEL-SA-00075 to this section
2017.07.12 some grammar fixes
2017.07.12 received security contact details from Samsung
2017.07.12 sent the advisory to Samsung
2017.07.12 resent the advisory to Intel
2017.07.12 attempt to contact Getac via the web form
2017.07.12 Intel PSIRT confirmed receipt of the advisory
2017.07.12 some rewording of the recommendations
2017.07.13 asked JPCERT/CC to relay the informationt to Toshiba
2017.07.13 asked TWNCERT to relay the information to Getac
2017.07.13 added clarification to vulnerability 3 about BitLocker
2017.10.24 added steps required to enable network access over Wi-Fi
2017.10.29 resent the message to JPCERT/CC
2017.10.29 added Parth Shukla's "Intel AMT: Using & Abusing the Ghost in the Machine"
presentation to prior work section
2017.12.07 notified CERT-CC, Intel and vendors about the upcoming publication
2017.12.07 received the following from Intel PSIRT: "Intel PSIRT revised the OEM
guidance, originally published under NDA in 2015, for AMT provisioning
thanks to both Parth and your feedback. The revised guidance was published
to OEM customers under NDA in early November 2017 as part of Intel document
id 561211."
2017.12.13 received response from Intel describing the actions taken. added section
describing Intel's response to the issue. also added reference to
"Intel AMT Security Best Practices QA".
2018.01.12 public disclosure.