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.

This Week In Security: Github, Google, And Realtek

February 3, 2023 by Jonathan Bennett 4 Comments

GitHub Desktop may have stopped working for you yesterday, Febuary 2nd. The reason was an unauthorized access to some decidedly non-public repositories. The most serious bit of information that escaped was code signing certificates, notably used for GitHub Desktop and Atom. Those certificates were password protected, so it’s unlikely they’ve been abused yet. Even so, Github is taking the proper steps of revoking those certificates.

The only active certificate that was revoked was used for signing the Mac releases of GitHub Desktop, so quite a few older versions of that software is no longer easily installed. If nothing else, it’s a reminder that even a project with a well run security team can have problems.

Sh1mmer-ing Chromebooks

There’s a new, clever attack on the Chromebook, specifically with the goal of unenrolling the device from an educational organization. And the “vulnerability” is a documented feature, the RMA Shim. That’s a special boot loader target that contains a valid signature, but allows the booting of other code, intended for troubleshooting and fixing devices in a repair center. Quite a few of those images have leaked, and Sh1mmer combines the appropriate image with a boot menu with some interesting options.

The first is unenrolling, so the device will act like a privately owned computer. This gets rid of content blocks and allows removing extensions. But wait, there’s more. Like rooting the device, a raw Bash terminal, and re-enabling developer mode. Now, as far as we can tell, this doesn’t *directly* break device encryption, but it’s likely that the RMA shim could be abused to tamper with the device’s filesystem. Meaning that the leak of a bunch of signed shims is a big problem for device security. If you use a Chromebook, it might be time to do some research on whether that model’s shim has been leaked. Continue reading “This Week In Security: Github, Google, And Realtek” →

A modchip described in the article - a small PCB with an epoxy blob on it, soldered to the Cisco switch PCB using four thin wires

Counterfeit Cisco Hardware Bypasses Security Checks With Modchips

February 1, 2023 by Arya Voronova 32 Comments

Some pictures recently surfaced on social media, showing a small PCB tapped into four points on Cisco-branded boards. What is this about? A NSA backdoor so data can be exfiltrated to some third party? Well, that’s theoretically possible, but it’s actually used for bypassing hardware authenticity checks in Cisco hardware being cloned — a sizable industry. Of course, “can’t believe it’s not Cisco” hardware is only valuable insofar that it’s able to run the Cisco software, and that’s where the bodge boards play a major role.

A 2020 report by F-Secure details an investigation, comparing three switches marked as Cisco 2960X – one known genuine and two known counterfeits. The counterfeits had the aforementioned implants either soldered to the bottom of the PCB or added to the board as a separate component, and the paper goes into why they’re important for successful counterfeiting.

Apparently, these chips emulate or bypass an I2C EEPROM containing part of the code executed during the boot sequence, and Cisco depends on this EEPROM’s contents for authenticity verification. Cisco software reads the EEPROM twice — once for verification, and once again for actually running it. The microcontroller included on the mod board can return a genuine binary with a valid signature on the first read, and a binary with hardware checks patched out for subsequent reads.

The paper will tell you about way more than this — it’s thorough yet captivating. As you’d expect, it devotes quite a bit of time to comparing genuine and counterfeit boards, showing that the cloning process is pretty to-the-T, save for some part substitutions. For instance, check out the PDF page 12 to see how via locations are exactly copied between PCBs in a bizarre way, or the Cisco file format and authenticity check analysis closer to the end of the report. All in all, the 38 pages of the document make for a fun foray into what makes Cisco authentication mechanisms tick, and what helps clone hardware makers bypass them.

Are such chips ever used for adding backdoors and data exfiltration? There’s no evidence of that, as much as that’s not to be excluded — bypassing anti-cloning protections would make other hijinks more viable no doubt, that said, only hardware authentication bypass measures were found so far. This mechanism also breaks during software updates, and absolutely, leaves some to be desired when it comes to its stated functionality. That said, such fun insights can help us, say, enforce right-to-repair, enable hardware reuse, and thwart many predatory business practices in areas where laws fail us.

Opening A Safe With A Stepper Motor And DIY Auto-Dialer

January 29, 2023 by Maya Posch 24 Comments

What do you do when you happen to come into possession of a safe of which the combination is lost to the sands of time? If you’re someone like [eNBeWe], you grab a stepper motor with driver module you had lying around gathering dust, an ESP8266 for the brains and a few other pieces to build your very own auto-dialer to crack that safe combination. The software has been made available on GitHub for those interested.

While other auto-dialers used with the fun hobby of safe cracking can generally find the combination in a matter of hours if not less, it took [eNBeWe]’s contraption two days to crack the combination. Much of this was due to the hacked together nature of the structure, with the glue joints among other weak points that’d probably not take too kindly to a lot of abuse. Since there was no particular rush to get into the safe, this worked out fine.

As an impromptu auto-dialer thrown together with parts that were lying around it seemed to perform just fine for the task, and we presume that this is the beginning of a beautiful new lock- and safe-picking hobby.

Continue reading “Opening A Safe With A Stepper Motor And DIY Auto-Dialer” →