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.
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:
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
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.
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 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.
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:
2017-01-03: Cylance attempted to contact firstname.lastname@example.org - email bounced.
2017-01-03: Cylance attempted to email email@example.com and firstname.lastname@example.org - email to email@example.com bounced; email to firstname.lastname@example.org bounced (MX error).
2017-01-13: Cylance attempted to email email@example.com.
2017-01-05: Cylance sent a second email to firstname.lastname@example.org as well as email@example.com.
2017-01-06: Cylance sent another email to firstname.lastname@example.org and email@example.com.
2017-01-10: Cylance sent another email to firstname.lastname@example.org, email@example.com, and also added firstname.lastname@example.org and email@example.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.