This Week In Security: In Mudge We Trust, Don’t Trust That App Browser, And Firefox At Pwn2Own

August 26, 2022 by Jonathan Bennett 19 Comments

There’s yet another brouhaha forming over Twitter, but this time around it’s a security researcher making noise instead of an eccentric billionaire. [Peiter Zatko] worked as Twitter’s security chief for just over a year, from November 2020 through January 2022. You may know Zatko better as [Mudge], a renowned security researcher, who literally wrote the book on buffer overflows. He was a member at L0pht Heavy Industries, worked at DARPA and Google, and was brought on at Twitter in response to the July 2020 hack that saw many brand accounts running Bitcoin scans.

Mudge was terminated at Twitter January 2022, and it seems he immediately started putting together a whistleblower complaint. You can access his complaint packet on archive.org, with whistleblower_disclosure.pdf (PDF, and mirror) being the primary document. There are some interesting tidbits in here, like the real answer to how many spam bots are on Twitter: “We don’t really know.” The very public claim that “…<5% of reported mDAU for the quarter are spam accounts” is a bit of a handwave, as the monetizable Daily Active Users count is essentially defined as active accounts that are not bots. Perhaps Mr. Musk has a more legitimate complaint than was previously thought.
Continue reading “This Week In Security: In Mudge We Trust, Don’t Trust That App Browser, And Firefox At Pwn2Own” →

Everything You Didn’t Know You Need To Know About Glitching Attacks

August 25, 2022 by Dan Maloney 1 Comment

If you’ve always been intrigued by the idea of performing hardware attacks but never knew where to start, then we’ve got the article for you: an in-depth look at the hows and whys of hardware glitching.

Attentive readers will recall that we’ve featured [Matthew Alt]’s reverse engineering exploits before, like the time he got root on a Linux-based arcade cabinet. For something a bit more challenging, he chose a Trezor One crypto wallet this time. We briefly covered a high-stakes hack (third item) on one of these wallets by [Joe Grand] a while back, but [Matthew] offers much, much more detail.

After introducing the theory of glitching attacks, which seek to force a processor into an undefined state using various methods, [Matthew] discusses the specifics of the Trezor wallet and how the attack was planned.

His target — the internal voltage regulator of the wallet’s STM32 microcontroller — required desoldering a few caps before the attack could begin, which was performed with a ChipWhisperer. After resolving a few initial timing issues, he was able to glitch the chip into dropping to the lowest level of readout protection, which gave access to the dongle’s SRAM through an ST-Link debugger.

While this summary may make the whole thing sound trivial, it’s obvious that the attack was anything but, nor was the effort that went into writing it all up. The whole thing reads a little like a techno-thriller, and there’s plenty of detail there if you’re looking for a tutorial on chip glitching. We’re looking forward to part 2, which will concentrate on electromagnetic fault-injection using a PicoEMP and what looks like a modified 3D printer.

This Week In Security: Secure Boot Bypass, Attack On Titan M, KASLR Weakness

August 19, 2022 by Jonathan Bennett 9 Comments

It’s debatable just how useful Secure Boot is for end users, but now there’s yet another issue with Secure Boot, or more specifically, a trio of signed bootloaders. Researchers at Eclypsium have identified problems in the Eurosoft, CryptoPro, and New Horizon bootloaders. In the first two cases, a way-too-flexible UEFI shell allows raw memory access. A startup script doesn’t have to be signed, and can easily manipulate the boot process at will. The last issue is in the New Horizon Datasys product, which disables any signature checking for the rest of the boot process — while still reporting that secure boot is enabled. It’s unclear if this requires a config option, or is just totally broken by default.

The real issue is that if malware or an attacker can get write access to the EFI partition, one of these signed bootloaders can be added to the boot chain, along with some nasty payload, and the OS that eventually gets booted still sees Secure Boot enabled. It’s the perfect vehicle for really stealthy infections, similar to CosmicStrand, the malicious firmware we covered a few weeks ago.
Continue reading “This Week In Security: Secure Boot Bypass, Attack On Titan M, KASLR Weakness” →

This Week In Security: Breaches, ÆPIC, SQUIP, And Symbols

August 12, 2022 by Jonathan Bennett 9 Comments

So you may have gotten a Slack password reset prompt. Something like half a percent of Slack’s userbase had their password hash potentially exposed due to an odd bug. When sending shared invitation links, the password hash was sent to other members of the workspace. It’s a bit hard to work out how this exact problem happened, as password hashes shouldn’t ever be sent to users like this. My guess is that other users got a state update packet when the link was created, and a logic error in the code resulted in too much state information being sent.

