Gigabyte Motherboards Came With Sloppy Backdoor Users Had No Idea About
from the trust-no-one dept
It’s always interesting to me to watch and see what gets attention in the security and privacy space. For example, everybody spent the last two years suffering absolute embolisms at the idea that TikTok was a threat to privacy, but nobody much seems to care that an absolute ocean of “smart devices,” from your router to your television, routinely come with paper-mache-grade security.
Hardware you expect to be secure (like door locks advertised as a security upgrade) routinely… aren’t. That frequently applies to core technologies you don’t spend a whole lot of time thinking about, from routers to PC components.
Last week, cybersecurity company Eclypsium issued a report that they’d discovered a hidden backdoor in the firmware of motherboards sold by the Taiwanese manufacturer Gigabyte. Code within the firmware activates each time a PC using these motherboards restarts. It’s supposed to help update the motherboard’s firmware, but it was implemented… poorly:
The firmware does not implement any cryptographic digital signature verification or any other validation over the executables. The dropped executable and the normally-downloaded Gigabyte tools do have a Gigabyte cryptographic signature that satisfies the code signing requirements of Microsoft Windows, but this does little to offset malicious use, especially if exploited using Living-off-the-Land techniques (like in the recent alert regarding Volt Typhoon attackers). As a result, any threat actor can use this to persistently infect vulnerable systems either via MITM or compromised infrastructure.
Whoops! The flawed implementation, as they note, doesn’t adequately inform the end user, and could then be exploited by bad actors, undermining the trust PC owners have that their core devices are inherently secure. Their blog post lists 271 models of Gigabyte motherboards are impacted by this flaw. The company isn’t responding to requests for comment.
Despite the widespread potential impact of the problem, I’m going to assume I won’t see any Senators showing up on cable news freaking out about the issue.
Filed Under: backdoors, gigabyte, hardware, motherboard, pc components, privacy, security
Companies: gigabyte
Comments on “Gigabyte Motherboards Came With Sloppy Backdoor Users Had No Idea About”
This is firmware we’re talking about. The ability to detect malware in it is exceptionally limited.
And how about this scenario: if the malware installs an update that implements the missing crypto digital signature checking, then congratulations! you’re locked out unless you’re willing (and able) to reflash your bios not just manually, but with external means. You know, unseating the chips, hotwiring them, etc…
Re:
I just posted another comment before seeing yours. This is Windows malware embedded in the firmware, not anything being run in or by the firmware. The idea of “Hardware you expect to be secure… routinely… aren’t” [sic] doesn’t really apply.
It is, in fact, trivial to detect. Just look for a WPBT entry in your system’s ACPI tables. On Linux, for example:
sudo acpidump | grep ‘^WPBT’
I see a result on my ASUS motherboard, and a web search shows 5-year-old reports of ASUS using it. People who intend to use Windows, or research its security, should probably be auditing these embedded programs (and drivers, many of which are written just well enough so Microsoft won’t reject them entirely). It’s a normal Windows binary, and the usual reverse-engineering tools should work. Alternately, patch Windows to ignore WPBT, or patch your firmware to remove it.
Re:
I’m not quite sure what you’re getting at here. Being a normal Windows program, the affected software has no more access to reflash the firmware than any other program. Downloading and installing other arbitrary Windows programs without verification is still a pretty big deal; but while they could write firmware updates to disk, the firmware would presumably only run those (on the next reboot) after checking the signature.
By the way, many good motherboards now have a chip that can update firmware from a USB stick, without using the CPU or RAM (which don’t even need to be installed—helpful if the board needs a firmware update to support them).
Re: Re:
“By the way, many good motherboards now have a chip that can update firmware from a USB stick”
I haven’t looked in a while but there used to be boards with pri/sec firmware circuitry which allowed fallback to prior version when necessary.
Re: Re: Re:
That’s sometimes called “dual BIOS”. Gigabyte’s used it, but I think they’ve stopped. It’s not clear whether it’s a good defense against malware, or whether malware could flash the secondary BIOS at the same time as the first. (Even in boards that have CPU-free flashing, if implemented poorly, the firmware of the microcontroller in charge of this could be replaced by malware. I’m not aware of any relevant security research.)
That’s half the problem. But if you read closer, the firmware is taking advantage of the same Windows backdoor used by anti-theft malware. That is: firmware can embed arbitrary Windows programs, and Windows will automatically run them without notification or any possibility of opting out. The idea is that if someone steals your laptop and installs a “clean” copy of Windows, they’ll run this unwanted software and get caught. Of course, worse malware has also used it.
I recall some weak outrage the last time this became known, but, ultimately, nothing came of it. I’m sure Microsoft has quantified the outrage and determined that few people will actually stop using their software. Therefore, there’s no reason to change anything, and the feature remains.
I don’t count this as a true “firmware backdoor”; just bundled crapware which, if installed via one backdoor (that doesn’t exist on any non-Windows operating system), provides another backdoor. That users didn’t know simply means they weren’t looking, because this isn’t steathly at all: anyone who dumps the ACPI tables should be able to see what it’s asking Windows to run. It’s not quite as scary as a backdoor using, for example, the Intel Management Engine and its own network stack.
Nothing worse than a sloppy backdoor.
Re:
N sloppy back doors
Re:
sloppy backdoor seconds.
I’ve never understood why technology companies are allowed to put out flawed software and hardware with little to no repercussions. If any other company put out a product with so many flaws and problems they would be sued out of existence.
Re:
“If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization.”
Re: Re:
Structural analysis is a simple problem compared to software validation. That does not stop building failing under snow loads, or resonance destroying the occasional bridge….
Re: Re: Re:
When it happens, we have an inquest. Maybe an engineer loses their license, maybe their firm goes under, and we’ll teach people about the failure in engineering school in the hopes that it’ll never happen again. Whereas when someone fucks up software, we just shrug and the person and company go on as if nothing happened. The same damn thing happens over and over. “Downloaded data without proper signature verification”, “wrote past the end of a buffer”, etc.
To your point about simplicity, at least part of the problem is that people are much more willing to accept complex software. If an engineer says “a moderate wind could destroy the proposed bridge”, it’s not gonna be built without fixes; if a programmer says “a man-in-the-middle could destroy our security”, well, we’ll put that on the list of things to fix in a future version—just get something built for now. The companies know they’re unlikely to lose business or suffer legal consequences, so why should they even care about negligence?
Re: Re: Re:2
Parts of California had roof/building collapses of building built to code, due an extreme wet Snow event that dropped a record breaking amount of snow. The only question that needs answering is what should the snow load be changed to in the building codes, noting that the change will make new buildings more expensive.
Re: Re: Re:3
If we could build software “to code”—that is, free of the classes of problems that have caused high-profile failures and are likely to reoccur—that would be a good start.
Re: Re: Re:4
verification of software is a large on-going development process. There is not general solution.
There are tools to make it easier to find some classes of flaws in some circumstances. However generally speaking writing any real-world program is complex enough that it will always have undiscovered bugs.
Re: Re: Re:5
Verifying that your software checks the signature of any data it downloads, before using it, isn’t much more difficult than verifying an electrician used the proper machine screws instead of sheet metal screws for bonding.
Formal proofs of correctness would be excellent, but right now, we don’t even seem to have reached the level of “a second competent person took a quick look at this”.
Re: Re: Re:6
That would be true if it was one of half a dozen things to consider, but less so when it it is one of a dozen things to consider when writing a piece of code, especially when, as this code likely is, there are memory constraints limiting code size.
NASA lost a mars probe due to trivial to spot issue, mixing metric and imperial units, its just that nobody though to check or specify which units to use, NASA assumed metric, their contractor assumed Imperial. And that in a coding environment when, all human input checking specifications and implementation considered, their speed of coding is better measured in man days per line of code than lines of code per man day.
Re: Re: Re:
“or resonance destroying the occasional bridge….”
I saw that film in school, Tacoma Narrows suspension bridge in high wind self destructing, was eye opening and was a few years ago.
In the recent past, several bridges have fallen due to a lack of maintenance, the twin cities one was blamed upon pigeon poop. Many bridges are on a list identifying the need for immediate attention.
That bridge in India has fallen twice in a few years, seems they can not get it right on a limited budget.
I’m no expert – but surely an attacker would need either direct-physical-access to the pc or to convince a user to flash their bios from an untrusted source? This isn’t as susceptible as the IIS vuln that code-red exploited remotely a few years back (also using LOTL techniques)