This Week In Security: Macstealer, 3CX Carnage, And Github’s Lost Key

March 31, 2023 by Jonathan Bennett 6 Comments

There’s a naming overload here, as two bits of security news this week are using the “MacStealer” moniker. We’re first going to talk about the WiFi vulnerability, also known as Framing Frames (pdf). The WPA encryption schemes introduced pairwise encryption, ensuring that not even other authenticated users can sniff each others’ traffic. At least that’s the idea, but this attack finds a couple techniques to bypass that protection.

A bit more background, there are a couple ways that packets can be delayed at the sender side. One of those is the power-save message, that signals the access point that the given client is going into a low power state. “Hold my calls, I’m going to sleep.” That message is a single bit in a frame header. And notably, that bit isn’t covered by WPA encryption or verification. An attacker can send a message, spoof a victim’s MAC address, and the access point marks that client as being in power-save mode.

This observation leads to a question: What happens when the encryption details change between the packet joining the queue, and actually transmitting? Turns out, the specifications on WiFi encryption don’t spell it out, and some implementations do the last thing you’d want, like sending the packets in the clear. Whoops. This behavior was the case in the Linux kernel through version 5.5.0, but starting with 5.6.0, the buffered packets were simply dropped when the encryption key was unavailable. Continue reading “This Week In Security: Macstealer, 3CX Carnage, And Github’s Lost Key” →

Screenshot of the SDR software in action, with decoded data in a terminal, and a map that shows the location received from the decoded data

Loudmouth DJI Drones Tell Everyone Where You Are

March 26, 2023 by Arya Voronova 42 Comments

Back when commercial quadcopters started appearing in the news on the regular, public safety was a talking point. How, for example, do we keep them away from airports? Well, large drone companies didn’t want the negative PR, so some voluntarily added geofencing and tracking mechanisms to their own drones.

When it comes to DJI, one such mechanism is DroneID: a beacon on the drone itself, sending out a trove of data, including its operator’s GPS location. DJI also, of course, sells the Aeroscope device that receives and decodes DroneID data, declared to be for government use. As it often is with privacy-compromising technology, turns out it’s been a bigger compromise than we expected.

Questions started popping up last year, as off-the-shelf quadcopters (including those made by DJI) started to play a part in the Russo-Ukrainian War. It didn’t take long for Ukrainian forces to notice that launching a DJI drone led to its operators being swiftly attacked, and intel was that Russia got some Aeroscopes from Syria. DJI’s response was that their products were not meant to be used this way, and shortly thereafter cut sales to both Russia and Ukraine.

But security researchers have recently discovered the situation was actually worse than we expected. Back in 2022, DJI claimed that the DroneID data was encrypted, but [Kevin Finisterre]’s research proved that to be a lie — with the company finally admitting to it after Verge pushed them on the question. It wouldn’t even be hard to implement a worse-than-nothing encryption that holds up mathematically. However, it seems, DroneID doesn’t even try: here’s a GitHub repository with a DroneID decoder you can use if you have an SDR dongle.

Sadly, the days of companies like DJI standing up against the anti-copter talking points seem to be over, Now they’re setting an example on how devices can subvert their owners’ privacy without reservation. Looks like it’s up to hackers on the frontlines to learn how to excise DroneID, just like we’ve done with the un-nuanced RF power limitations, or the DJI battery DRM, or transplanting firmware between hardware-identical DJI flight controller models.

Continue reading “Loudmouth DJI Drones Tell Everyone Where You Are” →

Showing the dock PCB with a Pi Zero attached and wired up onto it

Is Your USB-C Dock Out To Hack You?

March 26, 2023 by Arya Voronova 20 Comments

In today’s installment of Betteridge’s law enforcement, here’s an evil USB-C dock proof-of-concept by [Lachlan Davidson] from [Aura Division]. We’ve seen malicious USB devices aplenty, from cables and chargers to flash drives and even suspicious USB fans. But a dock, however, is new. The gist is simple — you take a stock dock, find a Pi Zero W and wire it up to a USB 2.0 port tapped somewhere inside the dock. Finding a Pi Zero is unquestionably the hardest part in this endeavor — on the software side, everything is ready for you, just flash an SD card with a pre-cooked malicious image and go!

On the surface level, this might seem like a cookie-cutter malicious USB attack. However, there’s a non-technical element to it; USB-C docks are becoming more and more popular, and with the unique level of convenience they provide, the “plug it in” temptation is much higher than with other devices. For instance, in shared workspaces, having a USB-C cable with charging and sometimes even a second monitor is becoming a norm. If you use USB-C day-to-day, the convenience of just plugging a USB-C cable into your laptop becomes too good to pass up on.

This hack doesn’t exactly use any USB-C specific technical features, like Power Delivery (PD) – it’s more about exploiting the convenience factor of USB-C that incentivizes you to plug a USB-C cable in, amplifying an old attack. Now, BadUSB with its keystroke injection is no longer the limit — with a Thunderbolt-capable USB-C dock, you can connect a PCIe device to it internally and even get access to a laptop’s RAM contents. Of course, fearing USB-C cables is not a viable approach, so perhaps it’s time for us to start protecting from BadUSB attacks on the software side.

