A recent firmware snafu discovered in more than 400 computer motherboard models produced by Gigabyte offers some powerful lessons to guardians of software supply chains.
The bit of insecure coding was discovered by researchers at firmware-focused cybersecurity company Eclypsium, which noticed suspicious backdoor-like activity in the wild by systems with the Gigabyte motherboards.
Upon further analysis, the researchers found that the firmware in the motherboards was dropping and executing a Windows-native executable during the system startup process that downloaded and executed additional payloads insecurely. Subsequent analysis showed that this same code was present in hundreds of models of Gigabyte PCs, the researchers added.
They noted that the code was meant to be an innocuous tool to keep the motherboard’s firmware updated, but because it was written insecurely, it created a mechanism that could be hijacked and become a vehicle for planting malicious software on a system.
Since it initially revealed the firmware coding problem, Eclypsium has posted a PowerShell script to GitHub that allows users to identify whether their systems have been impacted by the insecure code.
Here's what your software security team can learn from the Gigabyte firmware incident.
[ Learn about the evolution of app sec in our special report | See ReservingLabs threat researchers' latest reports ]
No care and feeding needed
ReversingLabs Field CISO Matt Rose said the code was an example of software being developed outside of security controls.
"The code creates functionality that the developers put in to make life easier, but it was probably out of the lens of any security audit."
—Matt Rose
Rose said most applications have admin capabilities to get information. "The fact that this was done insecurely makes me think that, because it was firmware and on a motherboard, the normal processes didn't take place."
"They were trying to be nice, no care and feeding required. The firmware on your motherboard will update automatically. That's fine as long it's done securely."
—Matt Rose
Some of the security flaws were elementary, meaning they should have been done securely but were not. "Sometimes they reached out to the internet without using https. It reached out in http to pull something down. If it's in http, then a man-in-the-middle attack is definitely a possibility," Rose said.
Mike Parkin, senior technical engineer at Vulcan Cyber, explained that Gigabyte apparently didn't initially design the firmware update system to properly verify that it was communicating with its servers or to verify the cryptographic signature of the firmware updates. "That presents opportunities for a threat actor to put themselves in a position to substitute their own compromised firmware," Parkin said.
The supply chain security connection
James McQuiggan, a security awareness advocate at KnowBe4, said the insecure code could be a danger to organizations similar to the one posed by the SolarWinds compromise.
"It presents an unknown attack vector to organizations that take the necessary due diligence to protect their infrastructure. Now they unknowingly could have been exposed to cybercriminals attempting to steal information from their networks."
—James McQuiggan
McQuiggan said that firmware attacks can pose a substantial risk to the software supply chain. Depending on the number of organizations it impacts, he continued, it can add thousands of hours of resources to mitigate.
"If cybercriminals can install backdoors or additional malware during the hardware manufacturing process, they can quickly attack any exposed system and compromise that infrastructure with little to no exposure."
—James McQuiggan
Because firmware programs run before the operating system is loaded, they can have a devastating impact on supply chain functions, said Tim Mackey, head of software supply chain risk strategy at Synopsys. "Consider a situation where a malicious piece of firmware is loaded prior to the operating system and that firmware controls the Wi-Fi adapter. That firmware then has access to all the data moving between the computer and the source code repository or even the build system," Mackey said.
"If that malicious firmware is also used on the build system, then the results of the build process couldn’t be trusted, either.”
—Tim Mackey
Parkin said firmware attacks are an area of concern for supply chain security.
"Firmware attacks pose a legitimate risk to the software supply chain, but not in the same sense that a compromised development library does. Where a compromised library gets injected into your development platform, a firmware compromise infects the hardware you're developing on. Both are potentially a bad thing, but in different ways."
—Mike Parkin
Masking insider threats
One good break is that firmware attacks aren't very common, Parkin said.
"They generally take a higher level of skill and sophistication and are effective against a relatively narrow range of targets. That said, when they do happen, they can be difficult to detect and harder to remediate."
—Mike Parkin
McQuiggan said that, while not common, firmware attacks are high-value targets for attackers. "[If] a cybercriminal group does develop an exploit on firmware, it's very coveted, as it provides access to a device at its root," he said.
Dev teams need good security, but it's not that simple
Jeff Williams, CTO and co-founder of Contrast Security, said that insecure coding can raise questions about insider threats. "Almost all security work is focused on inadvertent vulnerabilities created innocently by developers," he said.
"However, imagine you’re a malicious developer that wants to Trojan your company’s software with a backdoor. A smart attacker won’t make an obvious backdoor, they’ll just introduce a common vulnerability that looks accidental. That way they maintain plausible deniability if the backdoor is detected."
—Jeff Williams
Williams said the only way to tell the difference between a vulnerability from a backdoor is to try to discern that developer’s intent, "which is essentially impossible," he said.
"In this case, we may never know.”
—Jeff Williams
