Gigabyte Firmware Flaws Allow the Installation of UEFI Ransomware

Zarathustra[H]

Extremely [H]
Joined
Oct 29, 2000
Messages
38,741
At the BlackhHat Asia 2017 security conference on Friday researchers from cyber-security firm Cylance demonstrated two Gigabyte vulnerabilities which allow malicious code to be written to the UEFI firmware. The demonstration involved installing proof-of-concept UEFI ransomware preventing a Gigabyte Brix computer from booting. Researchers suggest that the same vulnerabilities can allow for the installation of rootkits allowing attackers to install persistent malware that reinstalls itself once cleared off of the installed system.

I wonder how this would be cleared. I'd imagine pulling the BIOS EEPROM and reprogramming it external to the motherboard would be required, and that would require an EEPROM programmer, which very few of us have. One thing is certain. Clearing malware is potentially going to get a lot more tricky in the future if exploits like these wind up being used in the wild.

The attacker gains user-mode execution through an application vulnerability such as a browser exploit or a malicious Word document with an embedded script. From there, the attacker elevates his privileges by exploiting the kernel or a kernel module such as Capcom.sys to execute code in ring 0. A vulnerable SMI handler allows the attacker to execute code in SMM mode (ring -2) where he finally can bypass any write protection mechanisms and install a backdoor into the system's firmware. Write-protection mechanisms exist to prevent attackers from modifying the firmware; however, the affected systems do not enable them.
 
Looks like it just affects the Brix systems and not their regular motherboards? I read the article and didn't find anything that noted if it was further spread.
 
At the BlackhHat Asia 2017 security conference on Friday researchers from cyber-security firm Cylance demonstrated two Gigabyte vulnerabilities which allow malicious code to be written to the UEFI firmware. The demonstration involved installing proof-of-concept UEFI ransomware preventing a Gigabyte Brix computer from booting. Researchers suggest that the same vulnerabilities can allow for the installation of rootkits allowing attackers to install persistent malware that reinstalls itself once cleared off of the installed system.

I wonder how this would be cleared. I'd imagine pulling the BIOS EEPROM and reprogramming it external to the motherboard would be required, and that would require an EEPROM programmer, which very few of us have. One thing is certain. Clearing malware is potentially going to get a lot more tricky in the future if exploits like these wind up being used in the wild.

The attacker gains user-mode execution through an application vulnerability such as a browser exploit or a malicious Word document with an embedded script. From there, the attacker elevates his privileges by exploiting the kernel or a kernel module such as Capcom.sys to execute code in ring 0. A vulnerable SMI handler allows the attacker to execute code in SMM mode (ring -2) where he finally can bypass any write protection mechanisms and install a backdoor into the system's firmware. Write-protection mechanisms exist to prevent attackers from modifying the firmware; however, the affected systems do not enable them.

You can also hotswap reporgram if you can gain access to another computer with the same mobo
 
  • Like
Reactions: erexx
like this
I was wondering how long this would take. I'm sure certain agencies are already using this exploit.

That said, things like restoring bios versions from the USB key (ASUS motherboards) should fix the issue....provided the USB bios update subroutines are protected from overwrite. That should be the only piece of ROM on a motherboard. (Like on satellites and NASA rovers that allow the entire system to be rewritten for patches and work arounds for bad components)
 
Hackers are always able to royally screw over computers if they have admin/physical access.

Granted this would be harder to detect than many ransomwares but preventing it also lock out homebrew BIOS updates/updaters which are a thing. Looks like that's the intended state for these devices to only allow signed updates though

Also odds are this is doable on many computers, not just Gigabyte, since they all use common frameworks
 
A very quick search for pricing of EEPROM programmers showed me $14.95 to $1595.00 prices.

I hope the $14.95 is sufficient for backing up and programming the EEPROM on my new and not so new systems.
 
A very quick search for pricing of EEPROM programmers showed me $14.95 to $1595.00 prices.

I hope the $14.95 is sufficient for backing up and programming the EEPROM on my new and not so new systems.

