This Week In Security: The X DDoS, The ESP32 Basementdoor, And The CamelCase RCE

We would be remiss if we didn’t address the X Distributed Denial of Service (DDoS) attack that’s been happening this week. It seems like everyone is is trying to make political hay out of the DDoS, but we’re going to set that aside as much as possible and talk about the technical details. Elon made an early statement that X was down due to a cyberattack, with the source IPs tracing back to “the Ukraine area”.

The latest reporting seems to conclude that this was indeed a DDoS, and a threat group named “Dark Storm” has taken credit for the attack. Dark Storm does not seem to be of Ukrainian origin or affiliation.

We’re going to try to read the tea leaves just a bit, but remember that about the only thing we know for sure is that X was unreachable for many users several times this week. This is completely consistent with the suspected DDoS attack. The quirk of modern DDoS attacks is that the IP addresses on the packets are never trustworthy.

There are two broad tactics used for large-scale DDoS attacks, sometimes used simultaneously. The first is the simple botnet. Computers, routers, servers, and cameras around the world have been infected with malware, and then remote controlled to create massive botnets. Those botnets usually come equipped with a DDoS function, allowing the botnet runner to task all the bots with sending traffic to the DDoS victim IPs. That traffic may be UDP packets with spoofed or legitimate source IPs, or it may be TCP Synchronization requests, with spoofed source IPs.

The other common approach is the reflection or amplification attack. This is where a public server can be manipulated into sending unsolicited traffic to a victim IP. It’s usually DNS, where a short message request can return a much larger response. And because DNS uses UDP, it’s trivial to convince the DNS server to send that larger response to a victim’s address, amplifying the attack.

Put these two techniques together, and you have a botnet sending spoofed requests to servers, that unintentionally send the DDoS traffic on to the target. And suddenly it’s understandable why it’s so difficult to nail down attribution for this sort of attack. It may very well be that a botnet with a heavy Ukrainian presence was involved in the attack, which at the same time doesn’t preclude Dark Storm as the originator. The tea leaves are still murky on this one.

Continue reading “This Week In Security: The X DDoS, The ESP32 Basementdoor, And The CamelCase RCE”

The ESP32 Bluetooth Backdoor That Wasn’t

Recently there was a panicked scrambling after the announcement by [Tarlogic] of a ‘backdoor’ found in Espressif’s popular ESP32 MCUs. Specifically a backdoor on  the Bluetooth side that would give a lot of control over the system to any attacker. As [Xeno Kovah] explains, much about these claims is exaggerated, and calling it a ‘backdoor’ is far beyond the scope of what was actually discovered.

To summarize the original findings, the researchers found a number of vendor-specific commands (VSCs) in the (publicly available) ESP32 ROM that can be sent via the host-controller interface (HCI) between the software and the Bluetooth PHY. They found that these VSCs could do things like writing and reading the firmware in the PHY, as well as send low-level packets.

The thing about VSCs is of course that these are a standard feature with Bluetooth controllers, with each manufacturer implementing a range of these for use with their own software SDK. These VSCs allow for updating firmware, report temperatures and features like debugging, and are generally documented (except for Broadcom).

Effectively, [Xeno] makes the point that VSCs are a standard feature in Bluetooth controllers, which – like most features – can also be abused. [Tarlogic] has since updated their article as well to distance themselves from the ‘backdoor’ term and instead want to call these VSCs a ‘hidden feature’. That said, if these VSCs in ESP32 chips are a security risk, then as [Xeno] duly notes, millions of BT controllers from Texas Instruments, Broadcom and others with similar VSCs would similarly be a security risk.

This Week In Security: Zen Jailbreak, Telegram Exploit, And VMware Hyperjack

The fine researchers at Google have released the juicy details on EntrySign, the AMD Zen microcode issue we first covered about a month ago. And to give away the punchline: cryptography is hard. It’s hard in lots of ways, but the AMD problem here is all about keeping track of the guarantees provided by cryptographic primitives.
Continue reading “This Week In Security: Zen Jailbreak, Telegram Exploit, And VMware Hyperjack”

An excerpt from the website, showing the nRootTag block diagram and describing its structure

Hijacking AirTag Infrastructure To Track Arbitrary Devices

In case you weren’t aware, Apple devices around you are constantly scanning for AirTags. Now, imagine you’re carrying your laptop around – no WiFi connectivity, but BLE’s on as usual, and there’s a little bit of hostile code running at user privileges, say, a third-party app. Turns out, it’d be possible to make your laptop or phone pretend to be a lost AirTag – making it and you trackable whenever an iPhone is around.

