BadPower Vulnerability In Fast Chargers Might Make Phones Halt And Catch Fire

A few days ago, Chinese researchers from technology giant Tencent released a paper outlining a firmware vulnerability in several types of fast charger power bricks (translated). The attack is known as BadPower, and it works by altering the default parameters in the firmware of fast chargers to deliver more power to devices than they can handle, which can cause them to overheat, melt, or catch fire.

The ancient and basic USB charging spec provides 0.5 A at 5 V, which is equal to 2.5 W. In theory, that’s all you’ll ever get from those types of chargers. But the newer generation of chargers are different. When you plug your phone into a fast charger, it negotiates a voltage and charging speed with your phone before passing it any power.

Fast chargers can push power at 20 V or more to speed up the charging process, depending on the charger and connected device. If the phone doesn’t do fast charging, it will default to the 5 V standard. Researchers claim the BadPower attack is capable of harming devices whether or not they include a fast charging feature. When a capable device is connected, the charger will still negotiate for 5V, but instead give 20V and wreak havoc.

In the demo after the break, one of the team uses a malicious device disguised as a phone to push the BadPower firmware change to a fast charger that’s hooked up to a voltmeter. Before the attack, the charger gives 5V. After the attack, it gives 5V for a few seconds before jumping up near 20V. Then they connect the now-dirty charger to two identical illuminated magnifying glasses. In one the chip lets the smoke monster out rather violently, and the chips of the other emit sparks.

The researchers tested 35 of the 200+ fast charging bricks currently on the market and found that 18 of them were vulnerable to BadPower, including 11 that can be exploited through the charging port itself. They believe the issue is fixable with a firmware update.

What is not available is enough information to verify this research, or a list of brands/models that are vulnerable. Researchers say the findings were submitted to the China National Vulnerability Database (CNVD) on March 27th, so the absence of this information may be a product of manufacturers needing more time to patch the vulnerability.

What do you think? We say halfway decent chargers shouldn’t be open to firmware attacks from the devices they are charging. And any halfway decent phone should have built-in electrical protection, right?

Continue reading “BadPower Vulnerability In Fast Chargers Might Make Phones Halt And Catch Fire”

This Week In Security: Chrome Speech Bug, UDP Fragmentation, And The Big Citrix Vulnerability

A critical security bug was fixed in Chrome recently, CVE-2020-6378. The CVE report is still marked private, as well as the bug report. All we have is “Use-after-free in speech recognizer”. Are we out of luck, trying to learn more about this vulnerability? If you look closely at the private bug report, you’ll notice it’s in the Chromium bug tracker. Chrome is based primarily on the Chromium project, with a few proprietary features added. Since Chromium is open source, we can go find the code change that fixed this bug, and possibly learn more about it.

Off to the Chromium source, mirrored on Github. We could look at every commit, and eventually find the one we’re looking for, but Chromium commit messages usually include a reference to the bug that is fixed by that commit. So, we can use Github’s search function to find a commit that mentions 1018677. Just like that, we’ve found a single commit and more information.

The shutdown mentioned in the commit message is possibly referring to the browser being closed, but could also refer to the tab doing the speech recognizing, or even the speech system itself. Because multiple parts are being unloaded in parallel, there is a race condition between calling the abort object, and that object being unloaded from memory. This race can result in a classic use-after-free, jumping code execution to a memory location that’s already been freed.

All interesting, but how does this warrant a Critical rating? Enter the Web Speech API. I’m speculating just a bit, but it’s likely that this API uses the speech recognizer code in question. It may even be interacting with the security prompt that triggers the crash. Imagine that an attacking page attempts to use the speech API, and then releases the API object before the user can respond to the prompt. That *might* be the scenario that was discovered, though we’re deep into speculation, now. Continue reading “This Week In Security: Chrome Speech Bug, UDP Fragmentation, And The Big Citrix Vulnerability”

UPnP, Vulnerability As A Feature That Just Won’t Die

UPnP — in a perfect world it would have been the answer to many connectivity headaches as we add more devices to our home networks. But in practice it the cause of a lot of headaches when it comes to keeping those networks secure.

