Earlier this month, we teased a proof of concept for UEFI ransomware, which was presented at RSA Conference 2017. The HackingTeam, Snowden, Shadow Brokers, and Vault7 leaks have revealed that UEFI/BIOS implants aren't just a theoretical concept, but have actually been weaponized by nation states to conduct cyber-espionage. Physical access requirements are a thing of the past; these low-level implants can be installed remotely by exploiting vulnerabilities in the underlying UEFI system.
Today at BlackHat Asia 2017, we are disclosing two vulnerabilities in two different models of the GIGABYTE BRIX platform:
- GB-BSi7H-6500 – firmware version: vF6 (2016/05/18)
- GB-BXi7-5775 – firmware version: vF2 (2016/07/19)
These vulnerabilities allow an attacker to elevate privileges, execute arbitrary code in System Management Mode (SMM), and install a backdoor at the firmware level. We have reported these vulnerabilities to the vendor (see our full disclosure timeline at the end of this post).
Firmware backdoors are difficult to detect because they execute in the early stages of the boot process and they can persist across operating system (OS) re-installations:
Figure 1: Attack Flow Chart to Install a UEFI Backdoor
A practical attack consists of 4 stages:
- User-mode execution (ring 3)
- Kernel mode execution (ring 0)
- SMM execution (ring -2)
- SPI Flash Write
The attacker gains user-mode execution through an application vulnerability such as a browser exploit or a malicious Word document with an embedded script. From there, the attacker elevates his privileges by exploiting the kernel or a kernel module such as Capcom.sys to execute code in ring 0. A vulnerable SMI handler allows the attacker to execute code in SMM mode (ring -2) where he finally can bypass any write protection mechanisms and install a backdoor into the system's firmware.
Write-protection mechanisms exist to prevent attackers from modifying the firmware; however, the affected systems do not enable them. Figure 2 shows the CHIPSEC output of a system which has enabled BIOS Lock Enable (BLE) and SMM BIOS Write Protection (SMM_BWP) to prevent modifications to the BIOS:
Figure 2: CHIPSEC Output of a Write Protected BIOS
It is up to the motherboard manufacturers to correctly implement the UEFI firmware and enable the appropriate protection mechanisms to prevent unauthorized modifications to the firmware. However, as seen below in figure 3, not all manufacturers will ship their systems with the protections enabled:
Figure 3: CHIPSEC Output of a Non-Write-Protected BIOS
CLVA-2017-01-001 / CVE-2017-3197
A vulnerable SMI handler, SmiFlash (GUID: BC327DBD-B982-4F55-9F79-056AD7E987C5), does not validate the input pointers, allowing an attacker to execute in System Management Mode (ring –2).
Gigabyte's implementation of the American Megatrends Inc. (AMI) firmware does not enroll in the necessary protection mechanisms (BIOSWE, BLE, SMM_BWP, and SPI Protect Ranges) to prevent unauthorized writes to the SPI flash.
This vulnerability can triggered by using an SMI fuzzer in the CHIPSEC project:
Our formal advisory is in our Vulnerability Disclosures repository: CLVA-2017-01-002.
CLVA-2017-01-002 / CVE-2017-3198
The GIGABYTE UEFI firmware does not cryptographically validate images prior to updating the system firmware. Additionally, the firmware updates are served over HTTP without checksums for verifying authenticity.
An attacker can use the provided AMI Firmware Update (AFU) utility to write arbitrary code to the firmware.
Rather than go through the trouble of finding a vulnerability to get ring 0 and ring -2 code execution, an attacker could just use the AFU program to write a backdoor into the system's firmware. Figure 4 demonstrates how an attacker would use the AFU utility delivered through a Word document containing an embedded Powershell dropper to update the firmware with a ransomware payload to block the system from booting into the OS.
Figure 4: Overview of an Attack Using the Firmware Updater
Our formal advisory is in our Vulnerability Disclosures repository: CLVA-2017-01-002. At BlackHat Asia 2017, we used the following platform configuration to demonstrate the impact of this vulnerability with persistent installation of UEFI ransomware:
- Gigabyte (GB-BSi7HA-6500)
- Intel 6th generation Core i7 CPU (Skylake)
- BIOS Lock (BLE) – ENABLED (not enabled by default)
- MS Windows 10 Enterprise
- All latest updates installed
- Virtualization Based Security (VBS) - ENABLED
- Device Guard – ENABLED
- Secure Boot – ENABLED
Vendor Response
GIGABYTE will be releasing a firmware update (vF7) for the GB-BSi-7H-6500 to address these vulnerabilities. The GB-BXi7-5775 is end of life (EOL) and will not be updated.
Impact and Mitigation
As mentioned in our previous post, successful infection at such a low level has the potential to be disastrous. UEFI rootkits and ransomware, as we demonstrated at both RSA Conference and BlackHat Asia, could provide attackers with a degree of control that is difficult, if not near-impossible, to detect or rectify.
However, there are approaches to potentially help reduce this risk:
- Update your BIOS as soon as vendors release updates. Depending on the manufacturer of your machine(s), you may need to use a specific updater. Download the updates and updater only from trusted vendor resources.
- Enable the most recent hardware Intel BIOS and Boot Guards technologies in your BIOS setup menu. This will prevent and reduce some of the risks of firmware-based attacks.
- For the technically inclined, audit your own BIOS/UEFI firmware! The CHIPSEC framework is a great starting point for identifying the known types of issues and attack vectors.
- Don't leave your laptop unattended in potentially risky or hostile environments.
Disclosure Timeline
2017-01-03: Cylance attempted to contact security@gigabyte.com - email bounced.
2017-01-03: Cylance attempted to email support@gigabyte.com and support@gigabyte.us - email to support@gigabyte.com bounced; email to support@gigabyte.us bounced (MX error).
2017-01-13: Cylance attempted to email services@gigabyteusa.com.
2017-01-05: Cylance sent a second email to services@gigabyteusa.com as well as csr@gigabyte.com.
2017-01-06: Cylance sent another email to csr@gigabyte.com and services@gigabyteusa.com.
2017-01-10: Cylance sent another email to csr@gigabyte.com, services@gigabyteusa.com, and also added sales@gigabyteusa.com and marketing@gigabyteusa.com.
2017-01-10: Cylance received a response from a representative at Gigabyte, requesting an outline of the issue(s) and any supporting documents. Cylance responded and provided disclosure policy/process doc, and requested PGP key(s).
2017-01-12: Cylance sent a follow up email to Gigabyte contact, asking if they would prefer an alternate mechanism for secure transmission of the vulnerability information.
2017-01-12: Cylance received a response from their contact at Gigabyte, who introduced an additional contact.
2017-01-17: Cylance sent a follow-up email informing both Gigabyte contacts of secure transmission medium, as well as reminding them that Cylance, per disclosure policy, would be contacting CERT/CC on 2017-01-18.
2017-01-17: Cylance used a secure file-sharing medium to share the advisories with Gigabyte.
2017-01-18: Cylance shared both advisories directly with CERT/CC.
2017-01-20: Cylance received acknowledgment from CERT/CC (tracked as VU#507496). CERT/CC requests additional clarification on certain points.
2017-01-23: Cylance replied to CERT/CC, clarifying their questions.
2017-01-24: Cylance sent another email to Gigabyte (cc'ing CERT/CC), indicating that no response has been received by Gigabyte.
2017-01-26: Cylance received a response from Gigabyte citing an impending local holiday as a delay for response.
2017-01-26: Cylance replied to Gigabyte (cc'ing CERT/CC) reminding them of the planned disclosure date (Mar 4, 2017), and offered to discuss pushing the disclosure date out.
2017-02-07: Cylance sent a follow-up email to Gigabyte (cc'ing CERT/CC), reminding them of the planned disclosure date of March 4, 2017.
2017-02-08: Gigabyte responded to Cylance, indicating that they would follow up with AMI directly.
2017-02-08: Cylance responded to Gigabyte, CERT/CC, et. al, asking for confirmation as to whether this is, in fact, an issue on AMI's side and not just Gigabyte's.
2017-02-09: Gigabyte requested additional vendors/models against which these findings were tested.
2017-02-10: Cylance was contacted directly by AMI, who indicated they had received a notification from a customer of theirs.
2017-02-10: Cylance replied to AMI explaining the situation and the planned public disclosure.
2017-02-16: AMI provided Cylance a PGP public key for secure transmission of vulnerability advisories.
2017-02-17: Cylance replied to AMI with the draft vulnerability advisories.
2017-02-20: AMI replied with to Cylance indicating that they provide reference designs to their customers, and the onus is therefore on them to implement certain security measures. Additionally, AMI suggested these issues had already been addressed. (No vulnerability information, including CVEs or links to specific patches/updates has been provided as of today).
2017-02-22: Cylance forwarded AMI's response to CERT/CC.
2017-02-23: CERT/CC replied to Cylance, agreeing that this was mainly a Gigabyte-specific issue. Additionally, CERT/CC indicated that they would likely broadcast to other UEFI vendors in an effort to help them identify similar issues in their codebase(s).
2017-03-06: Cylance updated CERT/CC with a revised disclosure date of 2017-03-31.
2017-03-07: CERT/CC acknowledged Cylance's revised disclosure date.
2017-03-20: Cylance emailed AMI requesting additional information (citations, links to patches, etc.) for the advisory revisions AMI requested, also notifying them of the revised disclosure date.
2017-03-20: Cylance emailed Gigabyte (cc'ing CERT/CC), informing them of the revised disclosure date, and also requesting any citations/links, etc. related to the mitigations or patches for the issues.
2017-03-21: Cylance received a response from Gigabyte, suggesting they were in the process of testing AMI's solution to the issues Cylance identified, and that the results of the proposed fix(es) would be shared with Cylance as well as customers some time in the future.
2017-03-23: CERT/CC shared a draft of their Vulnerability Note with Cylance and Gigabyte.
2017-03-30: Gigabyte informed Cylance and CERT/CC that the BIOS/UEFI update was in the final phase of testing and would soon be available.
2017-03-31: Public disclosure.