I remember reading a while back how to make one for $5 as an arduino add on so I'm sure the $15 one is sufficient. Might be slow as shit but it's probably good enough.
 
Who would have thought a mini OS that you have no control over that boots before your OS would be exploited.
Its time they let us have control over its network access without resorting to a programmable external firewall.
But that would limit law enforcement so we'll never see it.

I'd love to see a smoothwall type firewall built onto the mobo.
 
You can also hotswap reporgram if you can gain access to another computer with the same mobo
This can work even if its not. Just needs to be a compatible socket and in theory any bios can be burned this way. So if your lucky an external programmer isnt needed.
Some Gigabyte and other boards have dual bios. There are addons for boards with socketed bios.
 
At the BlackhHat Asia 2017 security conference on Friday researchers from cyber-security firm Cylance demonstrated two Gigabyte vulnerabilities which allow malicious code to be written to the UEFI firmware. The demonstration involved installing proof-of-concept UEFI ransomware preventing a Gigabyte Brix computer from booting. Researchers suggest that the same vulnerabilities can allow for the installation of rootkits allowing attackers to install persistent malware that reinstalls itself once cleared off of the installed system.

I wonder how this would be cleared. I'd imagine pulling the BIOS EEPROM and reprogramming it external to the motherboard would be required, and that would require an EEPROM programmer, which very few of us have. One thing is certain. Clearing malware is potentially going to get a lot more tricky in the future if exploits like these wind up being used in the wild.

The attacker gains user-mode execution through an application vulnerability such as a browser exploit or a malicious Word document with an embedded script. From there, the attacker elevates his privileges by exploiting the kernel or a kernel module such as Capcom.sys to execute code in ring 0. A vulnerable SMI handler allows the attacker to execute code in SMM mode (ring -2) where he finally can bypass any write protection mechanisms and install a backdoor into the system's firmware. Write-protection mechanisms exist to prevent attackers from modifying the firmware; however, the affected systems do not enable them.

you could hot-swap the eeprom to another motherboard and flash it there.
 
All said if this starts to be more of a thing I may well want to have my own eeprom programmer. At least I wont need a UV light with this one.
 
are socket bios chips all that common now?? I don't think so..

I know my Gigabyte GA-Z87X-UD3H (few years old now..still rocking a i7-4770K) has surface mount bios chips... it does have the dual bios.. but the chips are surface mounted... so if you wanted to replace them physically you'd have to be ready for some fairly advanced soldering / desoldering work .

I guess the question is was it something specifically related to the BRIX bios / hardware ... or is this something that could affect other gigabyte / other brands UEFI bios???
 
That is a good question. Gonna take a look at my mono when I get home from work.
 
This is how satellites and scientific instrumentation in space are protected:

  1. Computer powers up. CPU Instruction and Data segment register is hard coded to read from ROM only upon power up. IP is set in motion.
  2. ROOT BIOS ROM starts up to reset and stabilize system (Boot strap) Test power systems, RAM, eeproms, bootup setting CRCs, OS CRC etc.
  3. Communications mode starts up. stabilize satellite, reorient to link up antennas.
  4. Establish a ground link communication. Why? In case the satellite or instrument was damaged by micrometeorites, solar radiation (plasma), sabotage, f-ups by programmers, or plain old wearing out, it might need a new OS to bypass damaged systems. Engaging the stored OS first could result in instability.
  5. See if there is an updated image located from Step 6 if no further updates from step 4. Start applying image if available and reboot.
  6. ELSE If update is requested, verify the signature and start applying the patch. Confirm the CRC and create a raw backup. Store into the boot area.
  7. Boot from image
There's more to it than this, there are various other custom steps, and safe modes and additional security. But you guys get the idea. This is all written to a bullet (radiation hardened) ROM that can't be reprogrammed. These things cost thousands of dollars for a few K, but they are damn near indestructible. Luckily we don't need bullet hardened hardware.

If you established a similar ROM on a motherboard, none of you would have worry about nasty crap like this. Instead of establishing a ground link, you just read from the USB port and restore an image if it's located there. This takes effect before step 7, so the damaged area doesn't have the ability to stay in control.
 
