Update On The BLUFFS Bluetooth Vulnerability

December 2, 2023 by 12 Comments

As we first reported in yesterday’s weekly security post, researchers at EURECOM have revealed the details (PDF, references) of a new man-in-the-middle (MITM) attack on Bluetooth 4.2 through 5.4, which has been assigned CVE-2023-24023. Like preceding CVEs, it concerns the session authentication between Bluetooth devices, where the attacker uses spoofed paired or bonded devices to force the use of a much shorter encryption key length.

The name of this newly discovered vulnerability is BLUFFS (Bluetooth Forward and Future Secrecy), where forward and future secrecy are important terms that refer to the protection of secure sessions against compromise in the past (forward, FoS) and future (FuS). The CVE presentation notes that the Bluetooth specification does not cover either FuS or FoS. In total two new architectural vulnerabilities were discovered, both of which attack the security key.

The Bluetooth SIG has released a statement regarding this attack method. Although serious, it would seem that the core issue is that some implementations allow for encryption key lengths below 7 octets:

Continue reading “Update On The BLUFFS Bluetooth Vulnerability” →

This Week In Security: Not A Vulnerability, BGP Bug Propogation, And Press Enter To Hack

September 1, 2023 by 6 Comments

Curl was recently notified of a CVE, CVE-2020-19909, rated at a hair-raising 9.8 on the CVSS scale. And PostgreSQL has CVE-2020-21469, clocking in with a 7.5 severity. You may notice something odd about those two vulnerabilities, but I promise the 2020 date is only the tip of the iceberg here.

Let’s start with PostgreSQL. That vulnerability was only present in version 12.2, which released in February of 2020, and was fixed with the 12.3 release in May of that same year. The problem is a stack buffer overflow, which doesn’t seem to enable code execution, but does cause a denial of service situation. To trigger the bug? Repeatedly send the PostgreSQL daemon the SIGHUP signal.

If you’re familiar with Linux signals, that might sound odd. See, the SIGHUP signal technically indicates the end of a user session, but most daemons use it to indicate a restart or reload request. And to send this signal, a user has to have elevated privileges — elevated enough to simply stop the daemon altogether. Put simply, it’s not a security vulnerability, just a minor bug.

And now on to curl — This one is just bizarre. The issue is a integer overflow in the --retry-delay argument, which specifies in seconds how often curl should retry a failing download. The value is multiplied by 1000 to convert to milliseconds, resulting in an overflow for very large values. The result of that overflow? A smaller value for the retry delay.

[Daniel Stenberg] makes the point that this tale is a wonderful demonstration of the brokenness of the CVE system and NVD’s handling of it. And in this case, it’s hard not to see this as negligence. We have to work really hard to construct a theoretical scenario where this bug could actually be exploited. The best I’ve been able to come up with is an online download tool, where the user can specify part of the target name and a timeout. If that tool had a check to ensure that the timeout was large enough to avoid excess traffic, this bug could bypass that check. Should we be assigning CVEs for that sort of convoluted, theoretical attack?

But here’s the thing, that attack scenario should rate something like a CVSS of 4.8 at absolute worst. NVD assigned this a 9.8. There’s no way you can squint at this bug hard enough to legitimately rank it that severe. At the time of writing, the NVD lists this as “UNDERGOING REANALYSIS”.
Continue reading “This Week In Security: Not A Vulnerability, BGP Bug Propogation, And Press Enter To Hack” →

Serious Vulnerability In European Trunked Radio System

July 26, 2023 by 40 Comments

Trunked radio systems can be difficult to wrap one’s mind around, and that’s partially by design. They’re typically used by organizations like police, firefighters, and EMS to share a limited radio frequency band with a much larger number of users than would otherwise be able to operate. From a security standpoint, it also limits the effectiveness of scanners who might not know the control methods the trunked systems are using. But now a global standard for encrypted trunked radio systems, known as TETRA, has recently been found to have major security vulnerabilities, which could result in a lot more headache than disrupted voice communications.

One of the vulnerabilities in this radio system was a known backdoor, which seems to have been protected largely via a “security through obscurity” method. Since the system has been around for about 25 years now, it was only a matter of time before this became public knowledge. The backdoor could allow non-authorized users to snoop on encrypted radio traffic. A second serious vulnerability, unrelated to this backdoor, would further allow listening to encrypted voice traffic. There are a few other minor vulnerabilities recently uncovered by the same security researchers who found these two major ones, and the current recommendation is for anyone using a TETRA system to take a look to see if they are impacted by any of these issues.

