The worlds of gaming and hacking have always shared interesting areas of overlap. For many of us, games were the initial lure that sparked the interest into how computers and applications worked, and likewise, how they can be manipulated. And as long as there have been video games there have also been cheats and cheaters.
However, some of the most recent gaming cheats show that gamers have arrived at the same conclusion as malware and cybersecurity adversaries — one of the best ways to attack the application layer without getting caught is through the firmware. And while most enterprises couldn’t care less if someone cheats at Call of Duty, this type of cheat has serious implications for enterprise cybersecurity teams. Hardware and firmware level hacks are becoming far more accessible, portable, and practical than they ever have been in the past. And while gamers are using hardware attacks to win online battles, you can be sure that cybercriminals will do the same for profit. Let’s take a look at an example and the implications for enterprise security.
An Example Cheat
While gaming cheats have always existed, the massive growth and popularity of online competitive gaming has driven the interest in cheating to unprecedented levels. On a map full of competitive players, a cheater can use an aimbot to automatically target and shoot other players with superhuman speed and accuracy.
Game developers and operators naturally want to maintain a level playing field and are constantly building defenses to detect and prevent cheating. A recent Recon Montreal presentation provides a detailed look at the co-evolution of cheats and anti-cheat techniques, and ultimately showed how a cheat could be developed using a vulnerable Gigabyte driver to arbitrarily read and write physical memory. By accessing memory, the cheater can directly alter the game without relying on suspicious OS hooks and other techniques that are likely to get the attention of anti-cheating tools which also reside at the OS layer.
This recently published cheat takes a slightly different approach to arrive at the same result. Instead of relying on a vulnerable driver, the user loads his own EFI/UEFI firmware driver during the system boot, which can then likewise read/write to the system’s memory. With this backdoor into memory, the cheater has free rein to modify data used by the application and the cheat in virtually any way he chooses. It is important to note that this approach requires the user to disable Secure Boot on the system in order for the cheat to work, yet this is a trivial task. It draws to light the very conundrum we are faced with: a malicious user can configure their device drivers to be malicious, and there’s no good way for anti-cheat or anti-virus engines to detect this scenario.
This cheat takes advantage of a basic assumption in the security model: that the hardware can be trusted. While anti-cheat tools naturally do not trust actions in user space or in the operating system, they don’t extend that same skepticism to the hardware. Unlike gaming consoles (e.g. Playstation, XBox) which go to great lengths to defend their hardware, PC gamers have control over their own hardware. As this cheat shows, if you have an untrustworthy or “malicious” user in control of the hardware, it is fairly straightforward to gain control over the application layer.
Implications for the Enterprise Security Model
These examples of gaming cheats directly apply to far more serious enterprise attacks. The Recon example relied on a vulnerable driver in order to gain access to memory. As Eclypsium research has shown (repeatedly), vulnerable drivers that can provide attackers with read/write access to memory are incredibly common. Malware campaigns including the RobinHood family of ransomware have used vulnerable drivers as a way to disable security products or maintain persistence within an infected host.
The second example relied on an untrusted user disabling secure boot in order to use their own EFI driver. The recently discovered and incredibly widespread BootHole vulnerability would effectively allow an attacker or malware to do the same thing. Instead of having to disable Secure Boot, BootHole allows an attacker to run arbitrary code even when Secure Boot is enabled.
Both cases provide attackers with access to system memory, and in turn, direct control over applications. The ways that such access can be abused in a cyberattack is virtually unlimited. If an attacker knows where an app executes its code inside the memory, a hacker can fine-tune exploits that attack specific applications and steal sensitive information. Financially motivated malware is one example. Attackers have previously infiltrated banks and abused the SWIFT banking network to steal $81 million in funds. Banking trojans such as Zeus, Gozi, and many others have long used man-in-the-browser techniques to manipulate transactions between online users and their banks. With backdoor access to a system’s memory, however, attackers could perform a similar “man-in-the-memory” attack that could manipulate transactions without directly infecting the browser.
The same issues can apply to virtually any level of the enterprise including virtualization. This DEFCON presentation details how a firmware rootkit can allow an attacker to gain full access to the physical memory of the server as well as that of all virtual machines. So in much the same way that gamers can abuse an online game, attackers can abuse an enterprise’s fleet of cloud-based applications.
Ok, But Why Is This a Problem Now?
While many security professionals have long known that firmware threats are possible, the gaming cheats show that threats at this level are also becoming far more practical. And this is potentially the most important take-away for security teams. When firmware hacks start showing up in online gaming, it is a clear sign that we are well outside the realm of targeted attacks and state-backed adversaries.
But why is the bar for firmware attacks suddenly getting lower? There are several factors at play. First, firmware itself is becoming more standardized across multiple platforms and multiple generations of devices. This is key because it means that firmware attacks are no longer limited to bespoke, customized malware targeted to a specific system. It’s hard to believe that 15 years have passed since Stuxnet began its life as code. Adversaries have had that long, now, to really standardize this once-novel vector. When many systems can be targeted, it is suddenly worth an attacker’s time to develop firmware-based threats.
Secondly, the actual development of firmware threats has become far more accessible. Modern firmware is written in C as opposed to assembly, which makes developing firmware threats more modular and less specialized. Modern firmware is also well-documented and extensible. It’s worth remembering the UEFI stands for Universal Extensible Firmware Interface. It is universal and extensible by design, and building an interface for it is a matter of reading the documentation rather than reverse engineering. Additionally, there are open-source implementations of UEFI firmware such as EDK, which make the inner workings of firmware far more visible and accessible to developers. These factors combined with access to low-cost firmware debugging tools and readily available education and training, mean that attackers can far more easily create firmware threats now that can scale to far more devices than ever before.
Conclusions
Whether one plays games or not, the arrival of firmware-based cheats should serve as a canary in the coal mine for security professionals. The impact of firmware threats has been well known for years: massive. But as firmware hacks become both more accessible and scalable, the prevalence of firmware attacks are also on the rise. This translates to real risk for organizations, making it increasingly important that security teams have the tools to find firmware vulnerabilities and threats in order to protect themselves. We are dedicated to that mission both from support for open-source projects like CHIPSEC as well as our work with the Eclypsium platform. If you would like to learn more about firmware security and how to defend your organization, please contact the Eclypsium team at [email protected].
