In the wake of the revelation that Conti has been actively targeting firmware vulnerabilities, this past week has seen a flurry of announcements related to firmware attacks and firmware threat detection – but why has it taken so long for firmware to get onto organisations’ security radar?
Last week Eclypsium published a detailed analysis of Russian ransomware group Conti’s approach to targeting vulnerabilities in Intel’s Management Engine (ME), the microcontroller embedded in many modern Intel chipsets. When provisioned, the ME acts as a master controller for the system, with access to system memory, the screen, keyboard, and network.
That same day firmware security start-up Binarly announced a new firmware threat detection platform – and days later, Microsoft published a blog on its Firmware Attack Surface Reduction approach. Yesterday, UL also launched its new SafeCyber platform, focused on preventing supply chain attacks, including firmware attacks.
While there might have been some incentive for these vendors to move up their firmware security-related announcements following the revelations about Conti’s firmware attacks, it is clear that firmware security is now something to be taken seriously. But despite long-standing vulnerabilities in firmware – the EFF raised concerns about Intel’s Management Engine in 2017 – firmware attacks have not been widespread enough to worry about until recently.
“Over the past two years, firmware threats have gone from being the secret weapons of nation-state threat actors to everyday, commoditized threats used in some of the most widespread malware, ransomware, and attack campaigns in the world,” said a January blog post from Eclypsium, a firm focused on securing firmware and hardware.
See also: Unique new UEFI firmware attack dubbed “MoonBounce” raises questions
When asked what has changed in the past couple of years, John Loucaides, SVP for strategy at Eclypsium, told The Stack this pivot has in part been down to necessity.
“Organisations have gotten used to the idea that they should harden their software, their operating system, their network, and they do this – and that means that there is something else to evade. And so you have to do something that isn't the first thing you thought of 20 years ago.”
Joe FitzPatrick of Securing Hardware, a security researcher also focused on firmware and hardware attacks, agreed: “There was no need to attack the firmware, because the software was vulnerable enough. Only now that we have robust OSs with encrypted storage, signed kernels and drivers, and sandboxing everywhere does any attacker even need to consider firmware.”
He also said firmware attacks have been helped by the homogenisation of firmware: “It used to be that every version of every motherboard had a different bios written for it, and there were dozens of bios vendors. Now, everything is UEFI, and huge portions of the UEFI firmware on systems is identical across products, often with shared portions across different vendors as well.
“We have firmware being developed with modern tools – and we have tools to analyse and modify firmwares much more easily,” he told The Stack by email.
According to Loucaides, while firmware attacks might not be the most obvious starting point for threat actors, “the learning curve isn't as steep as people think.”
“Firmware is that part of the system that normally would be invisible, but it's intended to just work, and the manufacturer has placed it there with the understanding that you, the end user, don't have to mess with it,” he said.
“But that premise is why we get these problems. So you get a thing that was designed to be invisible, that's designed to be forgotten. And that thing is just software, and so it has all the problems that regular software always has. And because it's designed to be forgotten, we don't manage it like we do other software. That makes it a latent area of vulnerability.”
Follow The Stack on LinkedIn
And while Eclypsium has described adding firmware security to an organisation’s incident response process as “easy”, actually mitigating vulnerabilities is harder.
“It's ‘easy’ in that the solutions exist – we know how to boot securely, we know how to check signatures, we know how to do all the pieces in software and in firmware – the hard part is actually implementing them,” said FitzPatrick.
“There are still lots of cases where firmware is developed, tested, and put into production with development environments that look like they're from the 90s. On top of that, a failed firmware update can render a system useless.”
From Eclypsium, Binarly and other vendors, there are now tools which aim to make detecting and patching vulnerable firmware easier – and vendors such as Microsoft are also paying more attention to firmware attacks. But how are chipset manufacturers such as Intel responding?
“Intel and others have already been working on this for decades, but because of the number of moving parts, progress takes time – you need to architect a feature, implement it, test it, ship it on a product, and then software has to come in and actually use the feature. This is one reason why vertical products like phones and game platforms get these features first - and then those features trickle down into the rest of the industry,” FitzPatrick told The Stack.
Loucaides also believes Intel and others are taking the firmware security threat seriously, but thinks there are “institutional and market pressures” which limit their options to respond.
“Users really do want devices to ‘just work’. Market differentiation really does drive increased features and attack surface. Standardisation helps the attackers in addition to the defenders,” he said.
“Instead, the solution to firmware security is not going to come solely from the sources of the firmware. The solution needs to come from transparency and visibility, where end users can compare the level of visibility they get on devices and independently verify vulnerability and integrity just like we're doing with other software. This needs to happen throughout the lifecycle of devices, including supply chain, operations, and incident response.”
Loucaides references the efforts around a “software bill of materials” initiative which aims to reduce supply chain attacks – and suggests this should be extended to include a “firmware bill of materials” (FBOM) to improve firmware security.
“In addition to having a memorable name, the FBOM is important way to increase visibility on the parts of software that would otherwise be forgotten.”
