Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security Privacy Hardware

Gigabyte Firmware Bugs Allow the Installation of BIOS/UEFI Ransomware (bleepingcomputer.com) 49

An anonymous reader writes from a report via BleepingComputer: Last week, at the BlackHat Asia 2017 security conference, researchers from cyber-security firm Cylance disclosed two vulnerabilities in the firmware of Gigabyte BRIX small computing devices, which allow an attacker to write malicious content to the UEFI firmware. During their presentation, researchers installed a proof-of-concept UEFI ransomware, preventing the BRIX devices from booting, but researchers say the same flaws can be used to plant rootkits that allow attackers to persist malware for years. The two vulnerabilities discovered are CVE-2017-3197 and CVE-2017-3198. The first is a failure on Gigabyte's part to implement write protection for its UEFI firmware. The second vulnerability is another lapse on Gigabyte's side, who forgot to implement a system that cryptographically signs UEFI firmware files. Add to this the fact that Gigabyte uses an insecure firmware update process, which doesn't check the validity of downloaded files using a checksum and uses HTTP instead of HTTPS. A CERT vulnerability note was published to warn users of the impending danger and the bugs' ease of exploitation.
This discussion has been archived. No new comments can be posted.

Gigabyte Firmware Bugs Allow the Installation of BIOS/UEFI Ransomware

