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.