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:
1. User-mode execution (ring 3)
2. Kernel mode execution (ring 0)
3. SMM execution (ring -2)
4. 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.
Source:https://www.cylance.com
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
