Another Defeat Of The Intel Management Engine

December 7, 2017 by Bryan Cockfield 53 Comments

If you have a computer with an Intel processor that’s newer than about 2007, odds are high that it also contains a mystery software package known as the Intel Management Engine (ME). The ME has complete access to the computer below the operating system and can access a network, the computer’s memory, and many other parts of the computer even when the computer is powered down. If you’re thinking that this seems like an incredible security vulnerability then you’re not alone, and a team at Black Hat Europe 2017 has demonstrated yet another flaw in this black box (PDF), allowing arbitrary code execution and bypassing many of the known ME protections.

[Mark Ermolov] and [Maxim Goryachy] are the two-man team that discovered this exploit, only the second of its kind in the 12 years that the ME has been deployed. Luckily, this exploit can’t be taken advantage of (yet) unless an attacker has physical access to the device. Intel’s firmware upgrades also do not solve the problem because the patches still allow for use of older versions of the ME. [Mark] and [Maxim] speculate in their presentation that this might be fixed on the next version of the ME, but also note that these security vulnerabilities would disappear if Intel would stop shipping processors with the ME.

We won’t hold our breath on Intel doing the right thing by eliminating the ME, though. It’s only a matter of time before someone discovers a zero-day (if they haven’t already, there’s no way to know) which could cripple pretty much every computer built within the last ten years. If you’re OK with using legacy hardware, though, it is possible to eliminate the management engine and have a computer that doesn’t have crippling security vulnerabilities built into it. This post was even written from one. Good luck doing anything more resource-intensive with it, though.

Radio Controlled Pacemakers Are Easily Hacked

May 27, 2017 by Jack Laidlaw 40 Comments

Doctors use RF signals to adjust pacemakers so that instead of slicing a patient open, they can change the pacemakers parameters which in turn avoids unnecessary surgery. A study on security weaknesses of pacemakers (highlights) or full Report (PDF) has found that pacemakers from the main manufacturers contain security vulnerabilities that make it possible for the devices to be adjusted by anyone with a programmer and proximity. Of course, it shouldn’t be possible for anyone other than medical professionals to acquire a pacemaker programmer. The authors bought their examples on eBay.

They discovered over 8,000 known vulnerabilities in third-party libraries across four different pacemaker programmers from four manufacturers. This highlights an industry-wide problem when it comes to security. None of the pacemaker programmers required passwords, and none of the pacemakers authenticated with the programmers. Some home pacemaker monitoring systems even included USB connections in which opens up the possibilities of introducing malware through an infected pendrive.

The programmers’ firmware update procedures were also flawed, with hard-coded credentials being very common. This allows an attacker to setup their own authentication server and upload their own firmware to the home monitoring kit. Due to the nature of the hack, the researchers are not disclosing to the public which manufacturers or devices are at fault and have redacted some information until these medical device companies can get their house in order and fix these problems.

This article only scratches the surface for an in-depth look read the full report. Let’s just hope that these medical companies take action as soon as possible and resolve these issue’s as soon as possible. This is not the first time pacemakers have been shown to be flawed.

Yet Another IoT Botnet

May 17, 2017 by Jack Laidlaw 19 Comments

[TrendMicro] are reporting that yet another IoT botnet is emerging. This new botnet had been dubbed Persirai and targets IP cameras. Most of the victims don’t even realize their camera has access to the Internet 24/7 in the first place.

Trend Micro, have found 1,000 IP cameras of different models that have been exploited by Persirai so far. There are at least another 120,000 IP cameras that the botnet could attack using the same method. The problem starts with the IP cameras exposing themselves by default on TCP Port 81 as a web server — never a great idea.

Most IP cameras use Universal Plug and Play, which allows them to open ports from inside the router and start a web server without much in the way of security checks. This paints a giant target in cyber space complete with signs asking to be exploited. After logging into a vulnerable device the attacker can perform a command injection attack which in turn points gets the camera to download further malware.

The exploit runs in memory only, so once it has been rebooted it should all be fine again until your next drive by malware download. Check your devices, because even big named companies make mistakes. IoT is turning into a battlefield. We just hope that with all these attacks, botnets, and hacks the promise of the IoT idea isn’t destroyed because of lazy coders.

Part of feature image from Wikipedia, Creative Commons license.

Gigabytes The Dust With UEFI Vulnerabilities

