Perilous Peripherals: What To Do When Your Insecure Device Firmware Deceives You
Nearly every device on the market relies on firmware and many devices include multiple components with their own firmware. Manufacturers and developers have begun to focus on protecting system firmware from potential attackers, but peripheral firmware often receives very little attention. Security researchers at Eclypsium recently uncovered unsigned or unverified firmware in devices by companies such as Lenovo, HP, and Dell and were able to successfully attack a server. Many have been aware for quite some time of the dangers of unsigned firmware, but this recent study emphasizes how frequently manufacturers tend to ignore peripherals.
Katie Teitler, Senior Analyst at TAG Cyber, remarked, “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. This could lead to implanted backdoors, network traffic sniffing, data exfiltration, and more. Unfortunately, though, firmware vulnerabilities can be harder to detect and more difficult to patch.”
Peripheral devices often fail to confirm that firmware has been signed. Attackers could potentially load their own firmware and steal data, distribute ransomware, or otherwise compromise a device. This issue is particularly prevalent on Windows and Linux devices. Apple verifies the signature of all files on a driver, but Windows and Linux devices are less consistent. The researchers even discovered that many firmware updates that had been uploaded to the Linux Vendor Firmware Service are unsigned. This includes firmware for a VLI USB Hub.
Eclypsium researchers found unsigned firmware on several devices
Lenovo ThinkPad X1 Carbon 6th Gen laptop
An HP Spectre x360 Convertible 13 laptop did not fare much better than the Lenovo laptop. The firmware for its HP Wide Vision FHD camera, a USB camera module, was unencrypted and did not check for authenticity. HP recently provided a firmware update that included a firmware update tool with the firmware image. However, the firmware image does not incorporate a cryptographic signature or other forms of verification. The researchers were able to modify the USB descriptors, which provide information about the kind of device that is connected. If the researchers had malicious intentions, they could have easily disabled the device, caused the camera to be identified as a different kind of device, or uploaded malware.
The researchers were also able to tinker with the Killer Wireless-n/a/ac 1535 adapter on a Dell XPS 15 9560 that was running Windows 10. Windows 10 will check to see whether a driver has been signed and will display a certificate icon once the driver has proven to be legitimate. The researchers changed the adapter’s signed firmware image and eliminated the certificate icon. The unsigned driver loaded onto the device and continued to function even though it was no longer verified.
Unsigned firmware can damage an entire network
Unsigned firmware can demonstrably affect individual devices, but it can also damage an entire network. The researchers attacked a network interface card (NIC) Broadcom BCM5719 chipset. A NIC is the hardware component that connects a computer to a network, but it does not mean all network traffic that passes through it is seen by the computer’s operating system. Servers often have a baseboard management controller (BMC) installed alongside the host operating system, such as HP’s iLO and Dell’s iDRAC management solutions.
The BMC enables “out-of-band” management of the server. This allows server administrators to configure and monitor the server remotely. The BMC may have its own dedicated NIC, but in many cases it shares a physical NIC with the host OS. The BMC and host operating system still show as two separate devices on the network, each with its own network address. Traffic passing through a shared NIC is typically segregated so the host operating system cannot see the BMC’s traffic and vice-versa.
In Eclypsium’s demonstration, the researchers were able to infect a host server, then replace the system’s NIC firmware with their own. This modified firmware allowed the researchers to not only inspect the BMC’s traffic from the host operating system, but also modify and redirect it. The researchers could then block or redirect alerts generated by the BMC to evade detection and make outgoing connections to remote servers.
Additionally, server NICs commonly use the PCI bus as expansion cards. This allows attackers to leverage a Direct Memory Access (DMA) attack to read and write system memory directly. This can allow the attackers to bypass the CPU and OS to take control of the server at the kernel level. This ultimately makes detection far more difficult.
The BMC enables “out-of-band” management of the server. This allows server administrators to configure and monitor the server remotely. The BMC may have its own dedicated NIC, but in many cases it shares a physical NIC with the host OS. The BMC and host operating system still show as two separate devices on the network, each with its own network address. Traffic passing through a shared NIC is typically segregated so the host operating system cannot see the BMC’s traffic and vice-versa.
In Eclypsium’s demonstration, the researchers were able to infect a host server, then replace the system’s NIC firmware with their own. This modified firmware allowed the researchers to not only inspect the BMC’s traffic from the host operating system, but also modify and redirect it. The researchers could then block or redirect alerts generated by the BMC to evade detection and make outgoing connections to remote servers.
Additionally, server NICs commonly use the PCI bus as expansion cards. This allows attackers to leverage a Direct Memory Access (DMA) attack to read and write system memory directly. This can allow the attackers to bypass the CPU and OS to take control of the server at the kernel level. This ultimately makes detection far more difficult.
It is not always clear who should assume responsibility
Each manufacturer has responded differently to the news about their insecure peripherals. Lenovo remarked that they did not currently have a way to patch the issue, while HP insisted that they will be adding signed firmware to future cameras. Neither Qualcomm nor Microsoft claimed responsibility for the Killer Wireless-n/a/ac 1535 adapter on the Dell XPS 15 9560. Qualcomm produces the chipset and driver for the adapter, but argued that the software on a CPU should validate firmware. They noted that they do not plan to add signature verification. Microsoft contended that the device vendor is responsible for firmware verification.
These variations in responses illustrate the lack of consistency in manufacturer’s approaches to peripheral firmware. It is not always clear who should assume responsibility, but there should be some form of protocol. The researcher’s attack demonstrates that the threat is both tangible and prevalent.
Eclypsium researchers also presented their findings this past summer on Windows kernel security flaws that affected over 40 drivers from 20 different vendors. The vulnerable drivers gave attackers highly privileged access to OS kernel mode or ring 0 and allowed them to disable hardware and firmware. The affected manufacturers at least appeared more willing in this situation to provide patches. Let’s hope that manufactures will also follow suit with peripheral firmware.
Dell XPS 15 9560
These variations in responses illustrate the lack of consistency in manufacturer’s approaches to peripheral firmware. It is not always clear who should assume responsibility, but there should be some form of protocol. The researcher’s attack demonstrates that the threat is both tangible and prevalent.
Eclypsium researchers also presented their findings this past summer on Windows kernel security flaws that affected over 40 drivers from 20 different vendors. The vulnerable drivers gave attackers highly privileged access to OS kernel mode or ring 0 and allowed them to disable hardware and firmware. The affected manufacturers at least appeared more willing in this situation to provide patches. Let’s hope that manufactures will also follow suit with peripheral firmware.