The nroottag website isn’t big on details, but the paper ought to detail more; the hack does require a bit of GPU firepower, but nothing too out of the ordinary. The specific vulnerabilities making this possible have been patched in newer iOS and MacOS versions, but it’s still possible to pull off as long as an outdated-firmware Apple device is nearby!

Of course, local code execution is often considered a game over, but it’s pretty funny that you can do this while making use of the Apple AirTag infrastructure, relatively unprivileged, and, exfiltrate location data without any data connectivity whatsoever, all as long as an iPhone is nearby. You might also be able to exflitrate other data, for what it’s worth – here’s how you can use AirTag infrastructure to track new letter arrivals in your mailbox!

Here’s A Spy Movie-Grade Access Card Sniffing Implant

Some of our devices look like they’re straight out of hacker movies. For instance, how about a small board you plant behind an RFID reader, collecting access card data and then replaying it when you next walk up the door? [Jakub Kramarz] brings us perhaps the best design on the DIY market, called The Tick – simple, flexible, cheap, tiny, and fully open-source.

Take off the reader, tap into the relevant wires and power pins (up to 25V input), and just leave the board there. It can do BLE or WiFi – over WiFi, you get a nice web UI showing you the data collected so far, and letting you send arbitrary data. It can do Wiegand like quite a few open-source projects, but it can also do arbitrary clock+data protocols, plus you can just wire it up quickly, and it will figure out the encoding.

We could imagine such a board inside a Cyberpunk DnD rulebook or used in Mr Robot as a plot point, except that this one is real and you can use it today for red teaming and security purposes. Not to say all applications would be NSA-catalog-adjacent pentesting – you could use such a bug to reverse-engineer your own garage door opener, for one.

Screenshot of the REPL running on the Flipper, importing the flipper API library and calling infrared receive function out of it with help of autocomplete

A MicroPython Interpreter For Flipper Zero

Got a Flipper Zero? Ever wanted to use a high-level but powerful scripting language on it? Thanks to [Oliver] we now have a MicroPython application for the Flipper, complete with a library for hardware and software feature support. Load it up, start it up, connect over USB, and you’ve got the ever-so-convenient REPL at your disposal. Or, upload a Python script to your Flipper and run them directly from Flipper’s UI at your convenience!

In the API docs, we’re seeing support for every single primitive you could want – GPIO (including the headers at the top, of course), a healthy library for LCD and LCD backlight control, button handling, SD card support, speaker library for producing tones, ADC and PWM, vibromotor, logging, and even infrared transmit/receive support. Hopefully, we get support for Flipper’s wireless capabilities at some point, too!

Check out the code examples, get the latest release from the Flipper app portal or GitHub, load it up, and play! Mp-flipper has existed for the better half of a year now, so it’s a pretty mature application, and it adds quite a bit to Flipper’s use cases in our world of hardware hacking. Want to develop an app for the Flipper in Python or otherwise? Check out this small-screen UI design toolkit or this editor we’ve featured recently!

A PCR machine with its side cover taken off exposing its guts, and the tray extended out

Making A PCR Machine Crypto Sign Its Results

Money, status, or even survival – there’s no shortage of incentives for faking results in the scientific community. What can we do to prevent it, or at least make it noticeable? One possible solution is cryptographic signing of measurement results.

Here’s a proof-of-concept from [Clement Heyd] and [Arbion Halili]. They took a ThermoFisher Scientific 7500 Fast PCR (Polymerase Chain Reaction) machine, isolated its daughter-software, and confined it into a pipeline that automatically signs each result with help of a HSM (Hardware Security Module).

A many machines do, this one has to be paired to a PC, running bespoke software. This one’s running Windows XP, at least! The software got shoved into a heavily isolated virtual machine running XP, protected by TEE (Trusted Execution Environment). The software’s output is now piped into a data diode virtual serial port out of the VM, immediately signed with the HSM, and signed data is accessible through a read-only interface. Want to verify the results’ authenticity? Check them against the system’s public key, and you’re golden – in theory.

This design is just a part of the puzzle, given a typical chain of custody for samples in medical research, but it’s a solid start – and it happens to help make the Windows XP setup more resilient, too.

Wondering what PCR testing is good for? Tons of things all over the medical field, for instance, we’ve talked about PCR in a fair bit of detail in this article about COVID-19 testing. We’ve also covered a number of hacker-built PCR and PCR-enabling machines, from deceivingly simple to reasonably complex!