This Week In Security: USB Boom! Acropalypse, And A Bitcoin Heist

March 24, 2023 by Jonathan Bennett 4 Comments

We’ve covered a lot of sketchy USB devices over the years. And surely you know by now, if you find a USB drive, don’t plug it in to your computer. There’s more that could go wrong than just a malicious executable. We’ve covered creative and destructive ideas here on Hackaday, from creative firmware to capacitors that fry a machine when plugged in. But what happened to a handful of Ecuadorian journalists was quite the surprise. These drives went out with a bang.

That is, they literally exploded. The drives each reportedly contained a pellet of RDX, a popular explosive in use by militaries since the second World War. There have been five of these hyperactive USB devices located so far, and only one actually detonated. It seems that one only managed to trigger half of its RDX payload. Because of this, and the small overall size of a USB drive, the explosion was more comparable to a firecracker than a bomb. Continue reading “This Week In Security: USB Boom! Acropalypse, And A Bitcoin Heist” →

Screenshot of ImHex hex editor, with the MOC3 file structure being reverse-engineered inside of it

Live2D: Silently Subverting Threat Models

March 20, 2023 by Arya Voronova 10 Comments

In online spaces, VTubers have been steadily growing in popularity in the past few years – they are entertainers using motion capture tech to animate a special-sauce 2D or 3D model, typically livestreaming it as their avatar to an audience. The tech in question is pretty fun, lively communities tend to form around the entertainers and artists involved, and there’s loads of room for creativity in the VTuber format; as for viewers, there’s a VTuber for anyone’s taste out there – what’s not to like? On the tech side of making everything work, most creators in the VTubing space currently go with a software suite from a company called Live2D – which is where today’s investigation comes in. Continue reading “Live2D: Silently Subverting Threat Models” →

This Week In Security: Kali Purple, Malicious Notifications, And Cybersecurity Strategy

March 17, 2023 by Jonathan Bennett 2 Comments

After a one-week hiatus, we’re back. It’s been a busy couple weeks, and up first is the release of Kali Purple. This new tool from Kali Linux is billed as an SOC-in-a-box, that follows the NIST CSF structure. That is a veritable alphabet soup of abbreviated jargon, so let’s break this down a bit. First up, SOC IAB or SOC-in-a-box is integrated software for a Security Operation Center. It’s intrusion detection, intrusion prevention, data analysis, automated system accounting and vulnerability scanning, and more. Think a control room with multiple monitors showing graphs based on current traffic, a list of protected machines, and log analysis on demand.

NIST CSF is guidance published by the National Institute of Standards and Technology, a US government agency that does quite a bit of the formal ratification of cryptography and other security standards. CSF is the CyberSecurity Framework, which among other things, breaks cybersecurity into five tasks: identify, protect, detect, respond, and recover. The framework doesn’t map perfectly to the complexities of security, but it’s what we have to work with, and Kali Purple is tailor-made for that framework.

Putting that aside, what Purple really gives you is a set of defensive and analytical tools that rival the offensive tools in the main Kali distro. Suricata, Arkime, Elastic, and more are easily deployed. The one trick that really seems to be missing is the ability to deploy Kali Purple as the edge router/firewall. The Purple deployment docs suggest an OPNSense deployment for the purpose. Regardless, it’s sure to be worthwhile to watch the ongoing development of Kali Purple.

Continue reading “This Week In Security: Kali Purple, Malicious Notifications, And Cybersecurity Strategy” →

Breaking Into The Nintendo DSi Through The (Browser) Window

March 13, 2023 by Matthew Carlson 9 Comments

The Nintendo DSi was surpassed by newer and better handhelds many years ago, but that doesn’t stop people like [Nathan Farlow] from attempting to break into the old abandoned house through a rather unexpected place: the (browser) window.

When the Nintendo DSi was released in 2008, one of its notable features was a built-in version of the Opera 9.50 web browser. [Nathan] reasoned an exploit in this browser would be an ideal entry point, as there’s no OS or kernel to get past — once you get execution, you control the system. To put this plan into action, he put together two great ideas. First he used the WebKit layout tests to get the browser into weird edge cases, and then tracked down an Windows build of Opera 9.50 that he could run on his system under WINE. This allowed him to identify the use-after-free bugs that he was looking for.

Now that he had an address to jump to, he just had to get his code into the right spot. For this he employed what’s known as a NOP sled; basically a long list of commands that do nothing, which if jumped into, will slide into his exploit code. In modern browsers a good way to allocate a chunk of memory and fill it would be a Float32Array, but since this is a 2008 browser, a smattering of RGBA canvases will do.

The actual payload is designed to execute a boot.nds file from the SD card, such as a homebrew launcher. If you want to give it a shot on your own DSi, all you need to do is point the system’s browser to stylehax.net.

If you’re looking for a more exotic way to crack into a DSi, perhaps this EM glitching attack might tickle your fancy?

Continue reading “Breaking Into The Nintendo DSi Through The (Browser) Window” →