Comments Filter:
  • Oh BIOS WP Jumper (Score:5, Insightful)

    by Anonymous Coward on Tuesday April 04, 2017 @07:27PM (#54174547)

    Oh how we miss you in the UEFI age!

    • by zifn4b ( 1040588 )

      Oh how we miss you in the UEFI age!

      You would think we would have learned from this. There were nasty viruses like this in the 90's. But nope. I think it's because no one knows how to program in assembly language anymore. In fact, a lot of young programmers be like "Assembly Language, what's that?" Meanwhile, some black hat that does know is like "Oooh, look at me, I rekt ur firmware bc u forgots to write protect it!"

      • haha! youre not far off. and the hackers are normally the people that have skill and were sick of being blamed for other peoples bad code. so they decide to find it and expose it first.

    • by AmiMoJo ( 196126 )

      I don't think there is any technical reason why you couldn't have a WP jump with UEFI. It uses the same kind of flash memory chips, and some people using Libreboot do lift the WP pin away from the motherboard after installing a trusted bootloader.

  • BRIX (Score:3, Funny)

    by Fragholio ( 574860 ) on Tuesday April 04, 2017 @07:27PM (#54174551)
    So, essentially, they can now turn a BRIX into a brick.
    • by AmiMoJo ( 196126 )

      You jest but actually bricking is the most likely outcome of an infection. Windows 8 and above will likely be using Secure Boot to verify that the UEFI firmware has not been compromised in this manner, so unless the attacker also gets hold of valid signing keys (from Microsoft) Windows will simply refuse to boot.

      It's recoverable of course, just re-install without Secure Boot enabled, but kind of a give-away. Would also cause a TPM module to refuse to give up any keys it held, potentially making encrypted dr

      • Sorry, SecureBoot is implemented in the very firmware you can own when WP is busted... so Windows will happily believe all is good. That's the point of these types of vulnerabilities.

        The TPM point would be valid if you actually manually configured which PCRs will cause BitLocker and remote attestation to fail. By default the firmware ones are NOT setup this way. Even if they were, it the attacker knew the expected measurements (from the original firmware), TPM has no signing on measurements and therefore yo

  • by freeze128 ( 544774 ) on Tuesday April 04, 2017 @07:34PM (#54174601)
    Computers have had that vulnerability for YEARS! It's not a *REMOTE* exploit. Anyone with physical access to the machine can flash the bios with something bad. It's only a problem with UEFI, which is supposed to have "SECURE BOOT" capability.
    • by Anonymous Coward

      Not entirely.

      Using http & no checksum means could be redirected. I've had computers that checked for new bios. All it needs is quiet driveby malware edit to hosts that redirects the next update check to a compromised server.

      The no checksum part scares me more than the malware potential. Really easy to kill your bios with a corrupt update.

      • Most decent motherboards have a backup BIOS chip so you cant flash corrupt FW and brick your mother board. I can verify ASUS and GIGABYTE AMD motherboards have them(i have multiple of both) If it sees a boot fail from bad FW update, it will pull last known good BIOS version from written chip. Also most High-end motherboards have actual removable BIOS chips that you can have the manufacturer send replacments with new bios version on it(for use when you have old run of board and put a not supported in this ve

    • by Anonymous Coward

      "Add to this the fact that Gigabyte uses an insecure firmware update process, which doesn't check the validity of downloaded files using a checksum and uses HTTP"

      so remotely is possible.

    • Updated to 2107 with a little ransomware flair.

    • Re:Well, DUH! (Score:5, Interesting)

      by wbr1 ( 2538558 ) on Tuesday April 04, 2017 @09:37PM (#54175167)
      But.. this does not require direct physical access. since the download mechanism for the manufacturer updates is not encrypted it could easily be patched in by an adversary with advanced capabilities. Even if it were https it could be vulnerable to MITM attacks to modify the flash files. And really, no checksum and/or signature? This is an APTs wet dream.
      • by AHuxley ( 892839 )
        Buy some bulk ISP traffic and just search for device updates. If the IP is the same weeks or months later that device might still be online.
      • by zifn4b ( 1040588 )

        And really, no checksum and/or signature? This is an APTs wet dream.

        Like leaving your front door unlocked

    • by Anonymous Coward

      The goal of this report is to make the existence of Intel CPU backdoors a common knowledge and provide information on backdoor removal.

      What we know about Intel CPU backdoors so far:

      TL;DR version

      Your Intel CPU and Chipset is running a backdoor as we speak.

      The backdoor hardware is inside the CPU/Bridge and the backdoor firmware (Intel Management Engine) is in the chipset flash memory.

      30C3 Intel ME live hack:
      @21m43s, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.
      [Video Link] 30C3: Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware [youtube.com]
      [Quotes] Vortrag [events.ccc.de]:
      "DAGGER exploits Intel's Manageability Engine (ME), that executes firmware code such as Intel's Active Management Technology (iAMT), as well as its OOB network channel."

      "the ME provides a perfect environment for undetectable sensitive data leakage on behalf of the attacker. Our presentation consists of three parts. The first part addresses how to find valuable data in the main memory of the host. The second part exploits the ME's OOB network channel to exfiltrate captured data to an external platform and to inject new attack code to target other interesting data structures available in the host runtime memory. The last part deals with the implementation of a covert network channel based on JitterBug."

      "We have recently improved DAGGER's capabilites to include support for 64-bit operating systems and a stealthy update mechanism to download new attack code."

      "To be more precise, we show how to conduct a DMA attack using Intel's Manageability Engine (ME)."

      "We can permanently monitor the keyboard buffer on both operating system targets."

      Backdoor removal:
      The backdoor firmware can be removed by following this guide [github.io] using the me_cleaner [github.com] script.
      Removal requires a Raspberry Pi (with GPIO pins) and a SOIC clip.

      Decoding Intel backdoors:
      The situation is out of control and the Libreboot/Coreboot community is looking for BIOS/Firmware experts to help with the Intel ME decoding effort.

      If you are skilled in these areas, download Intel ME firmwares from this collection [win-raid.com] and have a go at them, beware Intel is using a lot of counter measures to prevent their backdoors from being decoded (explained below).

      1. Introduction, what is Intel ME

      Short version, from Intel staff:

      Re: What Intel CPUs lack Intel ME secondary processor? [intel.com]
      Amy_Intel Feb 8, 2016 9:27 AM

      The Management Engine (ME) is an isolated and protected coprocessor, embedded as a non-optional part in all current Intel chipsets, I even checked with the engineering department and they confirmed it.

      Long version:

      ME: Management Engine [libreboot.org]

      The Intel Management Engine (ME) is a separate computing environment physically located in the MCH chip or PCH chip replacing ICH.

      The ME consists of an individual processor core, code and data caches, a timer, and a secure internal bus to which additional devices are connected, including a cryptography engine, internal ROM and RAM, memory controllers, and a direct memory access (DMA) engine to access the host operating system's memory as well as to reserve a region of protected external memory to supplement the ME's limited internal RAM. The ME also has network access with its own MAC address through the Intel Gigabit Ethernet Controller integrated in the southbridge (ICH or PCH).

      The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can report to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can't be ignored.

      ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3/i5/i7 CPU and a PCH, include "ME Ignition" firmware that performs some hardware initialization and power management. If the ME's boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after 30 minutes.

      Quotes on Intel backdoors:

      A message from RMS [fsf.org]
      by Richard Stallman on Dec 29, 2016 09:45 AM

      The current generation of Intel and AMD processor chips are designed with vicious back doors that users cannot shut off. (In Intel processors, it's the "management engine".)

      No users should trust those processors.

      2. The backdoor is next to impossible to decode and reverse engineer:

      Due to multiple instruction sets + custom compression algorithm.
      The Trouble With Intel's Management Engine [hackaday.com]

      While most of the firmware for the ME also resides in the Flash chip used by the BIOS, the firmware isn't readily readable; some common functions are in an on-chip ROM and cannot be found by simply dumping the data from the Flash chip.

      This means that if you're trying to figure out the ME, a lot of the code is seemingly missing. Adding to the problem, a lot of the code itself is compressed with either LZMA or Huffman encoding. There are multiple versions of the Intel ME, as well, all using completely different instruction sets: ARC, ARCompact, and SPARC V8. In short, it's a reverse-engineer's worst nightmare.

      To break the Management Engine, though, this code will have to be reverse engineered, and figuring out the custom compression scheme that's used in the firmware remains an unsolved problem.

      But unsolved doesn't mean that people aren't working on it. There are efforts to break the ME's Huffman algorithm. Of course, deciphering the code we have would lead to another road block: there is still the code on the inaccessible on-chip ROM. Nothing short of industrial espionage or decapping the chip and looking at the silicon will allow anyone to read the ROM code. While researchers do have some idea what this code does by inferring the functions, there is no way to read and audit it. So the ME remains a black box for now.

      3. Onboard ethernet and WiFi is part of the backdoor:

      The ME has its own MAC and IP address for the out-of-band interface, with direct access to the Ethernet controller; one portion of the Ethernet traffic is diverted to the ME even before reaching the host's operating system

      If your CPU has Intel Anti-Theft Technology enabled, it is also possible to directly access the backdoor from cell towers using 3G.

      4. The backdoor uses encrypted communication:

      https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Using_Intel_AMT [wikipedia.org]

      AMT version 4.0 and higher can establish a secure communication tunnel between a wired PC and an IT console outside the corporate firewall. In this scheme, a management presence server (Intel calls this a "vPro-enabled gateway") authenticates the PC, opens a secure TLS tunnel between the IT console and the PC

      5. Recent backdoors run Java applets

      *3 billion devices run Java* and everyone's motherboard is running it.

      https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#cite_ref-is_31-0 [wikipedia.org]

      Starting with ME 7.1, the ARC processor can also execute signed Java applets. The ME state is stored in a partition of the SPI flash, using the Embedded Flash File System.

      6. Possible attack vectors from Intel/CIA/NSA (who holds the certifica

  • by Anonymous Coward
    With a name like Brix...
    Was Crasht already taken?
  • Oh come on. (Score:5, Informative)

    by mhkohne ( 3854 ) on Tuesday April 04, 2017 @07:41PM (#54174637) Homepage

    Can we please just go back to making sure the BIOS is right BEFORE shipping the motherboard and putting it in ROM? That would really help, thanks!

    Or at least put a 'write protect' jumper on there? The people who will actually update their BIOS can find a jumper...

    • +1 for the jumper!
      It's NOT THAT HARD to add a jumper for the WE# signal.

      • by Anonymous Coward

        Or a screw, like chromeboxes, though that is just google making sure their malware is not misplaced.

        Captcha:combated

    • by AmiMoJo ( 196126 )

      We can go back to making sure the BIOS is perfect before shipping, if you want to pay 3x as much or wait a couple of years or narrow down hardware compatibility significantly (e.g. RAM, CPU models).

      It's the old, "good, fast, cheap - pick any two" scenario.

    • by phorm ( 591458 )

      Right for what? Many of the BIOS upgrades I've downloaded dealt with hardware or situations that weren't present at the time the motherboard came out. Yes, there are bugfixes as well, but even these often deal with "allows hardware X (made after BIOS release) which doesn't play nicely in situation Y"

  • Demand that devices come with a "hardware reset switch" that will reset the firmware and other settings to factory condition.

    Yes, your data is still screwed if you get firmware ransomware that encrypts your storage, but at least you can get your device back.

    I would allow for one exception: Devices like phones and laptops which may NEED to be remotely controlled or even "perma-bricked" if they are stolen or otherwise fall out of your physical control. This kind of theft-protection/deterrent is incompatible

  • by Anonymous Coward

    Boot loaders should be ROM (not flash, EEPROM, etc.) and everything else should either be removable or not persistent.

  • by Gravis Zero ( 934156 ) on Tuesday April 04, 2017 @08:19PM (#54174823)

    Security people have been warning people about this possibility for a long time. I certain various government agencies from various governments have developed their own UEFI rootkits for a slew of motherboards.

    • Yes the CIA/NSA has, I have a buddy that is combing through the recent 'Vault 7' leak. and from what im understanding from talking to him, to actually use UEFI correctly is a pain in the ass. It can be made secure. But takes skill and patience.

  • by Joe_Dragon ( 2206452 ) on Tuesday April 04, 2017 @08:40PM (#54174917)

    can we have more dual bios boards?

    http://www.gigabyte.us/microsi... [gigabyte.us]

    is real old.

    • by l20502 ( 4813775 )
      Huh?
      I see plenty of both ultradurable and gaming series with DualBIOS
    • by phorm ( 591458 )

      That only works if an attacker isn't able to write the secondary BIOS. If the attacked can "pollute" the first BIOS then he/she could also do it to the second unless there's a physical impediment to doing so.

      One good way to secure this might be the good ol' BIOS jumper, but instead of flashing have multiple options/jumpers

      Flash jumper (3-pin)
      No pins: No BIOS flashing allowed (prevents BIOS drive-by's)
      A+B) Allow flashing BIOS A
      B+C) Allow flashing BIOS B

      Boot jumper (2-pin):
      open: Boot from BIOS A (default)
      clos

  • Somebody needs to rake GB over the damn coals for this shit. This is terrible and inexcusable.

PURGE COMPLETE.

Working...