Why did [Hales] end up hacking the BIOS on a 10 year old laptop left over from an Australian education program? When your BIOS starts telling you you’re not allowed to use a particular type of hardware, you don’t have much of a choice.
Originally [Hales] planned on purchasing a used Lenovo X260 to replace his dying laptop, but his plans were wrecked. A pandemic-induced surge in demand that even the used laptop market caused prices to bloat. The need for a small and affordable laptop with a built in Ethernet port led to the purchase of a Lenovo Thinkpad x131e. Although the laptop was older than he liked, [Hales] was determined to make it work. Little did he know the right-to-repair journey he was about to embark on.
Problems first arose when the Broadcom WiFi adapter stopped working reliably. He replaced it, but the coaxial antenna cable was found to be damaged. Even after replacing the damaged cabling, the WiFi adapter was still operating very poorly. Recalling past problems with fickle Broadcom WiFi adapters, it was decided that an Intel mPCIe WiFi adapter would take its place. When power was re-applied, [Hales] was shocked to find the following message:
Unauthorized network card is plugged in – Power off and remove the miniPCI network card
And this is where things got interesting. With off the shelf SOIC8 clips and a CH340 programmer, [Hales] dumped the BIOS from the laptop’s flash chip to another computer and started hacking away. After countless hours of researching, prodding, hacking, and reverse engineering, the laptop was useful once again with the new Intel WiFi adapter. His site documents in great detail how he was able to reverse engineer the BIOS over the course of several days.
But that’s not all! [Hales] was also able to modify the hardware so that his slightly more modern mPCIe WiFi adapter would come back on after the computer had been put in Hibernation. It’s an elegant hack, and be sure to check [Hales’] site to get the full details. And at the end, there’s a nice Easter egg for anybody who’s ever wanted to make their laptop boot up with their own logo.
We applaud [Hales] for his fine efforts to keep working equipment out of the landfill. We’ve covered many hacks that had similar goals in the past. Do you have a hack you’d like to share? Submit it via the Tips Line.
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”