Does this type of attack affect mobos that have dual BIOS that can only be mechanically switched?

I am also pretty sure that the backup BIOS is a read-only BIOS (can't be written onto).

My Mobo in question is Z97X-UD5H with a 4790k
 
They said UEFI was secure. LOL
Do you really need an >2TB drive as an OS drive anyways? It's not like an OS is crack proof either.
 
have you been to "space", or ever seen a working satellite? ps, not on tv

I used to design them. I wrote firmware and designed circuits for NASA GSFC a long time ago.

BTW: I love your other post. Troll-r-riffic!
 
Last edited by a moderator:
This is how satellites and scientific instrumentation in space are protected:

  1. Computer powers up. CPU Instruction and Data segment register is hard coded to read from ROM only upon power up. IP is set in motion.
  2. ROOT BIOS ROM starts up to reset and stabilize system (Boot strap) Test power systems, RAM, eeproms, bootup setting CRCs, OS CRC etc.
  3. Communications mode starts up. stabilize satellite, reorient to link up antennas.
  4. Establish a ground link communication. Why? In case the satellite or instrument was damaged by micrometeorites, solar radiation (plasma), sabotage, f-ups by programmers, or plain old wearing out, it might need a new OS to bypass damaged systems. Engaging the stored OS first could result in instability.
  5. See if there is an updated image located from Step 6 if no further updates from step 4. Start applying image if available and reboot.
  6. ELSE If update is requested, verify the signature and start applying the patch. Confirm the CRC and create a raw backup. Store into the boot area.
  7. Boot from image
There's more to it than this, there are various other custom steps, and safe modes and additional security. But you guys get the idea. This is all written to a bullet (radiation hardened) ROM that can't be reprogrammed. These things cost thousands of dollars for a few K, but they are damn near indestructible. Luckily we don't need bullet hardened hardware.

If you established a similar ROM on a motherboard, none of you would have worry about nasty crap like this. Instead of establishing a ground link, you just read from the USB port and restore an image if it's located there. This takes effect before step 7, so the damaged area doesn't have the ability to stay in control.


I hope you understand this is not specific to special equipment, further it isnt even "protection" that is the by the book process of booting any modern or even not so modern cpu based piece of whatever. Steps 5/6 merely use a hard drive on the ground rather than one in the box.

Apple 1, 2, 3, lisa, macs, 8086, 8088, 80286, 80368....... systems did things like that.

Read up on how Apple and early X86 systems would use ram to patch rom if you'd like.

Except when you have a new hard drive, new ram, new cpu, new whatever and it rendered the system unbootable you had to replace the bios chip, take it to a service center, burn your own etc.

Things in remote locations (including orbit) dont need to deal with frequent equipment updates, OS updates, and the vast realm of strange things you can plug into or connect a x86/Windows/Linux/MacOS box.

By controlling the hardware enough to have given Steve Jobs 100 wet dreams that box in orbit is just a lot easier and simpler to manage.

-edit type
 
I hope you understand this is not specific to special equipment, further it isnt even "protection" that is the by the book process of booting any modern or even not so modern cpu based piece of whatever. Steps 5/6 merely use a hard drive on the ground rather than one in the box.

Apple 1, 2, 3, lisa, macs, 8086, 8088, 80286, 80368....... systems did things like that.

Read up on how Apple and early X86 systems would use ram to patch rom if you'd like.

Except when you have a new hard drive, new ram, new cpu, new whatever and it rendered the system unbootable you had to replace the bios chip, take it to a service center, burn your own etc.

Steps 5/6 would be from a backup image stored on a USB key. A backup image can not be corrupted even if the UEFI is, provided the backup image is loaded first from the ROM into the raw storage, then validated, and applied to the EEPROM.

Yes but you can have a boot strap ROM that can not be corrupted. That is always your safe out from a corrupted system. That ROM can load an image from raw storage and write it to EEPROM (the UEFI) (step 6). The EEPROM then has the option of loading the OS or applying an OS update. The UEFI is designed keep running even if you replace all the swapable components.
 
Back
Top