Flaw In AMD Platform Security Processor Affects Millions Of Computers

October 1, 2021 by Lewin Day 30 Comments

Another day, another vulnerability. This time, it’s AMD’s turn, with a broad swathe of its modern CPU lines falling victim to a dangerous driver vulnerability that could leave PCs open to all manner of attacks.

As reported by TechSpot, the flaw is in the driver for AMD Platform Security Processor (PSP), and could leave systems vulnerable by allowing attackers to steal encryption keys, passwords, or other data from memory. Today, we’ll take a look at what the role of the PSP is, and how this vulnerability can be used against affected machines.

Continue reading “Flaw In AMD Platform Security Processor Affects Millions Of Computers” →

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

September 23, 2021 by Lewin Day 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.

Razer Mouse Grants Windows Admin Privileges

August 26, 2021 by Bryan Cockfield 50 Comments

As the common saying goes, “all networked computers are vulnerable to exploits, but some networked computers are more vulnerable than others”. While not the exact wording from Animal Farm, the saying does have plenty of merit nonetheless. Sure, there are some viruses and issues with Linux distributions but by far most of the exploits target Windows, if only because more people use it daily than any other operating system. The latest Windows 10 exploit, discovered by [jonhat], is almost comically easy too, and involves little more than plugging in a mouse.

While slightly comforting in that an attacker would need physical access to the device rather than simple network access, it is very concerning how simple this attack is otherwise. Apparently plugging in a Razer mouse automatically launches Windows Update, which installs a driver for the mouse. The installation is run with admin privileges, and a Power Shell can be opened by the user simply by pressing Shift and right-clicking the mouse. While [jonhat] originally tried to let the company know, they weren’t responsive until he made the exploit public on Twitter, and are now apparently working on solving the issue.

Others have confirmed the exploit does in fact work, so hopefully there is a patch released soon that solves the issue. In the meantime, we recommend not allowing strangers to plug any devices into your personal computers as a general rule, or plugging in anything where its origins are unknown. Also remember that some attacks don’t required physical or network access at all, like this one which remotely sniffs keystrokes from a wireless keyboard with less than stellar security, also coincidentally built by Microsoft.

Separation Between WiFi And Bluetooth Broken By The Spectra Co-Existence Attack

August 7, 2020 by Pedro Umbelino 5 Comments

This year, at ~~DEF CON 28~~ DEF CON Safe Mode, security researchers [Jiska Classen] and [Francesco Gringoli] gave a talk about inter-chip privilege escalation using wireless coexistence mechanisms. The title is catchy, sure, but what exactly is this about?

To understand this security flaw, or group of security flaws, we first need to know what wireless coexistence mechanisms are. Modern devices can support cellular and non-cellular wireless communications standards at the same time (LTE, WiFi, Bluetooth). Given the desired miniaturization of our devices, the different subsystems that support these communication technologies must reside in very close physical proximity within the device (in-device coexistence). The resulting high level of reciprocal leakage can at times cause considerable interference.

There are several scenarios where interference can occur, the main ones are:

Two radio systems occupy neighboring frequencies and carrier leakage occurs
The harmonics of one transmitter fall on frequencies used by another system
Two radio systems share the same frequencies

To tackle these kind of problems, manufacturers had to implement strategies so that the devices wireless chips can coexist (sometimes even sharing the same antenna) and reduce interference to a minimum. They are called coexistence mechanisms and enable high-performance communication on intersecting frequency bands and thus, they are essential to any modern mobile device. Despite open solutions exist, such as the Mobile Wireless Standards, the manufacturers usually implement proprietary solutions.

Spectra

Spectra is a new attack class demonstrated in this DEF CON talk, which is focused on Broadcom and Cypress WiFi/Bluetooth combo chips. On a combo chip, WiFi and Bluetooth run on separate processing cores and coexistence information is directly exchanged between cores using the Serial Enhanced Coexistence Interface (SECI) and does not go through the underlying operating system.

Spectra class attacks exploit flaws in the interfaces between wireless cores in which one core can achieve denial of service (DoS), information disclosure and even code execution on another core. The reasoning here is, from an attacker perspective, to leverage a Bluetooth subsystem remote code execution (RCE) to perform WiFi RCE and maybe even LTE RCE. Keep in mind that this remote code execution is happening in these CPU core subsystems, and so can be completely invisible to the main device CPU and OS.

Join me below where the talk is embedded and where I will also dig into the denial of service, information disclosure, and code execution topics of the Spectra attack.

Continue reading “Separation Between WiFi And Bluetooth Broken By The Spectra Co-Existence Attack” →

Copy And Paste Deemed Insecure