It’s likely that many Hackaday readers provide some form of technical support to relatives or friends. We’ll help sort out Mom’s desktop and email gripes, and we’ll set up her new router and lock it down as best we can to minimise the chance of the bad guys causing her problems. Probably one of the first things we’ll have all done is something that’s old news in our community; to ensure that a notorious vulnerability exposed to the outside world is plugged, we disable UPnP on whatever cable modem or ADSL router her provider supplied.

Continue reading “UPnP, Vulnerability As A Feature That Just Won’t Die”

Apple Kernel Code Vulnerability Affected All Devices

Another day, another vulnerability. Discovered by [Kevin Backhouse], CVE-2018-4407 is a particularly serious problem because it is present all throughout Apple’s product line, from the Macbook to the Apple Watch. The flaw is in the XNU kernel shared by all of these products.

This is a buffer overflow issue in the error handling for network packets. The kernel is expecting a fixed length of those packets but doesn’t check to prevent writing past the end of the buffer. The fact Apple’s XNU kernel powers all their products is remarkable, but issues like this are a reminder of the potential downside to that approach. Thanks to responsible disclosure, a patch was pushed out in September.

Anatomy of a Buffer Overflow

Buffer overflows aren’t new, but a reminder on what exactly is going on might be in order. In low level languages like C, the software designer is responsible for managing computer memory manually. They allocate memory, tagging a certain number of bytes for a given use. A buffer overflow is when the program writes more bytes into the memory location than are allocated, writing past the intended limit into parts of memory that are likely being used for a different purpose. In short, this overflow is written into memory that can contain other data or even executable code.

With a buffer overflow vulnerability, an attacker can write whatever code they wish to that out-of-bounds memory space, then manipulate the program to jump into that newly written code. This is referred to as arbitrary code execution. [Computerphile] has a great walk-through on buffer overflows and how they lead to code execution.

This Overflow Vulnerabilty Strikes Apple’s XNU Kernel

[Kevin] took the time to explain the issue he found in further depth. The vulnerability stems from the kernel code making an assumption about incoming packets. ICMP error messages are sent automatically in response to various network events. We’re probably most familiar with the “connection refused’ message, indicating a port closed by the firewall. These ICMP packets include the IP header of the packet that triggered the error. The XNU implementation of this process makes the assumption that the incoming packet will always have a header of the correct length, and copies that header into a buffer without first checking the length. A specially crafted packet can have a longer header, and this is the data that overflows the buffer.

Because of the role ICMP plays in communicating network status, a closed firewall isn’t enough to mitigate the attack. Even when sent to a closed port, the vulnerability can still trigger. Aside from updating to a patched OS release, the only mitigation is to run the macOS firewall in what it calls “stealth mode”. This mode doesn’t respond to pings, and more importantly, silently drops packets rather than sending ICMP error responses. This mitigation isn’t possible for watchOS and iOS devices.

The good news about the vulnerability is that a packet, malformed in this way, has little chance of being passed through a router at all. An attacker must be on the same physical network in order to send the malicious packet. The most likely attack vector, then, is the public WiFi at the local coffee shop.

Come back after the break for a demonstration of this attack in action.

Continue reading “Apple Kernel Code Vulnerability Affected All Devices”

PGP Vulnerability Pre-announced By Security Researcher

From the gaping maw of the infosec Twitterverse comes horrifying news. PGP is broken. How? We don’t know. When will there be any information on this vulnerability? Tomorrow. It’s the most important infosec story of the week, and it’s only Monday. Of course, this vulnerability already has a name. Everyone else is calling it eFail, but I’m calling it Fear, Uncertainty, and Doubt.

Update: eFail site and paper now available. This was released ahead of Tuesday’s planned announcement when the news broke ahead of a press embargo.

Update 2: The report mentions two attacks. The Direct Exfiltration attack wraps the body of a PGP-encrypted email around an image tag. If a mail client automatically decrypts this email, the result will be a request to a URL containing the plaintext of the encrypted email. The second attack only works one-third of the time. Mitigation strategies are to not decrypt email in a client, disable HTML rendering, and in time, update the OpenPGP and S/MIME standards. This is not the end of PGP, it’s a vulnerability warranting attention from those with a very specific use case.

Update 3: Hackaday has published an in-depth explanation of how eFail works which details the scope of the vulnerability.

