STM32 Blue Pill Turned GPG Security Token

June 10, 2020 by Tom Nardi 30 Comments

Feeling the cost of commercial options like the YubiKey and Nitrokey were too high, [TheStaticTurtle] started researching DIY alternatives. He found an open source project allows the STM32F103 to act as a USB cryptographic token for GNU Privacy Guard, which was a start. All he had to do was build a suitable device to install it on.

The first step was to test the software out on the popular “Blue Pill” development board, which [TheStaticTurtle] documents in the write-up should anyone want to give it a try themselves. The ST-Link V2 was already a supported target, so it only took some relatively minor tweaks to get running and add support for a simple push button. The output of gpg --card-status showed the device was working as expected, so with the software sorted, it was time to take a closer look at the hardware.

To create his “TurtleAuth” dongle, [TheStaticTurtle] started with the basic layout of the Blue Pill and added in a TTP223E touch control IC. The original Micro USB port was also swapped for a male USB-A connector so the device could be plugged directly into a computer. An upper PCB, containing the status LEDs and touch pad, was then designed so it would fit over the main board as an enclosure of sorts. While the sides are still open, the device looks robust enough to handle life in a laptop bag at least.

While it’s not exactly a common project, this isn’t the first time we’ve seen somebody spin up their own hardware token. More evidence of what the dedicated individual can accomplish these days on a relatively limited budget.

This Week In Security: Exim, Apple Sign-in, Cursed Wallpaper, And Nuclear Secrets

June 5, 2020 by Jonathan Bennett 9 Comments

So first off, remember the Unc0ver vulnerability/jailbreak from last week? In the 13.5.1 iOS release, the underlying flaw was fixed, closing the jailbreak. If you intend to jailbreak your iOS device, make sure not to install this update. That said, the normal warning applies: Be very careful about running out-of-date software.

Apple Sign In

An exploit in Apple’s web authentication protocol was fixed in the past week . Sign In With Apple is similar to OAuth, and allows using an Apple account to sign in to other sites and services. Under the hood, a JSON Web Token (JWT) gets generated and passed around, in order to confirm the user’s identity. In theory, this scheme even allows authentication without disclosing the user’s email address.

So what could go wrong? Apparently a simple request for a JWT that’s signed with Apple’s public key will automatically be approved. Yeah, it was that bad. Any account linked to an Apple ID could be trivially compromised. It was fixed this past week, after being found and reported by [Bhavuk Jain]. Continue reading “This Week In Security: Exim, Apple Sign-in, Cursed Wallpaper, And Nuclear Secrets” →

This Week In Security: Leaking Partial Bits, Apple News, And Overzealous Contact Tracing

May 29, 2020 by Jonathan Bennett 11 Comments

Researchers at the NCCGroup have been working on a 5-part explanation of a Windows kernel vulnerability, targeting the Kernel Transaction Manager (KTM). The vulnerability, CVE-2018-8611, is a local privilege escalation bug. There doesn’t seem to be a way to exploit this remotely, but it is an interesting bug, and NCCGroup’s work on it is outstanding.

They start with a bit of background on what the KTM is, and why one might want to use it. Next is a handy guide to reverse engineering Microsoft patches. From there, they describe the race condition and how to actually exploit it. They cover a wide swath in the series, so go check it out.

Left4Dead 2

Just a reminder that bugs show up where you least expect them, [Hunter Stanton] shares his story of finding a code execution bug in the popular Valve game, Left4Dead 2. Since the game’s code isn’t available to look at, he decided to go the route of fuzzing. The specific approach he took was to fuzz the navigation mesh data, part of the data contained in each game map. Letting the Basic Fuzzing Framework (BFF) run for three days turned up a few possible crashes, and the most promising turned out to have code execution potential. [Hunter] submitted the find through Valve’s HackerOne bug bounty program, and landed a cool $10k bounty for his trouble.

While it isn’t directly an RCE, [Hunter] does point out that malicious mesh data could be distributed with downloadable maps on the Steam workshop. Alternatively, it should be possible to set up a fake game server that distributes the trapped map. Continue reading “This Week In Security: Leaking Partial Bits, Apple News, And Overzealous Contact Tracing” →

Home Assistant Get Fingerprint Scanning

May 28, 2020 by Al Williams 13 Comments

Biometrics — like using your fingerprint as a password — is certainly convenient and are pretty commonplace on phones and laptops these days. While their overall security could be a problem, they certainly fit the bill to keep casual intruders out of your system. [Lewis Barclay] had some sensors gathering dust and decided to interface them to his Home Assistant setup using an ESP chip and MQTT.

