For a determined cyberattacker wanting to compromise a modern Windows, Apple or Linux computer, there is no bigger or better target to aim for than the low-level Unified Extensible Firmware Interface (UEFI) firmware that manages the boot process.
Residing on a special SPI flash chip, reach it and you’ve achieved the precious goal of persistence, the ability to remain on a computer without that being obvious to the victim. Fortunately, since UEFI became a standard feature on PCs a decade ago as a replacement for the old-style basic input/output system (BIOS), known compromises of this layer have been rare… but not that rare.
The first in-the-wild UEFI attack was uncovered by security company ESET in 2018, believed to have been the work of the Sednit APT group, also known as APT28, Strontium and, more famously after the hacking of the Democratic National Convention (DNC) in 2016, Fancy Bear.
Earlier this month, Kaspersky Lab discovered a second UEFI compromise, which is where the story becomes more complex and alarming. Tentatively connected to China or North Korea, this campaign was similar in many respects to that discovered by ESET, combining selective targeting, nation-state espionage, and even employing some identical software components.
Significantly, Kaspersky Lab tied the rootkit used to attack UEFI firmware to a much larger platform, dubbed MosaicRegressor. That’s usually not a good sign because it implies a determined and long-term development effort that works in conjunction with other malware components, likely also to be very hard to detect.
What we have here, then, is two entirely different attack groups which have had the same clever idea in the same time period. These attacks have not only been successful but date back at least one to two years before they were detected. And even these discoveries happened by chance – ESET and Kaspersky noticed them after adding UEFI firmware scanning to their anti-virus products, a feature some rival security products still lack.
Disaster foretold
Ironically, the idea of compromising UEFI firmware can be traced to a legitimate anti-theft remote tracking system that went awry, Absolute Software’s Computrace/LoJack for Laptops. Installed in UEFI, this could survive not only an OS install and hard drive reformat but drive replacement. After years of anxiety about risks of this ‘good rootkit’ approach, in 2014 Kaspersky researchers found serious design weaknesses it suspected could turn it into a security liability.
Content from our partners
Sure enough, the campaign noticed by ESET in 2018 hooked into these weaknesses to overwrite and Trojanise Absolute’s LoJack communication. Criminals also borrowed the same techniques for a UEFI bootkit called VectorEDK, leaked from the Hacking Team threat group in 2015. This source code was the basis of the 2020 attack noticed by Kaspersky.
UEFI Rootkits: who were the targets?
Suspected nation-state campaigns, the 2018 and 2020 attacks were aimed at a small number of government agencies and NGOs in Africa, Asia and Europe. These are not mainstream attacks and are never likely to be. However, when Tech Monitor spoke to the researchers at both companies, they were in no doubt that the same UEFI rootkit method could be used against any high-value target, including organisations involved in critical infrastructure such as energy, transport or health.
How did the compromises happen?
Neither ESET nor Kaspersky is certain. One first possibility is a remote attack although, reassuringly, targeting UEFI SPI chips is technically challenging. Attackers would need to understand the specific firmware used by each target machine and these turn out to be very diverse.
“UEFI suggests all kinds of security mechanisms such as checking the authenticity of firmware updates. Another is enabling write protection. It’s up to the specific vendor to enforce them or not,” said Kaspersky Lab’s senior security researcher, Mark Lechtik. Incredibly, this doesn’t always happen. “Sometimes the mechanisms are absent or not properly implemented,” he added.
Alternatively, Lechtik speculates the attacks involved physical access to the target machines or the deployment of an infected USB drive containing a flash overwriting utility.
Defending against UEFI attacks
The discovery of a second campaign happening up to three years in the past confirms that UEFI attacks are viable and should be taken seriously by organisations in some sectors. So how should CTOs react?
Assessing the vulnerability of UEFI security on a population of machines is one approach, but this leads to a maze of possible firmware versions, each different from the other. Another method is to inspect UEFI firmware using an endpoint security product, assuming such a capability is offered. Lechtik’s recommendation is to adopt an active approach, regularly updating UEFI using an authenticated mechanism from the company that created the firmware rather than a third party.
Depending on the UEFI rootkit design, other defences are possible for high-value machines. “In the case of MosaicRegressor, a simple mitigation would be to have applied full disk encryption. If that had been installed, the rootkit would not have been able to access the filesystem,” says Lechtik. Defending against physical attacks could be achieved by password protect the UEFI on every boot.
When we spoke to ESET’s Jean-Ian Boutin, who researched the 2018 UEFI campaign, he argued that we should question the assumption that a modifiable software layer such as UEFI was ever trustworthy.
“All of this could have been prevented if the root of trust was the hardware itself.” He suggests technologies such as Intel Boot Guard as a better defence. “If you have the root of trust in the hardware then even if you rewrite the flash the computer won’t boot.”
This makes it harder to modify firmware but also to overwrite it with a rootkit. Although not a magic shield – Boot Guard itself might have weaknesses – this type of security tips the balance back in favour of the defender. Boot Guard is also only available on machines made after 2013 so older equipment and operating systems would not be able to use it.
Boutin does not expect UEFI attacks to become common in the coming years but to crop up now and again. It’s also possible they are more common than anyone realises but simply aren’t being detected because nobody’s looking. Concludes Boutin: “Some organisations should have this in their threat model. It is hard to detect, hard to remove. Preventive measures are a very good idea.”
