Researchers at firmware security company Eclypsium on Tuesday released new research that identifies and confirms unsigned firmware in WiFi adapters, USB hubs, trackpads and cameras used in Windows and Linux computer and server products from Lenovo, Dell, HP and other major manufacturers.
Eclypsium also demonstrated a successful attack on a server via a network interface card with unsigned firmware used by each of the big three server manufacturers.
The demonstration shows the exposed attack vector once firmware on any of these components is infected using the issues the report describes. The malware stays undetected by any software security controls.
Unsigned firmware provides multiple pathways for malicious actors to compromise laptops and servers. That leaves millions of Windows and Linux systems at risk of firmware attacks that can exfiltrate data, disrupt operations and deliver ransomware, warned Eclypsium.
Unsigned firmware in peripheral devices remains a highly overlooked aspect of cybersecurity. Depending on the capabilities of the component, unsigned firmware can lead to the loss of data, integrity and privacy. It also can allow attackers to gain privileges and hide from traditional security controls, notes the report, titled “Perilous Peripherals: the Hidden Dangers Inside Windows & Linux Computers.”
Software and network vulnerabilities are often the more obvious focus of organizations’ security priorities, but firmware vulnerabilities could give adversaries full control over the compromised device, according to Katie Teitler, senior analyst at TAG Cyber.
“This could lead to implanted back doors, network traffic sniffing, data exfiltration, and more,” she told LinuxInsider.
Reporting factors
The “Perilous Peripherals” report is based on original research conducted by members of Eclypsium’s research team. They include principal researchers Rick Altherr, Mickey Shkatov, Jesse Michael and CTO Alex Bazhaniuk.
Work on this research began more than18 months ago and was completed this February. The study was self-funded by the company, according to Jesse Michael, the report’s principal researcher.
“It is safe to assume that tens of millions — if not hundreds of millions — of systems have these specific unsigned firmware components,” Michael told LinuxInsider.
For example, annual server shipments are around 12 million, and annual laptop shipments number approximately 200 million units. While the specific vulnerabilities identified in this report affect only a portion of all shipped systems, unsigned firmware components are prevalent within the industry, he explained.
“We have yet to find a system that does not include such components,” Michael said.
Problematic Roots
The problem surrounding unsigned firmware surfaced five years ago. Security researchers found the Equation Group’s HDD implants lurking in the wild. That was a wake-up call introducing the computer industry to the power of firmware hacking and the underlying dangers posed by unsigned firmware in peripheral devices, according to Eclypsium’s report.
There have been pockets of progress in dealing with the problem in recent years. However, much of the industry continues to turn a blind eye to the risks of unsigned firmware, Elypsium’s research indicates.
In carrying out four separate research projects, Elypsium’s team found unsigned firmware in WiFi adapters, USB hubs, trackpads and cameras in a variety of enterprise devices. These issues can be devastating to the security and operation of the devices.
“More often than not, [they] are very difficult to fix. Disruption to components such as network cards, drives and other peripherals can completely disable the device or provide attackers with ways to steal data, deliver ransomware and hide from security,” the report states.
These weaknesses are widespread across components in laptops and servers, the new Eclypsium research shows. They offer multiple pathways for malicious attacks.
See Eclypsium’s “Know Your Own Device” resource for an overview of some of the most common firmware-enabled components within devices today.
Slow Response, Few Solutions
Despite previous in-the-wild attacks, peripheral manufacturers have been slow to adopt the practice of signing firmware. When it comes to security, most of the attention goes to the most visible components of a system, such as the operating system and the applications.
In response to the growing number of threats, many organizations have begun to add firmware to their vulnerability management and threat prevention models. However, these efforts are limited to the system firmware — the UEFI or BIOS resident on the main board of a device, explained Michael.
The lurking danger is underscored because virtually every component within a device has its own firmware and its own potential for risk, he said. That includes network adapters, graphics cards, USB devices, cameras, touchpads and trackpads, and more.
“Unfortunately, this issue will be around for quite a while, and we’ll most likely see improvements in next-gen products. But this will not happen all at once. As an industry, we need to pay more attention to hardware and firmware security,” suggested Michael.
Some OEMs, such as HP and Lenovo, have been quick to acknowledge the problem and begin working on solutions with their device/component manufacturers. Signed firmware protections typically require changes within the hardware as well as the firmware. To do that, they must be introduced in a future device revision or model, he added.
Why the Risk
These internal components in peripheral devices are governed by firmware. The firmware may be burned into the integrated circuit of the device itself. Or the component may have its own flash memory where firmware is stored.
In other cases firmware may be provided dynamically by the operating system at boot time. However the firmware is stored, it can act like a miniature computer that governs the low-level behavior of that particular component. This code often is very susceptible to attack, residing in everything from laptops to servers to network devices, according to the report.
Protecting users from the dangers of unsigned firmware requires work by vendors throughout the industry. The original equipment manufacturers (OEMs) and original design manufacturers (ODMs) need to work together to fix these issues.
“By including these types of issues in their risk assessments, organizations can make informed decisions on which peripherals and products are secure and which are not,” said Michael.
Daunting Struggle Ahead
Mitigating the problems unsigned firmware causes over such an extended period of widespread use means a speedy solution is unlikely to come soon — but it is essential to make progress toward that end.
“Unfortunately, though, firmware vulnerabilities can be harder to detect and more difficult to patch,” TAG Cyber’s Teitler said. “Best practice is to deploy automated scanning for vulnerabilities and misconfigurations at the component level and continuously monitor for new issues or exploits.”
The problem is that peripheral devices often lack the same security best practices that we take for granted in operating systems and in other more visible components, like the UEFI or BIOS, noted Michael. Specifically, many peripheral devices do not verify that firmware is signed properly with a high-quality public/private key before running the code.
This means that these components have no way to validate that the firmware loaded by the device is authentic and should be trusted. An attacker simply could insert a malicious or vulnerable firmware image, which the component would trust blindly and run, he cautioned.
No Clear Path Forward
These components are inside laptops and servers, but it is often up to the individual device/component manufacturers to introduce mitigations.
Most organizations do not have the mature processes needed to handle security flaws at this level or assign Common Vulnerabilities and Exposures (CVE) reports, according to Yuriy Buygin, CEO of Eclypsium.
Often, aging hardware becomes a bigger part of the problem. Technical methods to provide robust fixes for fielded products are unavailable because of an old hardware design, he said.
“So we will see these issues for years to come, and the only way to improve this is to keep finding vulnerabilities, alerting the public, and helping device vendors to establish better firmware security,” Buygin told LinuxInsider.
Attack Vectors
Eclypsium researchers demonstrated how unsigned firmware can be abused as part of a real-world attack.
The company’s report details how an attacker who gains control over a peripheral component can use the component’s functionality for malicious purposes. The attacker potentially can gain new privileges and even get control over the entire system.
The demonstration shows Eclypsium researchers attacking unsigned firmware in a network interface card (NIC) chipset. A malicious attack on the card can have a profound impact on the server.
That, in turn, compromises the operating system remotely. It provides the attacker with a remote backdoor for snooping and exfiltrating raw network traffic while bypassing operating system firewalls to extract data or deliver ransomware.
Such an attack could disconnect a server from a network upon a signal, the report warns. That can result in disrupting connectivity for an entire data center.
Loading ...
This is the biggest bit of garbage I have ever read because they totally don’t understand the problem space.
The problem is not unsigned firmware. Its non-verified firmware.
Yes signing firmware can be a method to assist in verification.
https://www.darkreading.com/vulnerabilities—threats/how-the-major-intel-me-firmware-flaw-lets-attackers-get-god-mode-on-a-machine/d/d-id/1330565
We have to remember threats like above turn up yes this is signed firmware and systems still get exploited. So if all hardware mandated signed firmware nothings says that attack will not use old flawed version of firmware that was signed.
Really have another side to this problem.
In their attack example they are using a open source implemented version of the firmware that would not exist if the device required signed. This is a security upside to this as well not covered. The security upside is if there is a fault in that firmware that a third party can make a new version with the fix. Yes this is doubled sided without a verification system third party could make a hostile version as well. Signed firmware by a vendor that is not more with know security faults is also a hostile firmware.
Signed firmware is a doubled sided problem.
Now what would I class as correct fix to this long term.
Its not signing firmware. Because the ability to repair firmware is important.
1) We need standard for how to extract firmware from devices. Part of that standard is that the code to extract the firmware is rom code. The extract firmware to be checksumed and compared against list of known good. This counters old signed firmwares and the unsigned firmware problem to extend.
2)We need a standard to be able lock firmware. As in you send X command to device after it receives that command it will no longer allow firmware to be changed unless the system is fully powered down.
Please look at there example again. Lets forgot for one min that what they did was unsigned. Lets pretend it was signed.
BMC(Baseboard Management Controller) is for some reason expecting a particular version of network card firmware. Its signed and the OS now uploads incompatible with BMC version.
Lets say my point 2 was implemented when the system powers on the BMC puts the firmware into the network card and locks it. Yes 2 could have a string value so the party locking it can leave a name of who did it. Of course the operating system will need the point 1 for it drivers to find out what firmware it is in fact dealing with.
Now really think how often to you update firmware. If when you system booted some chip like the BMC set all the firmware would you notice.
Having my feature 2 would allow implementing signed firmware on hardware that does not have any signed firmware processing. Why the controller that send the signed firmware to the hardware without any signed firmware check checks the firmware and locks the device that receives it.
Other thing to consider is Dell, HP…. the OEM and ODMs basically could require own custom version of firmware for some reason. Do we really want every chip in our computer wasting silicon space for signature processing of firmware with fuse-able links burn out making those parts unique. Or would we be better off with the ability for one master chip to validate firmware then send to the controllers as lock them from being altered after that point.
Really its not cost sane to-do signed firmware on every controller. Now all controllers having a lock from firmware change and ability to extract firmware that is cost sane and can block all the attacks people point to lets sign the firmware for.
Signed firmware only part of the solution. Problem is signed is only validating where it come from not that is the right version for everything else in the system. My idea first item that need a particular version of firmware locks the door on everyone less.
Controller taking unsigned firmware end user could allow when attempting to develop a fixed firmware against some particular issue so the right to repair. Signed firmware processed inside the controller as the solution is anti the right to pay a third party to fix a security fault in firmware.
The problem space is complex not helped by people thinking signed firmware is a magical bullet that fix everything when it not.
Please edit the comment above for typos and omissions. The last few paragraphs are confusing and the topic critical.
To me its not really confusing but at the end due to growing length I did attempt to cut it down.
Reading over there is a clear omission that most people would not know.
"Really its not cost sane to-do signed firmware on every controller."
This paragraph. Exactly what about the controllers make cost insane.
Large number of controllers core instruction set is still based about the 8051 8 bit instruction set with extended parts to the instruction set to process that. You could argue that this is old. Even if we move to a modern risc-v the controller version can be RV32I with no extensions. So a risc-v with only maths there is add and subtraction
The simple reality in controller silicon the ability to process x502 certificate or equal to check that firmware is signed by the correct party in time effective way does not exist in the controller silicon in lot of cases. Adding this ability you are talking about increasing size of controller a lot and giving those who compromise that controller more cpu it work with as well.
Now it still a silicon cost to add to the MMU or equal of the controller the means to have a flag set that locks the memory where the firmware is stored read only to the controllers CPU. Think about this no point checking if the firmware was signed if it sitting in read/write memory. So this is a cost that has to be paid but its the bare min cost.
Same with the storing the in rom section of cpu the code to dump the firmware back to host when requested. Doing both means to lock memory that the firmware is stored in and return contents of firmware to host is a lot smaller in silicon than implementing everything you need to process signing in the controller.
"Controller taking unsigned firmware end user could allow when attempting to develop a fixed firmware against some particular issue so the right to repair."
The controller having the ability to take unsigned firmware does not mean in general operation end user will be able to use unsigned firmware. That the core concept to what I have written.
Individual controllers being able to take unsigned firmware is not the threat. The ability to modify the firmware at any time is the threat in fact. Think about this a controller that takes unsigned firmware but you can lock it as long as the firmware is locked from change of firmware before attacker can change it the attacker can do nothing with the fact it unsigned firmware. Remember it does not make any sense to waste time sending to a controller that cannot process signature the signature that you are just going to lock. I AM not saying not to send checksum.
Something with signed firmware arguement as well is how with signed firmware are you going to handle a key compromised problem. Lets say you have put your x502 certificate or equal into your controller that you have spent the extra silicon to process this. Now you need to somehow get revoked to a controller of course if you have used fuse-able links to write it into the controller the controller is now scrap and most likely made the board on it security scrap.
More you look at it signing firmware is not the solution at the individual controller level.
This is most likely the confusing part as well.
The concept that controllers that will accept unsigned firmware does not mean the firmware is not signed and enforced.
Concept of validating controller is not being suggested in this write up saying unsigned firmware is putting Linux and Windows at rish. Validating controller could be like the BMC or the main CPU these items have more processing power. What a validating controller needs is the means to send to the controllers under it the firmware that are validated and lock against change except in cases attacker will not be able to perform. Simplest form of this is firmware can only be changed with device is power cycled with power cycling triggering the system that will relock it. Attacker does not have a open window.
Validating controller can be a bigger bit of silicon with more processing. Remember this is a pay once item compared to pay for every single controller. Validating controller could have the means to reach out to internet and check for revoked 502x certificates and be storing checksums of acceptable firmware on particular devices. Remember acceptable firmware checksums allow locking to particular version. Also this is 1 device in system to update if signature/checksum method is found to have a exploitable flaw.
Remember validating controller could kick in when you plug in a USB device or any other device before the OS in the machine is informed that the device is even present yet.
https://hackaday.com/2013/12/29/hacking-sd-card-flash-memory-controllers/
One of our biggest problem is also not that is unsigned. Lot of these controllers are using the failed concept of security by obscurity. This is done like in the SD standards here that we will give a stack of commands to manufacture to do what they like instead of defining command to read firmware, write firmware and lock firmware.
Here is a good question why can your general SD card reader pass though write firmware commands? Normal usage you don’t need to change the firmware on a SD card so a general SD reader should not need this feature. Next question how do you work out that the SD card you put in is hostile or not the instructions to read what firmware is in it is not standard. Signed firmware does not equal not hostile firmware.
When you start thinking carefully you will notice that most of the x86 PC device firmware is basically writable 24/7 that is not a feature we in fact need this feature gives attackers too large of window to cause trouble. Also we lack standard ways to validate what firmware is in fact being used need to detect old/out of date/flawed in usage as we as modified.
The problem space is not simple. Signed firmware is a tool that can help with the problem if it used correctly to validate supply chain. Having every controller in the system validate signed firmware is not the way forwards because a signed firmware does not mean it the correct and current version. You have to look a xbox hacking on this one where people to play not approved games are using Microsoft signed code just old version with known flaws.
Validation of what firmware you are using is more important than any of them being signed. Validation that you are using the most current with the min flaws can be done by simply checking the firmwares against a checksum list attacker cannot mess with.
Signing firmware does not equal a full blown Validation system. Validation system can using signing as extra feature to check supply line but it does not require signing of firmware to be solid wall attacker cannot get past.
See why I give thumbs down. Signing is only icing on the cake of security. Proper validation of what being used is the cake. The cake is just fine with a defined shape without the icing but the icing is undefined shape. This is true for the signing icing and validation cake. The undefined shape of signing is what allowed attackers to use old versions of signed firmware.
Of course someone will say lets just make signed firmware that you cannot use old versions then you end up with users screwed over because new version of firmware has security fault and user cannot switch back to old version.
Firmware signing no matter how you look at it cannot ever fix the attacker problem completely and when it get close it starts harming the owner of the hardware.
Validation systems with lock firmware provided by controllers can 100 percent block the attacker without physical access exploiting included hardware in a device/computer without firmware signing as long as the firmware has no other flaws.
Yes validation systems can be design that the owner of a bit of hardware can physically access the hardware and disable them if there is some valid reason to-do so like repair/diagnostics.
Security is a very simple to get tunnel visioned and start going after so called silver bullets. Problem is as soon as you do that you are hurting self.
Validation is not without is flaws when it comes to functional security but for this problem space its the core question. Does the chosen method make sure you are using the Valid and Correct Firmware? Signed firmware fails to answer that question so is not complete solution instead is only a part that can help correct solution. Correct solution is a validation system that may or may not depend on signed firmware.
Remember signed does not equal valid. This is where lets sign the firmware falls in heap. Basics people faking checks and using valid signatures before computers really showed the fault of signed firmware as well. We have not learnt from history and we are lining up to repeat it.
Something critical here. Some of the hardware that is in usage using unsigned firmware has to be power cycled to change firmware by PCIe/USB… These bits of hardware already have the lock.
You could modify the PCI-e controller/usb controller that when powering up or power cycling a bit of hardware up that it validates the firmware attacker would not be able to exploit these devices even that they accept unsigned firmware. Yes this could well and truly frustrate an attacker they changed the firmware only to have the validation system on power cycle switch it back and log a issue.
Issue for the validation system is the standards of PCIe, USB… don’t include standard systems to write and read firmware. Yes the security by obscurity thing.
Thanks for the clarification. Very much appreciated.