Last month at the RSA 2017 conference, we ran a live demo of Cylance’s UEFI Ransomware proof of concept at our ‘Hacking Exposed Next-Gen’ talk. In the demo, we targeted a system with an Intel Skylake CPU running Microsoft Windows 10 Enterprise (1607) with all updates installed. We activated all security features including Secure Boot, Virtual Secure Mode (VSM), and Device Guard (with its default policy).
All of the details about the vulnerabilities we exploited, the disclosure process, and target platforms will soon be unveiled at Black Hat Asia 2017 in our talk, titled: ‘UEFI Firmware Rootkits: Myths and Reality’.
These new mitigations, based on virtualization technologies in Windows 10, are vulnerable to UEFI-based attacks from System Management Mode (SMM). Because SMM allows direct access to physical memory, it’s possible to bypass the virtualization layer of isolation (Intel VT-x) . This kind of attack is already discussed in detail in ‘Attacking Hypervisors via Firmware and Hardware’. Another interesting piece of research was presented by Rafal Wojtczuk last year: ‘Analysis of the Attack Surface of Windows 10 Virtualization-Based Security’.
Figure 1
Microsoft also recently raised the line of requirements for OEMs for an upcoming update on Windows 10 (1703), presumably in an effort to improve UEFI security requirements. Similary, Intel Software Guard Extensions (SGX) was recently introduced, which is designed to help avoid SMM-based attacks.
However, due to the severity of code execution vulnerabilities − with the privileges of SMM − it’s still possible to fully disclose memory, subsequently breaking ‘isolation by virtualization’.
In our RSA presentation, we focused on the possibilities of persistent rootkit installation or even a ransomware for modern hardware in order to demonstrate the impact of this type of attack. I’ve already discussed some of these ideas in ‘UEFI Firmware Rootkits: Myths and Reality’, which was presented at last year’s ZeroNights Conference. As part of this research, we showed the generic concept of the delivery method for firmware infection, along with possible remote scenarios (Figure 2).
Figure 2
User-Mode
Stage 1:
– Client-side exploit drops installer (1)
– Installer elevates privileges to LOCALSYSTEM
Kernel-Mode
Stage 2:
– Installer bypasses code signing policies
– Kernel-mode payload is then installed (2)
System Management Mode
Stage 3:
– SMM exploit is executed
– Privileges are elevated to SMM
– SMM payload is executed (3)
SPI Flash
Stage 4:
– Flash Write Protection is bypassed (not enabled)
– Rootkit is then installed into firmware (on SPI flash)
As previously mentioned, the talk presented a simplified, generic scheme of a possible attack scenarios. It’s also worth noting that not all of the UEFI firmware versions have the same level of security. Some vendors care about security more than others, it seems, and they add additional security measures into their firmware to stop some of these low-hanging fruit attacks from the start.
One example of this is that models of laptops most often used in corporate environments usually get updates more frequently. Unfortunately, some vendors don’t set simple protection bits for SMM and SPI flash memory (BLE, BWE, PRx), which Intel introduced years ago. This makes them easy targets for attackers, since they have no active memory protections at the hardware level (Figure 3).
Figure 3
As seen in Figure 3, this particular target does not have write protection on BIOS or SPI flash memory ranges. This means an attacker could write directly to the SPI flash memory after elevating privileges to SMM, effectively allowing them to backdoor the firmware.
Additionally, this particular vendor did not properly verify firmware updates, which opened the doors for delivery of our ransomware by way of their BIOS updater software. Our proof of concept took advantage of a kernel-mode driver for the BIOS updater, which then delivers the infected BIOS to the SPI flash. The new attack scenario which we’re presenting at Black Hat Asia 2017 is shown in Figure 4:
Figure 4
Impact and Mitigation
Suffice to say, this type of low-level infection could be devastating for end-users or even an entire organization. Imagine a critical system being ransomed at the hardware (BIOS/UEFI firmware) level, potentially bringing operations to a halt.
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 alone in weird places. 🙂
We’ll reveal the full attack scenario and our disclosure process here after the Black Hat Asia talk in a few weeks.
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.
