At this year’s BlackHat Asia security conference, researchers from Cylance disclosed two potentially fatal flaws in the UEFI firmware of Gigabyte BRIX small computers which allow a would-be attacker unfettered low-level access to the computer.
Gigabyte has been working on a fix since the start of 2017. Gigabyte are preparing to release firmware updates as a matter of urgency to only one of the affected models — GB-BSi7H-6500 (firmware vF6), while leaving the — GB-BXi7-5775 (firmware vF2) unpatched as it has reached it’s end of life. We understand that support can’t last forever, but if you sell products with such a big fault from the factory, it might be worth it to fix the problem and keep your reputation.
The two vulnerabilities that have been discovered seem like a massive oversight from Gigabyte, They didn’t enable write protection for their UEFI (CVE-2017-3197), and seem to have thrown cryptography out of the window when it comes to signing their UEFI files (CVE-2017-3198). The latter vulnerability is partly due to not verifying a checksum or using HTTPS in the firmware update process, instead using its insecure sibling HTTP. CERT has issued an official vulnerability note (VU#507496) for both flaws.
Attackers may exploit the vulnerabilities to execute unsigned code in System Management Mode (SMM), planting whatever malware they like into the low level workings of the computer. Cylance explain a possible scenario as follows:
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.
With all this said, it does raise some interesting opportunities for the hacker community. We wonder if anyone will come up with a custom UEFI for the Brix since Gigabyte left the keys in the door.
Something is rotten in the state of Intel. Over the last decade or so, Intel has dedicated enormous efforts to the security of their microcontrollers. For Intel, this is the only logical thing to do; you really, really want to know if the firmware running on a device is the firmware you want to run on a device. Anything else, and the device is wide open to balaclava-wearing hackers.
Intel’s first efforts toward cryptographically signed firmware began in the early 2000s with embedded security subsystems using Trusted Platform Modules (TPM). These small crypto chips, along with the BIOS, form the root of trust for modern computers. If the TPM is secure, the rest of the computer can be secure, or so the theory goes.
The TPM model has been shown to be vulnerable to attack, though. Intel’s solution was to add another layer of security: the (Intel) Management Engine (ME). Extremely little is known about the ME, except for some of its capabilities. The ME has complete access to all of a computer’s memory, its network connections, and every peripheral connected to a computer. It runs when the computer is hibernating, and can intercept TCP/IP traffic. Own the ME and you own the computer.
There are no known vulnerabilities in the ME to exploit right now: we’re all locked out of the ME. But that is security through obscurity. Once the ME falls, everything with an Intel chip will fall. It is, by far, the scariest security threat today, and it’s one that’s made even worse by our own ignorance of how the ME works.
Continue reading “The Trouble With Intel’s Management Engine”
[Moogle] wrote in to see if anyone can figure out why his unused electrolytic capacitors are popping. This is the behavior you see in populated caps whose electrolyte dries out. But these are still in his parts bin. Anyone know why they would pop when going unused?
We see a lot of BIOS flashing hacks; but it’s always a handy thing to know about when you get in a bind. Here [Adan] shows us how to reflash a corrupt BIOS using a Tiva C Launchpad board.
Wanting to hack together her own blow gun [Carlyn] scrapped a handheld vacuum cleaner. When she discovered the pump could not easily be converted from suck to blow she made a handheld suction manipulator which picks up paper plates and a few slightly heavier objects.
Unfortunately a drill press is not one of the tools we have in our lair right now. If we did, this tip about using it to help tap threads in a hole would come in really hand.
Retro computing fans will appreciate this Z80 computer build (translated). It’s a fairly large mainboard with plenty of chips, resistors, buttons, and seven segment displays. Excellent. [Thanks Daniel]
We start to drool a little bit when we see a teardown post that shows off a piece of equipment really well. We’ve already reached for a bib to catch the slobber from pawing our way through [David’s] teardown of an HP 6010A bench supply.
We’ve seen the Arduino used to flash BIOS chips several times now. But these hacks are almost always the result of a bad flash. This time around [GNUtoo] is interested in putting a tool in your hands which can be used to flash Coreboot to your motherboard. His offering uses the Arduino Uno, but there are several other hardware options covered as well.
The firmware makes use of the serprog-duino library which was crafted at writing to flash memory chips. On the computer side of things the flashrom package pushes the BIOS image to the Arduino. The nice thing is the flashrom is a common packge in Linux repositories so it’s probably just an apt-get away.
The process isn’t fast, taking about ten minutes to program a 1 Mb chip. But if you’re just interested in loading an open source BIOS alternative this is easy to set up.
This clever hack uses an Arduino to do a brute force attack on a computer’s BIOS. In theory, this technique could be used for other programs, but it’s use would be limited since there’s no way to account for too many wrong passwords.
The Arduino generates and outputs the possible password emulating a USB keyboard. When this is done, the pixel in the middle of the screen is read. This is done by reading the analog red signal synced up with the corresponding horizontal and vertical pulses. As with any hack, there were some programming issues that had to be overcome (including one that locked up the keyboard emulator), but this was resolved, and the code is available if you wan to build your own.
Hardware for this build is simple, involving a LCD output, a button to stop everything, and a couple diodes to get the USB keyboard working correctly. This hack turned out quite nicely, and the code and schematics are included!
[Jeremy] had an ASUS EEE PC 1000HE netbook on his hands which had succumbed to a corrupted BIOS. In most situations, people replace a motherboard when the BIOS is damaged beyond repair, but considering the price of motherboards, especially those built for portable devices, he simply refused to go that route.
Instead, he took it apart and did a little investigation to find out what SPI flash chip ASUS used in the netbook. With that information in hand, he put together an SPI flash programmer using a breadboard and a DLP-USB1232H USB to UART module. He couldn’t program the flash chip in-circuit, so he had to desolder it and deadbugged it onto his programmer. Using a few Linux-based flashing tools, he was able to reprogram the chip with a functioning BIOS in short order, saving him from a costly motherboard replacement.
While some motherboard manufacturers have built in secondary BIOS chips to prevent the need for this sort of recovery, it’s nice to know that the process is relatively straightforward, provided you have some basic soldering and Linux skills.
This also isn’t the first time we’ve seen someone recover an EEE PC from the brink – if you’re looking for an Arduino-based alternative, be sure to check this out.
In his line of work, Instructables user [Harrymatic] sees a lot of Toshiba laptops come across his desk, some of which are protected with a BIOS password. Typically, in order to make it past the BIOS lockout and get access to the computer, he would have to open the laptop case and short the CMOS reset pins or pull the CMOS battery. The process is quite tedious, so he prefers to use a simpler method, a parallel loopback plug.
The plug itself is pretty easy to build. After soldering a handful of wires to the back of a standard male D-sub 25 connector in the arrangement shown in his tutorial, he was good to go. When a laptop is powered on with the plug inserted, the BIOS password is cleared, and the computer can be used as normal.
It should be said that he is only positive that this works with the specific Toshiba laptop models he lists in his writeup. It would be interesting to see this tried with other laptop brands to see if they respond in the same way.
Since no laptops are manufactured with parallel ports these days, do you have some tips or tricks for recovering laptop BIOS passwords? Be sure to share them with us in the comments.