Build Your Own Two-Factor Authenticator With Good USB

Two-factor authentication is becoming the norm for many applications and services, and security concerns around phone porting hacks are leading to a phaseout of SMS-based systems. Amidst that backdrop, [Josh] developed his own authentication device by the name of Good USB.

The device can be built using a Arduino Leonardo, SS Micro, or even a BadUSB device. It’s the latter which [Josh] most liked, and since the nefarious device is being repurposed for good, it led to the name Good USB. Basically any Atmega32U4-based device will work, as the key functionality is the ability to emulate a USB keyboard to a host PC.

Using the device is just as simple. With the Good USB plugged in, one simply needs to click a button in the companion app to generate a code for the given account you’re logging in to. Pressing the button on the device then types in the code for you. Alternatively, if your device has no button, it can be set up to simply type the code two seconds after you select an account in the companion app.

The code is on Github for those wishing to make their own. Caveat for the cautious: it’s still a work in progress, and there may be security holes in the current implementation.

If you’re interested in the nuts and bolts of how 2FA works, we’ve looked into that in detail. Video after the break.

Continue reading “Build Your Own Two-Factor Authenticator With Good USB”

Your Building’s RFID Access Tags Might Be Really Insecure

[Gabe Schuyler] had a frustrating problem when it came to getting into his building’s garage. The RFID access system meant he had to remove his gloves while sitting on his motorcycle to fish out the keytag for entry. He decided to whip up a better solution with less fuss.

His initial plan was to duplicate the keytag and to sew one into his gloves. Purchasing a 125 KHz RFID tag duplicator off eBay, he was able to quickly copy the tag, and create one that worked with his garage’s entry system. While the duplicate tags worked well, they were still too big to easily fit into a glove. Attempts to create a duplicate with a smaller tag failed, too. Eventually, [Gabe] turned up a ring complete with a compatible RFID chip, and was able to duplicate his entry tag onto that. Now, by wearing the ring, he can enter his garage and building with a simple wave of the hand, gloves on or off.

Of course, duplicating an RFID tag is no major hack. As per [Gabe]’s Shmoocon talk on the topic, however, it shows that many buildings are using completely insecure RFID access methods with little to no security whatsoever. Anyone that found an access tag lying on the ground could easily replicate as many as they wanted and enter the building unimpeded. It also bears noting that you can snoop RFID cards from further away than you might expect.

This Week In Security: Pacman, Hertzbleed, And The Death Of Internet Explorer

There’s not one, but two side-channel attacks to talk about this week. Up first is Pacman, a bypass for ARM’s Pointer Authentication Code. PAC is a protection built into certain ARM Processors, where a cryptographic hash value must be set correctly when pointers are updated. If the hash is not set correctly, the program simply crashes. The idea is that most exploits use pointer manipulation to achieve code execution, and correctly setting the PAC requires an explicit instruction call. The PAC is actually indicated in the unused bits of the pointer itself. The AArch64 architecture uses 64-bit values for addressing, but the address space is much less than 64-bit, usually 53 bits or less. This leaves 11 bits for the PAC value. Keep in mind that the application doesn’t hold the keys and doesn’t calculate this value. 11 bits may not seem like enough to make this secure, but keep in mind that every failed attempt crashes the program, and every application restart regenerate the keys.

What Pacman introduces is an oracle, which is a method to gain insight on data the attacker shouldn’t be able to see. In this case, the oracle works via speculation attacks, very similar to Meltdown and Spectre. The key is to attempt a protected pointer dereference speculatively, and to then observe the change in system state as a result. What you may notice is that this requires an attack to already be running code on the target system, in order to run the PAC oracle technique. Pacman is not a Remote Code Execution flaw, nor is it useful in gaining RCE.

One more important note is that an application has to have PAC support compiled in, in order to benefit from this protection. The platform that has made wide use of PAC is MacOS, as it’s a feature baked in to their M1 processor. The attack chain would likely start with a remote execution bug in an application missing PAC support. Once a foothold is established in uprivileged userspace, Pacman would be used as part of an exploit against the kernel. See the PDF paper for all the details.

Continue reading “This Week In Security: Pacman, Hertzbleed, And The Death Of Internet Explorer”

This Week In Security: For The Horde, Feature Not A Bug, And Confluence

If you roll way back through the history of open source webmail projects, you’ll find Horde, a groupware web application. First released in 1998 on Freshmeat, it gained some notoriety in early 2012 when it was discovered that the 3.0 release had been tampered with, and packages containing a backdoor had been shipped for three months. While this time around it isn’t an intentional backdoor, there is a very serious problem in the Horde webmail interface. Or more accurately, a pair of problems. The most serious is CVE-2022-30287, an RCE bug allowing an authenticated user to trigger code execution on the connected server.

