Self-Destructing USB Drive Releases The Magic Smoke

March 1, 2023 by Tom Nardi 52 Comments

There were some that doubted the day would ever come, but we’re happy to report that the ambitious self-destructing USB drive that security researcher [Walker] has been working on for the last 6+ months has finally stopped working. Which in this case, is a good thing.

Readers may recall that the goal of the Ovrdrive project was to create a standard-looking flash drive that didn’t just hide or erase its contents when accessed by an unauthorized user, but actively damaged itself to try and prevent any forensic recovery of the data in question. To achieve this, [Walker] built a voltage doubler circuit into the drive that produces 10 volts from the nominal 5 VDC coming from the USB port. At the command of an onboard microcontroller, that 10 V is connected to the circuit’s 3.3 V rail to set off the fireworks.

Early attempts only corrupted some of the data, so [Walker] added some more capacitance to the circuit to build up more of a charge. With the revised circuit the USB controller IC visibly popped, but even after it was replaced, the NAND flash was still unresponsive. Sounds pretty dead to us.

Unfortunately, there’s still at least one issue that’s holding back the design. As we mentioned previously, [Walker] was having trouble getting the computer to actually acknowledge his homebrew drive had any free space available. It turns out that the SM3257EN USB controller IC he’s using needs to be initialized by some poorly documented Windows XP software, which might not be such a big deal if the goal was just to build one of them, but could obviously be a hindrance when going into production.

He hopes further reverse engineering will allow him to determine which commands the XP software is giving to the IC so that he can duplicate them in a less ancient environment. Sounds like a job for Wireshark to us — with any luck he should be able to capture the commands being sent to the hardware and replay them.

While we can understand some readers may have lingering doubts about the drive’s spit-detection authentication system, it’s clear [Walker] has made some incredible progress here. This project demonstrates that not only can an individual spin up their own sold state storage, but that should they ever need to, they can also destroy it in an instant.

A picture showing acupuncture needles wedged into the inside of the payment terminal

Aaron Christophel Brings DOOM To Payment Terminal

March 1, 2023 by Arya Voronova 9 Comments

Payment terminals might feel intimidating — they’re generally manufactured with security in mind, with all manner of anti-tamper protections in place to prevent you from poking around in the hardware too much. But [Aaron Christophel] thinks that level of security isn’t aren’t always in practice however, and on his journey towards repurposing devices of all kinds, has stumbled upon just the terminal that will give up its secrets easily. The device in question is Sumup Solo terminal, a small handheld with a battery, LTE connection and a payment card slot – helping you accept card payments even if you’re on the go.

Now, this terminal has security features like the anti-tamper shield over the crucial parts of the device, leading to payment processing-related keys being erased when lifted. However, acupuncture needles, a tool firmly in [Aaron]’s arsenal, helped him reach two UART testpoints that were meant to be located under that shield, and they turned out to be all that a hacker needed to access the Linux system powering this terminal. Not just that, but the UART drops you right into the root shell, which [Aaron] dutifully explored — and after some cross–compilation and Linux tinkering, he got the terminal to, naturally, run Doom.

The video shows you even more, including the responsible disclosure process that he went through with Sumup, resulting in some patches and, we hope, even hardware improvements down the line. Now, the payment processing keys aren’t accessible from the Linux environment — however, [Aaron] notes that this doesn’t exclude attacks like changing the amount of money displayed while the customer is using such a terminal to pay.

If you’d like to take a closer look at some of the hardware tricks used in these secure devices, we did a teardown on one back in 2019 that should prove interesting.

Continue reading “Aaron Christophel Brings DOOM To Payment Terminal” →

This Week In Security: GoDaddy, Joomla, And ClamAV

February 24, 2023 by Jonathan Bennett 1 Comment

We’ve seen some rough security fails over the years, and GoDaddy’s recent news about a breach leading to rogue website redirects might make the highlight reel. The real juicy part is buried on page 30 of a PDF filing to the SEC.

Based on our investigation, we believe these incidents are part of a multi-year campaign by a sophisticated threat actor group that, among other things, installed malware on our systems and obtained pieces of code related to some services within GoDaddy.

That multi-year campaign appears to goes back to at least October 2019, when an SSH file was accessed and altered, leading to 28,000 customer SSH usernames and passwords being exposed. There was also a 2021 breach of the GoDaddy WordPress environment, that has been linked to the same group.

Reading between the lines, there may be an implication here that the attackers had an ongoing presence in GoDaddy’s internal network for that entire multi-year period — note that the quote above refers to a single campaign, and not multiple campaigns from the same actor. That would be decidedly bad.

Joomla’s Force Persuasion

Joomla has a critical vulnerability, CVE-2023-23752, which is a trivial information leak from a web endpoint. This flaw is present in all of the 4.x releases, up to 4.2.8, which contains the fix. The issue is the Rest API, which gives access to pretty much everything about a given site. It has an authentication component, of course. The bypass is to simply append ?public=true. Yes, it’s a good old “You don’t need to see his identification” force suggestion.

There’s even a PoC script that runs the request and spits out the most interesting data: the username, password, and user id contained in the data. It’s not quite as disastrous as that sounds — the API isn’t actually leaking the administrative username and password, or even password hash. It’s leaking the SQL database information. Though if your database is accessible from the Internet, then that’s pretty much as bad as it could be. Continue reading “This Week In Security: GoDaddy, Joomla, And ClamAV” →

A pair of PCBs with OLED character displays, showing a simple encryption program

The CryptMaster 2001 Provides Basic Lessons In Cryptography

February 13, 2023 by Robin Kearey 6 Comments

Sending secret messages to your friends is fun, but today it’s so simple that you don’t even notice it anymore: practically any serious messaging system features encryption of some sort. To teach his kids about cryptography, [Michal Zalewski] therefore decided to bring the topic to life by building a handheld encryption system, called the CryptMaster 2001.