[Sebastian Schinzel] announced on Twitter today he will be announcing a critical vulnerability in PGP/GPG and S/MIME email encryption. This vulnerability may reveal the plaintext of encrypted emails. There are currently no fixes — but there’s no proof of concept, or any actual publication of this exploit either. The only thing that’s certain: somebody on Twitter said encrypted email is broken.

The EFF has chimed in on this exploit and advises everyone to immediately disable and uninstall tools that automatically decrypt PGP-encrypted email. It also looks like the EFF came up with a great little logo for eFail as well so kudos on that.

While there are no details whatsoever concerning eFail aside from a recommendation to not use PGP, a few members of the community have seen a pre-press of the eFail paper. [Werner Koch] of GnuPG says eFail is simply using HTML as a back channel. If this is true, PGP is still safe; you just shouldn’t use HTML emails. If you really need to read HTML emails, use a proper MIME parser and disallow access to external links. It should be noted that HTML in email is already an attack vector and has been for decades. You don’t need to bring PGP into this.

Should you worry about a vulnerability in PGP and email encryption? Literally no one knows. European security researchers are working on a publication release right now, but other experts in the field who have seen the paper think it’s not a big deal. There is no consensus from experts in the field, and there is no paper available right now. That last point will change in a few hours, but for now eFail just stands for Fear, Uncertainty, and Doubt.

Joykill: Previously Undisclosed Vulnerability Endangers User Data

Researchers have recently announced a vulnerability in PC hardware enabling attackers to wipe the disk of a victim’s computer. This vulnerability, going by the name Joykill, stems from the lack of proper validation when enabling manufacturing system tests.

Joykill affects the IBM PCjr and allows local and remote attackers to destroy the contents of the floppy diskette using minimal interaction. The attack is performed by plugging two joysticks into the PCjr, booting the computer, entering the PCjr’s diagnostic mode, and immediately pressing button ‘B’ on joystick one, and buttons ‘A’ and ‘B’ on joystick two. This will enable the manufacturing system test mode, where all internal tests are performed without user interaction. The first of these tests is the diskette test, which destroys all user data on any inserted diskette. There is no visual indication of what is happening, and the data is destroyed when the test is run.

A local exploit destroying user data is scary enough, but after much work, the researchers behind Joykill have also managed to craft a remote exploit based on Joykill. To accomplish this, the researchers built two IBM PCjr joysticks with 50-meter long cables.

Researchers believe this exploit is due to undocumented code in the PCjr’s ROM. This code contains diagnostics code for manufacturing burn-in, system test code, and service test code. This code is not meant to be run by the end user, but is still exploitable by an attacker. Researchers have disassembled this code and made their work available to anyone.

As of the time of this writing, we were not able to contact anyone at the IBM PCjr Information Center for comment. We did, however, receive an exciting offer for a Carribean cruise.

Bluetooth Vulnerability Affects All Major OS

Security researchers from Armis Labs recently published a whitepaper unveiling eight critical 0-day Bluetooth-related vulnerabilities, affecting Linux, Windows, Android and iOS operating systems. These vulnerabilities alone or combined can lead to privileged code execution on a target device. The only requirement is: Bluetooth turned on. No user interaction is necessary to successfully exploit the flaws, the attacker does not need to pair with a target device nor the target device must be paired with some other device.

The research paper, dubbed BlueBorne (what’s a vulnerability, or a bunch, without a cool name nowadays?), details each vulnerability and how it was exploited. BlueBorne is estimated to affect over five billion devices. Some vendors, like Microsoft, have already issued a patch while others, like Samsung, remain silent. Despite the patches, some devices will never receive a BlueBorne patch since they are outside of their support window. Armis estimates this accounts for around 40% of all Bluetooth enabled devices.

A self-replicating worm that would spread and hop from a device to other nearby devices with Bluetooth turned on was mentioned by the researchers as something that could be done with some more work. That immediately reminds us of the BroadPwn vulnerability, in which the researchers implemented what is most likely the first WiFi only worm. Although it is definitely a fun security exercise to code such worm, it’s really a bad, bad idea… Right?…

So who’s affected?

Continue reading “Bluetooth Vulnerability Affects All Major OS”