The vulnerable element is the Turba address book module, which uses a PHP factory method to access a specific address book. The create() method has an interesting bit of code, that first checks the initialization value. If it’s a string, that value is understood as the name of the local address book to access. However, if the factory is initialized with an array, any of the address book drivers can be used, including the IMSP driver. IMSP fetches serialized data from remote servers, and deserializes it. And yes, PHP can have deserialization bugs, and this one runs code on the host.

But it’s not that bad, it’s only authenticated users, right? That would be bad enough, but that second bug is a Cross-site Request Forgery, CSRF, triggered by viewing an email. So on a vulnerable Horde server, any user viewing a malicious message would trigger RCE on the server. Oof. So let’s talk fixes. There is a new version of the Turba module that seems to fix the bugs, but it’s not clear that the actual Horde suite has pushed an update that includes it. So you may be on your own. As is pointed out on the Sonar Blog where the vulnerability was discovered, Horde itself seems to be essentially unmaintained at this point. Maybe time to consider migrating to a newer platform.
Continue reading “This Week In Security: For The Horde, Feature Not A Bug, And Confluence”

A Secure Phone Fit For A Prime Minister

The curtain of state secrecy which surrounds the type of government agency known primarily by initialisms is all-encompassing and long-lived, meaning that tech that is otherwise in the public domain remains top secret for many decades. Thus it’s fascinating when from time to time the skirts are lifted to reveal a glimpse of ankle, as has evidently been the case for a BBC piece dealing with the encrypted phones produced by GCHQ and used by Margaret Thatcher in the early 1980s. Sadly, it’s long on human interest and short on in-depth technology, but nevertheless from it can be deduced enough to work out how it most likely worked.

We’re told that it worked over a standard phone line and transmitted at 2.4 kilobytes per second, a digital data stream encoded using a paper tape key that was changed daily. If we were presented with this design spec to implement in a briefcase using 1980s components, we’d probably make an ADPCM (Adaptive Differential Pulse Code Modulation) system with an XOR encryption against the key, something we think would be well within the capabilities of early 1980s digital logic and microprocessors. We’re wondering whether the BBC have made a typo and that  should be kilobits rather than kilobytes to work on a standard phone line.

No doubt there are people in the comments who could tell us if they were willing to break the Official Secrets Act, but we’d suggest they don’t risk their liberty by doing so. It’s worth noting though, that GCHQ have been known to show off some of their past glories, as in this 2019 exhibition at London’s Science Museum.

A light blue marker with a two-pin header replacing the tip, being pressed against the back of the keypad baord that's removed from the safe

Anyone Can Be The Master Of This Master Lock Safe

[Etienne Sellan] got one of these lovely $5 logic analyzers. As with any shiny new tool, he started looking for things to investigate with it, and his gaze fell on a Sentry Safe (produced by Master Lock). On the surface level, this keypad-equipped safe is designed decently when it comes to privilege separation. You can take the keypad board off and access its backside, but the keypad doesn’t make any decisions, it merely sends the digits to a different board embedded behind the safe’s door. The solenoid-connected board receives the PIN, verifies it, and then controls the solenoid that unlocks the safe.

[Etienne] hooked up a logic analyzer to the communication wire, which turned out to be a UART channel, and logged the keypad communication packets — both for password entry and for password change. Then, he wrote some Arduino code to send the same packets manually, which worked wonders. Bruteforcing wasn’t viable, however, due to rate limitation in the solenoid controller. Something drew his attention from there – if you want to change the password, the keypad requires you enter the factory code, unique to each safe and supplied in the instruction manual. That code entry is a separate kind of packet from the “change password” one.

More after the break…

Continue reading “Anyone Can Be The Master Of This Master Lock Safe”

This Week In Security: Follina, Open Redirect RCE, And Annoyware

Depending on who you ask, there’s either 2 vulnerabilities at play in Follina, only one, or according to Microsoft a week ago, no security problem whatsoever. On the 27th of last month, a .docx file was uploaded to VirusTotal, and most of the tools there thought it was perfectly normal. That didn’t seem right to [@nao_sec], who raised the alarm on Twitter. It seems this suspicious file originated somewhere in Belarus, and it uses a series of tricks to run a malicious PowerShell script.
Continue reading “This Week In Security: Follina, Open Redirect RCE, And Annoyware”