The system consists of an identical pair of hand-held devices built on prototype PCBs. A standard 16×2 character OLED display is used as an output device, which generates the ciphertext in real time as the plaintext is entered character by character through a rotary encoder. An ATmega328P manages the input and output routines and performs the encryption.

For ease of use, [Michal] wanted to use a reciprocal cipher, meaning one that uses the same operation for encryption and decryption. Trivial ciphers like ROT13 would be a bit too easy to crack, so he devised a slightly more complex system where each character in the input is encoded using a separate rearranged alphabet – a basic polyalphabetic substitution cipher.

[Michal]’s kids apparently had some good fun with the CryptMaster 2001, until his eldest son managed to reverse-engineer the encryption method, enabling him to decode messages without having access to one of the devices. This made the project a pretty decent lesson about the limits of basic cryptography: simply swapping letters doesn’t present a real challenge to anyone. Luckily, much more secure methods are available, even if you’re only using pen and paper.

A Look Back At The Xbox 360’s Hard Drive Security

February 11, 2023 by Tom Nardi 31 Comments

Anyone who’s owned a game console from the last couple of generations will tell you that the machines are becoming increasingly like set-top computers — equipped with USB ports, Bluetooth, removable hard drives, and their own online software repositories. But while this overlap theoretically offers considerable benefits, such as the ability to use your own USB controller rather than being stuck with the system’s default, the manufacturers haven’t always been so accommodating.

Take for example the removable hard drive of the Xbox 360. It was a bog standard 2.5″ SATA drive inside a fancy enclosure, but as explained by [Eaton], Microsoft went to considerable lengths to prevent the user from upgrading it themselves. Which wouldn’t have been such a big deal, if the Redmond giant wasn’t putting a huge markup on the things; even in 2005, $99 USD for 20 GBs was highway robbery. Continue reading “A Look Back At The Xbox 360’s Hard Drive Security” →

This Week In Security: ImageMagick, VBulletin, And Dota 2

February 10, 2023 by Jonathan Bennett 3 Comments

There are a few binaries that wind up running in a bunch of places, silently do their jobs, and being easily forgotten about. ImageMagick is used on many servers for image conversion and resizing, and tends to run automatically on uploaded images. Easily forgotten, runs automatically, and with arbitrary inputs. Yep, perfect target for vulnerability hunting. And the good folks at Metabase found two of them.

First up is CVE-2022-44267, a Denial of Service, when ImageMagick tries to process a rigged PNG that contains a textual chunk. This data type is usually used for metadata, and can include a profile entry for something like EXIF data. If this tag is specified inside a text chunk, ImageMagick looks to the given value as a filename for finding that profile data. And notably, if that value is a dash -, it tries to read from standard input. If the server’s image processing flow doesn’t account for that quirk, and virtually none of them likely do, this means the ImageMagick process hangs forever, waiting for the end of input. So while that’s not usually a critical problem, it could be used for a resource exhaustion attack.

But the real problem is CVE-2022-44268. It’s the same trick, but instead of using - to indicate standard input, the processed image refers to a file on the server filesystem. If the file exists, and can be read, the contents are included in the image output. If the attacker has access to the image, it’s a slick data leak — and obviously a real security problem. If a server doesn’t have tight file permissions and isolation, there’s plenty of sensitive information to be found and abused.

The fix landed back in October 2022, and was part of the 7.1.0-52 release. There’s a bit of uncertainty about which versions are vulnerable, but I wouldn’t trust anything older than that version. It’s a pretty straightforward flaw to understand and exploit, so there’s a decent chance somebody figured it out before now. The file exfiltration attack is the one to watch out for. It looks like there’s an Indicator of Compromise (IoC) for those output PNGs: “Raw profile type”. Continue reading “This Week In Security: ImageMagick, VBulletin, And Dota 2” →

Dumping script window, showing the bytes being dumped one by one from the STM chip

Need To Dump A Protected STM32F0x? Use Your Pico!

February 5, 2023 by Arya Voronova 21 Comments

Sometimes, security mechanisms can be bypassed if you just do things slightly out of the ordinary. For instance, readout protection on microcontrollers is a given nowadays, to the point where it’s intentionally enabled and relied upon as a major technical measure to protect intellectual property. The gist is — when you connect to a microcontroller over its debug interface and then ask to read its flash memory, it will politely refuse. However, [Racerxdl] shows us that in practice, it’s not flawless protection – for certain chips, you just need to be a little quicker than usual.

Usually, flashing and debugging software will chat with the microcontroller for a bit, and probe parameters before going for any direct requests. However, if you skip the courtesy and bluntly get to the point immediately right after power is applied to the microcontroller, you can intimidate them just enough to give you one byte of its memory before it refuses to cooperate further. Since that can be any byte you wish, you can read the entire flash — one byte at a time.

You need to power cycle the chip before you can progress, so the hardware does involve a bit more than just an SWD interface, and it will take a fair bit more time than reading out a non-protected chip the usual way; plus, of course, the debugging interface needs to be active for this in the first place, which isn’t always the case. However, it still beats paying a few thousand dollars for a factory in China to decap your chip and read it out using a fancy machine.

[Racerxdl] didn’t just write a proof-of-concept for this attack – they implemented it for one of our favourite chips, the RP2040. As such, you no longer need an unobtainium STM32 to dump an unobtainium STM32.

To be clear, [Racerxdl] didn’t design this attack — it’s been around for some time now. Credit for that goes to Johanes Obermaier. All in all, this is a wonderful reminder that seemingly reliable security mechanisms can be foiled by the simplest tricks. For instance, if your chip erases the flash when you unlock its protection, you can just tell it not to.