June 18, 2020 by Al Williams 23 Comments

Back when Windows NT was king, Microsoft was able to claim that it met the strict “Orange Book” C2 security certification. The catch? Don’t install networking and remove the floppy drives. Turns out most of the things you want to do with your computer are the very things that are a security risk. Even copy and paste.

[Michal Benkowki] has a good summary of his research which boils down to the following attack scenario:

Visit a malicious site.
Copy something to the clipboard which allows the site to put in a dangerous payload.
Visit another site with a browser-based visual editor (e.g., Gmail or WordPress)
Paste the clipboard into the editor.

Continue reading “Copy And Paste Deemed Insecure” →

Fail Of The Week: Padlock Purports To Provide Protection, Proves Pathetic

January 21, 2020 by Dan Maloney 49 Comments

Anyone in the know about IoT security is likely to steer clear of a physical security product that’s got some sort of wireless control. The list of exploits for such devices is a long, sad statement on security as an afterthought, if at all. So it’s understandable if you think a Bluetooth-enabled lock is best attacked via its wireless stack.

As it turns out, the Master 5440D Bluetooth Key Safe can be defeated in a few minutes with just a screwdriver. The key safe is the type a realtor or AirBnB host would use to allow access to a property’s keys. [Bosnianbill] embarked on an inspection of the $120 unit, looking for weaknesses. When physical attacks with a hammer and spoofing the solenoids with a magnet didn’t pay off, he decided to strip off the resilient skin that Master so thoughtfully provided to prevent the box from marring the finish of a door or gate. The denuded device thus revealed its awful secret: two Phillips screws, each securing a locking shackle to the cover. Once those are loose, a little prying with a screwdriver is all that’s need to get the keys to the kingdom.

In a follow-up video posted later, [Bill] took a closer look at another key safe and found that Master had made an anemic effort to fix this vulnerability with a squirt of epoxy in each screw head. It’s weak, at best, since a tap with a hammer compresses the gunk enough to get a grip on the screw.

We really thought [Bosnianbill]’s attack would be electronic, like that time [Dave Jones] cracked a safe with an oscilloscope. Who’d have thought a screwdriver would be the best way past the wireless stack?

Continue reading “Fail Of The Week: Padlock Purports To Provide Protection, Proves Pathetic” →

ESP8266 And ESP32 WiFi Hacked!

September 5, 2019 by Elliot Williams 48 Comments

[Matheus Garbelini] just came out with three (3!) different WiFi attacks on the popular ESP32/8266 family of chips. He notified Espressif first (thanks!) and they’ve patched around most of the vulnerabilities already, but if you’re running software on any of these chips that’s in a critical environment, you’d better push up new firmware pretty quick.

The first flaw is the simplest, and only effects ESP8266s. While connecting to an access point, the access point sends the ESP8266 an “AKM suite count” field that contains the number of authentication methods that are available for the connection. Because the ESP doesn’t do bounds-checking on this value, a malicious fake access point can send a large number here, probably overflowing a buffer, but definitely crashing the ESP. If you can send an ESP8266 a bogus beacon frame or probe response, you can crash it.

What’s most fun about the beacon frame crasher is that it can be implemented on an ESP8266 as well. Crash-ception! This takes advantage of the ESP’s packet injection mode, which we’ve covered before.

The second and third vulnerabilities exploit bugs in the way the ESP libraries handle the extensible authentication protocol (EAP) which is mostly used in enterprise and higher-security environments. One hack makes the ESP32 or ESP8266 on the EAP-enabled network crash, but the other hack allows for a complete hijacking of the encrypted session.

These EAP hacks are more troubling, and not just because session hijacking is more dangerous than a crash-DOS scenario. The ESP32 codebase has already been patched against them, but the older ESP8266 SDK has not yet. So as of now, if you’re running an ESP8266 on EAP, you’re vulnerable. We have no idea how many ESP8266 devices are out there in EAP networks, but we’d really like to see Espressif patch up this hole anyway.

[Matheus] points out the irony that if you’re using WPA2, you’re actually safer than if you’re unpatched and using the nominally more secure EAP. He also wrote us that if you’re stuck with a bunch of ESP8266s in an EAP environment, you should at least encrypt and sign your data to prevent eavesdropping and/or replay attacks.

Again, because [Matheus] informed Espressif first, most of the bugs are already fixed. It’s even percolated downstream into the Arduino-for-ESP, where it’s just been worked into the latest release a few hours ago. Time for an update. But those crusty old NodeMCU builds that we’ve got running everything in our house? Time for a full recompile.

We’ve always wondered when we’d see the first ESP8266 attacks in the wild, and that day has finally come. Thanks, [Matheus]!