It has been a busy and exciting few weeks for the team here at Eclypsium, capped off with the chance to deliver talks at Black Hat and DEFCON on some of our latest research. In this blog I want to give a basic overview of what we found, but also talk a little bit about what I think it means for security in a broader sense.
Attacks Against Common UEFI
Let’s start with a quick summary of our talk at Black Hat. If you read our previous blog, we highlighted the risks posed by remote management features in modern servers. And while servers have long had their own networking capabilities for remote management, we have started to see the same sort of networking functionality showing up in the system UEFI firmware (modern-day BIOS) for many standard systems.
In short, the standard UEFI codebase now includes a rich set of network capabilities for Ethernet, WiFi, and even Bluetooth that allow the firmware to communicate remotely and even perform a full HTTP boot from a remote server across the internet. Additionally, vendors have individually been implementing “update over the Internet” features that allow the computer to check for and download firmware updates from a remote server before the host operating system is ever loaded.
As part of our research we found that common firmware from ASRock and ASUS were both vulnerable to a basic buffer overflow vulnerability, which could allowing arbitrary remote code execution. We were able to demonstrate this vulnerability with proof-of-concept exploit code during our talks at Black Hat and DEFCON.
What Next? How About Remote Exploitability?
So vulnerabilities in UEFI is bad, but things get more interesting from there. We also found that the update over the Internet functionality was essentially happening unverified and in the clear. The host configures the network using DHCP and then makes a request to a remote server using plain HTTP without SSL or verification that the host was actually talking to the correct remote server. This means that if we are able to intercept this request via MITM or otherwise redirect the request to our server (e.g. DNS/ARP/route poisoning, etc), we can modify the response returned to the client and exploit the vulnerability. As a result, we were able to remotely deliver malicious code resulting in buffer overflows and arbitrary code execution just by checking if a newer version of firmware exists.
Once compromised, an attacker gains almost unlimited power over the device. For example, an attacker could use the NTFS EFI driver to implant malware into the operating system much like the Hacking Team’s UEFI rootkit. Alternatively, an attacker could use the same driver to exfiltrate files stolen off of the hard drive or encrypt them with ransomware or install an SMM rootkit and then let the operating system load normally to attack other assets.
The Bigger Trend Facing Security
So I think it is important to point out that this is pretty new territory. We have seen remotely exploitable vulnerabilities in IPMI for servers before, but this is one of the very few times the industry has seen remotely exploitable vulns in common UEFI firmware. This is a big deal for a few reasons. First, this problem is not going away. Networking has become a standard component of system firmware, and with the drive for more remote management and administration of systems, it is likely that this functionality is here to stay. With network connectivity comes the opportunity for remote exploitability just as in every other connected device and component in history.
However, this trend also potentially opens up firmware-level attacks to a much larger and much less sophisticated class of attackers. Attack trends and malware almost always eventually trend downmarket from state operators to organized crime to less sophisticated criminal groups to script kiddies. What was originally part of an APT campaign becomes commonplace within months and years. In the past, firmware attacks were the realm of state actors simply because it required a high degree of specialization both to develop and deliver a working implant. However, remotely exploitable firmware potentially opens this style of attack to the masses. The barrier to entry could quickly be reduced to buying a firmware exploit and payload, and then have the ability to intercept or redirect traffic (again via common techniques like MitM, ARP/DNS poisoning, etc).
Quite simply, most organizations are not prepared for this style of threat. Visibility is often limited, patching is slow and manual, and threat prevention typically just does not exist at the hardware and firmware level. This is a greenfield for attackers, and remotely exploitable firmware could get them there sooner rather than later.