You can see the device working in the video below. The code is on GitHub, and the only thing we worried about was the overall security. Of course, the security of fingerprint scanners is debatable since you hear stories about people lifting fingerprints with tape and glue, but even beyond that, if you were on the network, it would seem like you could sniff and fake fingerprint messages via MQTT. Depending on your security goals, that might not be a big deal and, of course, that assumes someone could compromise your network to start with.

Continue reading “Home Assistant Get Fingerprint Scanning” →

Hiding Malware, With Windows XP

May 22, 2020 by Jenny List 20 Comments

In the nearly four decades since the first PC viruses spread in the wild, malware writers have evolved some exceptionally clever ways to hide their creations from system administrators and from anti-virus writers. The researchers at Sophos have found one that conceals itself as probably the ultimate Trojan horse: it hides its tiny payload in a Windows XP installation.

The crusty Windows version is packaged up with a copy of an older version of the VirtualBox hypervisor on which to run it. A WIndows exploit allows Microsoft Installer to download the whole thing as a 122 MB installer package that hides the hypervisor and a 282 MB disk image containing Windows XP. The Ragnar Locker ransomware payload is a tiny 49 kB component of the XP image, which the infected host will run on the hypervisor unchallenged.

The Sophos analysis has a fascinating delve into some of the Windows batch file tricks it uses to probe its environment and set up the connections between host and XP, leaving us amazed at the unorthodox use of a complete Microsoft OS and that seemingly we have reached a point of system bloat at which such a large unauthorised download and the running of a complete Microsoft operating system albeit one from twenty years ago in a hypervisor can go unnoticed. Still, unlike some malware stories we’ve seen, at least this one is real.

This Week In Security: DNS DDOS, Revenge Of The 15 Year Old Bug, And More

May 22, 2020 by Jonathan Bennett 9 Comments

Another DDOS amplification technique has just recently been disclosed, NXNSAttack (technical paper here) that could be used against DNS servers.

We’ve covered amplification attacks before. The short explanation is that some UDP services, like DNS, can be abused to get more mileage out of a DDoS attack. The attacking machined send messages like this: “Hello Google DNS, This is the Hackaday server. Can you send me a really big DNS response packet?” If the DNS response is bigger than the request, then the overall attack is bigger as a result. The measure of effectiveness is the amplification factor. For every byte of DDoS sent by attacking machines, how much many bytes are actually sent to the victim machine? Mirai, for example, had an amplification factor of something around 2.6.

NXNSAttack has a theoretical per-byte amplification factor of 163. That’s not a missed decimal point, this has the potential to be quite the nasty problem. Continue reading “This Week In Security: DNS DDOS, Revenge Of The 15 Year Old Bug, And More” →

All Your Passwords Are Belong To FPGA

May 15, 2020 by Tom Nardi 26 Comments

When used for cracking passwords, a modern high-end graphics card will absolutely chew through “classic” hashing algorithms like SHA-1 and SHA-2. When a single desktop machine can run through 50+ billion password combinations per second, even decent passwords can be guessed in a worryingly short amount of time. Luckily, advanced password hashing functions such as bcrypt are designed specifically to make these sort of brute-force attacks impractically slow.

Cracking bcrypt on desktop hardware might be out of the question, but the folks over at [Scattered Secrets] had a hunch that an array of FPGAs might be up to the task. While the clock speed on these programmable chips might seem low compared to a modern CPUs and GPUs, they don’t have all that burdensome overhead to contend with. This makes the dedicated circuitry in the FPGA many times more efficient at performing the same task. Using a decade-old FPGA board intended for mining cryptocurrency, the team was able to demonstrate a four-fold performance improvement over the latest generation of GPUs.

After seeing what a single quad FPGA board was capable of, the [Scattered Secrets] team started scaling the concept up. The first version of the hardware crammed a dozen of the ZTEX FPGA boards and a master control computer computer into a standard 4U server case. For the second version, they bumped that up to 18 boards for a total of 72 FPGAs, and made incremental improvements to the power and connectivity systems.

Each 4U FPGA cracker is capable of 2.1 million bcrypt hashes per second, while consuming just 585 watts. To put that into perspective, [Scattered Secrets] says you’d need at least 75 Nvidia RTX-2080Ti graphics cards to match that performance. Such an array would not only take up a whole server rack, but would burn through a staggering 25 kilowatts. Now might be a good time to change your password to something longer, or finally get onboard with 2FA.

We’ve covered attempts to reverse engineer hardware designed for cryptocurrency mining, but those were based around application-specific integrated circuits (ASICs) which by definition are very difficult to repurpose. On the other hand, disused FPGA-based miners offer tantalizing possibilities; once you wrap your mind around how they work, anyway.

[Thanks to Piejoe for the tip.]