The evidence suggests that the first person to catch the bug was a researcher who disclosed the problem mid-July. Slack seems to use a sane password policy, only storing hashed, salted passwords. That may sound like a breakfast recipe, but just means that when you type your password in to log in to slack, the password goes through a one-way cryptographic hash, and the results of the hash are stored. Salting is the addition of extra data, to make a precomputation attack impractical. Slack stated that even if this bug was used to capture these hashes, they cannot be used to directly authenticate as an affected user. The normal advice about turning on 2-factor authentication still applies, as an extra guard against misuse of leaked information. Continue reading “This Week In Security: Breaches, ÆPIC, SQUIP, And Symbols” →

Photo of the MCH2022 badge's screen, showing the "Hack me if you can" app's start splashscreen, saying "Service is accessible on IP ADDRESS : 1337"

MCH2022 Badge CTF Solved, With Plenty To Learn From

August 7, 2022 by Arya Voronova 3 Comments

Among all the things you could find at MCH2022, there were a few CTFs (Capture The Flag exercises) – in particular, every badge contained an application that you could try and break into – only two teams have cracked this one! [dojoe] was part of one of them, and he has composed an extensive reverse-engineering story for us – complete with Ghidra disassembly of Xtensa code, remote code execution attempts, ROP gadget creation, and no detail left aside.

There was a catch: badges handed out to the participants didn’t contain the actual flag. You had to develop an exploit using your personal badge that only contained a placeholder flag, then go to the badge tent and apply your exploit over the network to one of the few badges with the real flag on them. The app in question turned out to be an echo server – sending back everything it received; notably, certain messages made it crash. One man’s crashes are another man’s exploit possibilities, and after a few hacking sessions, [dojoe]’s team got their well-deserved place on the scoreboard.

If you always thought that firmware reverse-engineering sounds cool, and you also happen to own a MCH2022 badge, you should try and follow the intricately documented steps of [dojoe]’s writeup. Even for people with little low-level programming experience, repeating this hack is realistic thanks to his extensive explanations, and you will leave with way more reverse-engineering experience than you had before.

The MCH2022 badge is a featureful creation of intricate engineering, with the ESP32 portion only being part of the badge – we’re eager to hear about what you’ve accomplished or are about to accomplish given everything it has to offer!

Here’s How The Precursor Protects Your Privacy

August 6, 2022 by Arya Voronova 14 Comments

At some point, you will find yourself asking – is my device actually running the code I expect it to? [bunnie] aka [Andrew Huang] is passionate about making devices you can fundamentally, deeply trust, and his latest passion project is the Precursor communicator.

At the heart of it is an FPGA, and Precursor’s CPU is created out of the gates of that FPGA. This and a myriad of other design decisions make the Precursor fundamentally hard to backdoor, and you don’t have to take [bunnie]’s word for it — he’s made an entire video going through the architecture, boot protections and guarantees of the Precursor, teaching us what goes into a secure device that’s also practical to use.

If you can’t understand how your device works, your trust in it might be misplaced. In the hour long video, [bunnie] explains the entire stack, from the lower levels of hardware to root keys used to sign and verify the integrity of your OS, along the way demonstrating how you can verify that things haven’t gone wrong.

He makes sure to point out aspects you’d want to be cautious of, from physical security limitations to toolchain nuances. If you’re not up for a video, you can always check out the Precursor wiki, which has a treasure trove of information on the device’s security model.

As you might’ve already learned, it’s not enough for hardware to be open-source in order to be trustworthy. While open-source silicon designs are undoubtedly the future, their security guarantees only go so far.

Whether it’s esoteric hard drive firmware backdoors, weekend projects turning your WiFi card into a keylogger, or rootkits you can get on store-bought Lenovo laptops, hell, even our latest This Week In Security installment has two fun malware examples – there’s never a shortage of parties interested in collecting as much data as possible.

ESP32 Powers Covert Pentesting Device

August 5, 2022 by Tom Nardi 11 Comments

Looking to expand their hardware design experience, [mentalburden] recently put together a low-cost handheld gadget that can be used for various security-related tasks such as logging WiFi traffic, operating as a dead drop, and performing deauthentication attacks.

The custom PCB plays host to the essentials — an ESP32-S microcontroller, AMS1117 3.3 V regulator, a SSD1306 OLED, and a couple of buttons. This lets the user navigate through a simple menu system and select whatever function they wish to enable. During testing, a pair of 18650 cells kept the electronics running for an impressive 22 hours.

A second version of the PCB fixed a few bodges that were required to get the original prototype working, and given how energy efficient the hardware ended up being, [mentalburden] decided to drop the power supply down to a single 18650 for a total runtime of around 15 hours. A 3D printed case and some silicone buttons, produced with a simple clay mold, completed the package.

There’s still some improvements that could be made, namely integrating a battery charging circuit into the PCB and switching over to USB-C, but overall its a solid prototype with an impressive per-unit cost of less than $10 USD. Though if you’re looking for something even cheaper, we’ve seen an even more simplistic approach based on the ESP-01.