Part of the reason this issue is so concerning is that these systems aren’t just used for encrypted voice among first responders. They also are used for critical infrastructure like power grids, rail networks, and other systems controlled by SCADA. This article from Wired goes into much more detail about this vulnerability as well, and we all know that most of our infrastructure already needs significant help when it comes to vulnerabilities to all kinds of failure modes.

Thanks to [cfacer] and [ToniSoft] who sent these tips!

Photo via Wikimedia Commons.

This Week In Security: GitHub Actions, SHA-1 Retirement, And A Self-Worming Vulnerability

December 23, 2022 by 6 Comments

It should be no surprise that running untrusted code in a GitHub Actions workflow can have unintended consequences. It’s a killer feature, to automatically run through a code test suite whenever a pull request is opened. But that pull request is run in some part of the target’s development environment, and there’s been a few clever attacks found over the years that take advantage of that. There’s now another one, what Legit Security calls Github Environment Injection, and there were some big-name organizations vulnerable to it.

The crux of the issue is the $GITHUB_ENV file, which contains environment variables to be set in the Actions environment. Individual variables get added to this file as part of the automated action, and that process needs to include some sanitization of data. Otherwise, an attacker can send an environment variable that includes a newline and completely unintended environment variable. And an unintended, arbitrary environment variable is game over for the security of the workflow. The example uses the NODE_OPTIONS variable to dump the entire environment to an accessible output. Any API keys or other secrets are revealed.

This particular attack was reported to GitHub, but there isn’t a practical way to fix it architecturally. So it’s up to individual projects to be very careful about writing untrusted data into the $GITHUB_ENV file.

Continue reading “This Week In Security: GitHub Actions, SHA-1 Retirement, And A Self-Worming Vulnerability” →

Bluetooth Vulnerability: Arbitrary Code Execution On The ESP32, Among Others

September 23, 2021 by 21 Comments

Bluetooth has become widely popular since its introduction in 1999. However, it’s also had its fair share of security problems over the years. Just recently, a research group from the Singapore University of Technology and Design found a serious vulnerability in a large variety of Bluetooth devices. Having now been disclosed, it is known as the BrakTooth vulnerability.

Full details are not yet available; the research team is waiting until October to publicly release proof-of-concept code in order to give time for companies to patch their devices. The basic idea however, is in the name. “Brak” is the Norweigan word for “crash,” with “tooth” referring to Bluetooth itself. The attack involves repeatedly attempting to crash devices to force them into undesired operation.

The Espressif ESP32 is perhaps one of the worst affected. Found in all manner of IoT devices, the ESP32 can be fooled into executing arbitrary code via this vulnerability, which can do everything from clearing the devices RAM to flipping GPIO pins. In smart home applications or other security-critical situations, this could have dire consequences.

Other chipsets are affected to varying degrees, including parts from manufacturers like Texas Instruments and Cypress Semiconductor. Some parts are vulnerable to denial of service, while audio devices may be frozen up or shut down by the attack. The group claims over 1400 products could be affected by the bug.

Firmware patches are being rolled out, and researcher [Matheus E. Garbelini] has released code to build a sniffer device for the vulnerability on GitHub. If you’re involved with the design or manufacture of Bluetooth hardware, it might pay to start doing some homework on this one! Concerned vendors can apply for proof-of-concept test code here.

ESP32 Vulnerability Affects Older Chips

September 24, 2020 by 24 Comments

There is a scene from the movie RED (Retired, Extremely Dangerous) where Bruce Willis encounters a highly-secure door with a constantly changing lock code deep inside the CIA. Knowing the lock would be impossible to break, he simply destroyed the wall next to the door, reached through, and opened the door from the other side. We thought about that when we saw [raelize’s] hack to bypass the ESP32’s security measures.

Before you throw out all your ESP32 spy gadgets, though, be aware that the V3 silicon can be made to prevent the attack. V1 and V2, however, have a flaw that — if you know how to exploit it — renders secure boot and flash encryption almost meaningless.

Continue reading “ESP32 Vulnerability Affects Older Chips” →

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

July 22, 2020 by 21 Comments

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” →