April 4, 2017 by Jack Laidlaw 46 Comments

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.

32C3: Beyond Your Cable Modem

December 29, 2015 by Elliot Williams 20 Comments

[Alexander Graf] gave an absolutely hilarious talk at 32C3 about the security flaws he found in cable modems from two large German ISPs. The vulnerability was very serious, resulting in remote root terminals on essentially any affected cable modem, and the causes were trivial: unencrypted passwords in files that are sent over TFTP or Telnet to the modems, for instance.

While [Alexander] was very careful to point out that he’d disclosed all of these vulnerabilities to the two German cable ISPs that were affected, he notably praised one of them for its speedy response in patching up the holes. As for the other? “They’d better hurry up.” He also mentions that, although he’s not sure, he suspects that similar vulnerabilities are present in other countries. Oh dear.

A very interesting point in the talk is the way that [Alexander] chose to go about informing the cable ISPs. Instead of going to them directly and potentially landing himself in jail, he instead went to the press, and let his contacts at the press talk to the ISPs. This both shielded him from the potential initial heat and puts a bit of additional pressure on the ISPs to fix the vulnerability — when the story hits the front page, they would really like to be ahead of the problem.

There’s even a bone for you die-hard hardware hackers out there who think that all of this software security stuff is silly. To get the modem’s firmware in the first place, at minute 42 of the talk, [Alexander] shows briefly how he pulled the flash chip off the device and read it into his computer using a BeagleBone Black. No JTAG, no nothing. Just pulling the chip off and reading it the old-fashioned way.

If you’ve got an hour, go watch [Alexander]’s talk. It’s a fun romp through some serious vulnerabilities.

Remove Security Issues From Untrusted USB Connections

June 23, 2015 by Bryan Cockfield 30 Comments

USB has become pretty “universal” nowadays, handling everything from high-speed data transfer to charging phones. There are even USB-powered lava lamps. This ubiquity doesn’t come without some costs, though. There have been many attacks on smartphones and computers which exploit the fact that USB is found pretty much everywhere, and if you want to avoid these attacks you can either give up using USB or do what [Jason] did and block the data lines on the USB port.

USB typically uses four wires: two for power and two for data. If you simply disconnect the data lines, though, the peripheral can’t negotiate with the host for more power and will limp along at 0.5 watts. However, [Jason] discovered that this negotiation takes place at a much lower data rate than normal data transfer, and was able to put a type of filter in between the host and the peripheral. The filter allows the low-frequency data transfer pass through but when a high-frequency data transfer occurs the filter blocks the communication.

[Jason] now has a device that can allow his peripherals to charge at the increased rate without having to worry about untrusted USB ports (at an airport or coffee shop, for example). This simple device could stop things like BadUSB from doing their dirty work, although whether or not it could stop something this nasty is still up in the air.

Exposing Private Facebook Photos With A Malicious App

March 20, 2015 by Rick Osgood 21 Comments

[Laxman] is back again with another hack related to Facebook photos. This hack revolves around the Facebook mobile application’s “sync photos” function. This feature automatically uploads every photo taken on your mobile device to your Facebook account. These photos are automatically marked as private so that only the user can see them. The user would have to manually update the privacy settings on each photo later in order to make them available to friends or the public.

[Laxman] wanted to put these privacy restrictions to the test, so he started poking around the Facebook mobile application. He found that the Facebook app would make an HTTP GET request to a specific URL in order to retrieve the synced photos. This request was performed using a top-level access token. The Facebook server checked this token before sending down the private images. It sounds secure, but [Laxman] found a fatal flaw.

The Facebook server only checked the owner of the token. It did not bother to check which Facebook application was making the request. As long as the app had the “user_photos” permission, it was able to pull down the private photos. This permission is required by many applications as it allows the apps to access the user’s public photos. This vulnerability could have allowed an attacker access to the victim’s private photos by building a malicious application and then tricking victims into installing the app.

At least, that could have been the case if Facebook wasn’t so good about fixing their vulnerabilities. [Laxman] disclosed his finding to Facebook. They had patched the vulnerability less than an hour after acknowledging the disclosure. They also found this vulnerability severe enough to warrant a $10,000 bounty payout to [Laxman]. This is in addition to the $12,500 [Laxman] received last month for a different Facebook photo-related vulnerability.