Millions of Gigabyte motherboards appear to be backdoored

Millions of Gigabyte motherboards inside servers and desktops shipped globally may be backdoored. Several hundred different product models from the Taiwanese multinational have been identified dropping an executable Windows binary that is embedded inside of its UEFI firmware. This launches during system startup, before downloading and executing additional payloads insecurely from the internet – a major risk for users that exposes them to easy man-in-the-middle attacks from any adversary.

The potential Gigabyte backdoor appears to be “implementing intentional functionality and would require a firmware update to completely remove it from affected systems” say security researchers at firmware and software supply chain security specialist Eclypsium, who spotted the troubling Gigabyte firmware behaviour via heuristic detections that they regularly run on the firmware of over 20 original equipment manufacturers (OEMs).

The backdoor alert comes after the Gigabyte Server Manager was caught this year allowing a remote attacker using an XSS attack to gain full root/SYSTEM permissions and after it suffered back-to-back ransomware attacks in 2021 that resulted in significant leaks of confidential data. Four Gigabyte vulnerabilities allocated CVEs in 2018 were not accompanied by a security advisory from the company until May 2020 meanwhile. Those bugs (exploited in the wild) were because Gigabyte drivers grant user-mode apps read/write access to memory. (Read a tragi-comic disclosure timeline here to get a sense of how well Gigabyte handled disclosure.)

A Gigabyte backdoor? Or just really bad QA?

Eclypsium VP John Loucaides told The Stack: “This is about as bad as you imagine. If you look at all of the implants that have been in BIOS ever discovered, the set of things that they do is very, very similar to what we saw here, so it was something that worried us substantially…”

The Gigabyte firmware behaviour "uses the same techniques as other OEM backdoor-like features like Computrace backdoor (a.k.a. LoJack DoubleAgent) abused by threat actors and even firmware implants such as Sednit LoJax, MosaicRegressor, Vector-EDK", Eclypsium said in a blog.

That level of concern saw Eclypsium bring its disclosure forward faster than an industry standard 90-day timeframe after reaching Gigabyte.

The company responded to Eclypsium inside of a week and appears to have taken action on its side, but those affected – a figure given that Gigabyte shipped approximately 1,000 motherboards per hour in 2022, is likely to be in the millions – will need to take their own mitigatory action.

(The Taiwanese multinational did not respond to a request for comment from The Stack made two days before we published. As a result it was not immediately clear if a firmware update could be applied to all affected products. Eclypsium's recommended mitigations are listed at bottom.)

OK, so what's happening exactly?

Gigabyte backdoor: Stage 1

The issue starts with a Windows Native Binary executable* embedded inside of UEFI firmware binary in a UEFI firmware volume with the following GUID: AEB1671D-019C-4B3B-BA-00-35-A2-E6-28-04-36.

*8ccbee6f7858ac6b92ce23594c9e2563ebcef59414b5ac13ebebde0c715971b2.bin

This Windows executable is embedded into UEFI firmware and written to disk by firmware as part of the system boot process. During the Driver Execution Environment (DXE) phase of the UEFI firmware boot process, the “WpbtDxe.efi” firmware module uses the above GUID to load  an embedded Windows executable file into memory and installs it into a WPBT ACPI table which will later be loaded and executed by the Windows Session Manager Subsystem (smss.exe) upon Windows startup.

See also: Unique new UEFI firmware attack dubbed "MoonBounce" raises questions

This “WpbtDxe.efi” module checks if the "APP Center Download & Install" feature has been enabled in the BIOS/UEFI Setup before installing the executable into the WPBT ACPI table, which then uses the Windows Native API to write the contents of an embedded executable to the file system at  %SystemRoot%\system32\GigabyteUpdateService.exe

Gigabyte backdoor: Stage 2

The dropped Windows executable is a .NET application that downloads and runs executable payloads from one of the following locations, depending on how it’s been configured (note that the top is http).

• http://mb.download.gigabyte.com/FileList/Swhttp/LiveUpdate4
• https://mb.download.gigabyte.com/FileList/Swhttp/LiveUpdate4
• https://software-nas/Swhttp/LiveUpdate4

As Eclypsium notes: “Plain HTTP should never be used for updating privileged code as it is easily compromised via Machine-in-the-middle (MITM) attacks. However, we noticed that even when using the HTTPS-enabled options, the remote server certificate validation is not implemented correctly. Therefore, MITM is possible in that case also... any threat actor can use this to persistently infect vulnerable systems either via MITM or...compromised router, compromised device on the same network segment, DNS poisoning, or other network manipulation."

(This said, Gigabyte does have documentation on its website for this feature. It is conceivable that the behaviour is legitimate; i.e. it drops the executable Windows binary to help it pull updates in future and someone forgot to secure how then does that latter step. Hanlon's Razor may apply.)

Asked by The Stack if the security issue was conceivably the result of a severe developer error that went unseen by Gigabyte, Loucaides – previously a technical team lead for the US federal government and then on the product security incident response team at Intel – said: “I know exactly how I would do this intentionally and it would look exactly like this.

"It’s easy to say ‘oops! I didn't know I was supposed to do that!’ but this is the sort of code that you should have been paying a lot more attention to. You literally are downloading something from the internet and running it with the highest privileges on the system" he emphasised on a May 30 call.

"I don't know, maybe that's the part that I'd look at first?”

He added: "Even in the best case scenario, if Gigabyte responds perfectly and does everything right, from here on out, realistically most people probably aren't installing that update; as a result, these things are going to be vulnerable until people stop using them..."

UPDATED with further input from John Loucaides following some questions from The Stack on the remote server certificate validation failures and the signature verification or otherwise of the executable. Answers below: "In HTTPS, you need to validate the certificate as well as the matching domain against what the server actually sent. The code fails to implement these checks. Therefore, any certificate can be used to complete the TLS session and allow the download. This is one of the specific items that GB fixed in their update...

"The MS AuthentiCode signature on most EXE files simply allows windows to run it without popping up something, and anyone can easily get something signed. That said, the kind of attacks we are referring to here are "living off the land" attacks where an existing admin tool gets reused in a capacity like this. In that case, it's already signed and the GB feature is abused to download and cause it to run early in boot and with privileges. When we say "normally downloaded" we mean the official Gigabyte files from their website.. as opposed to a malicious file that you might download when spoofing it, which is permitted by the above bug.
This is the second fix that GB implemented. They're checking for their particular signature on the downloaded file..."