Front Door Keys Hidden In Plain Sight

If there’s one thing about managing a bunch of keys, whether they’re for RSA, SSH, or a car, it’s that large amounts of them can be a hassle. In fact, anything that makes life even a little bit simpler is a concept we often see projects built on to of, and keys are no different. This project, for example, eliminates the need to consciously carry a house key around by hiding it in a piece of jewelry.

This project sprang from [Maxime]’s previous project, which allowed the front door to be unlocked with a smartphone or tablet. This isn’t much better than carrying a key, since the valuable piece of electronics must be toted along in place of one. Instead, this build eschews the smartphone for a ring which can be worn and used to unlock the door with the wave of a hand. The ring contains an RFID which is read by an antenna that’s monitored by a Wemos D1 Mini. When it sees the ring, a set of servos unlocks the door.

The entire device is mounted on the front of the door about where a peephole would normally be, with the mechanical actuators on the inside. It seems just as secure (if not more so) than carrying around a metal key, and we also appreciate the aesthetic of circuit boards shown off in this way, rather than hidden inside an enclosure. It’s an interesting build that reminds us of some other unique ways of unlocking a door.

Continue reading “Front Door Keys Hidden In Plain Sight”

What’s Old Is New Again: GPT-3 Prompt Injection Attack Affects AI

What do SQL injection attacks have in common with the nuances of GPT-3 prompting? More than one might think, it turns out.

Many security exploits hinge on getting user-supplied data incorrectly treated as instruction. With that in mind, read on to see [Simon Willison] explain how GPT-3 — a natural-language AI —  can be made to act incorrectly via what he’s calling prompt injection attacks.

This all started with a fascinating tweet from [Riley Goodside] demonstrating the ability to exploit GPT-3 prompts with malicious instructions that order the model to behave differently than one would expect.

Continue reading “What’s Old Is New Again: GPT-3 Prompt Injection Attack Affects AI”

USB Drive Keeps Your Secrets… As Long As Your Fingers Are Wet?

[Walker] has a very interesting new project: a completely different take on a self-destructing USB drive. Instead of relying on encryption or other “visible” security features, this device looks and works like an utterly normal USB drive. The only difference is this: if an unauthorized person plugs it in, there’s no data. What separates authorized access from unauthorized? Wet fingers.

It sounds weird, but let’s walk through the thinking behind the concept. First, encryption is of course the technologically sound and correct solution to data security. But in some environments, the mere presence of encryption technology can be considered incriminating. In such environments, it is better for the drive to appear completely normal.

Toggling the chip enable (CE) pin will hide the drive’s contents.

The second part is the access control; the “wet fingers” part. [Walker] plans to have hidden electrodes surreptitiously measure the resistance of a user’s finger when it’s being plugged in. He says a dry finger should be around 1.5 MΩ, but wet fingers are more like 500 kΩ.

But why detect a wet finger as part of access control? Well, what’s something no normal person would do right before plugging in a USB drive? Lick their finger. And what’s something a microcontroller should be able to detect easily without a lot of extra parts? A freshly-licked finger.

Of course, detecting wet skin is only half the equation. You still need to implement a USB Mass Storage device, and that’s where things get particularly interesting. Even if you aren’t into the covert aspect of this device, the research [Walker] has done into USB storage controllers and flash chips, combined with the KiCad footprints he’s already put together means this open source project will be a great example for anyone looking to roll their own USB flash drives.

Regular readers may recall that [Walker] was previously working on a very impressive Linux “wall wart” intended for penetration testers, but the chip shortage has put that ambitious project on hold for the time being. As this build looks to utilize less exotic components, hopefully it can avoid a similar fate.

McTerminals Give The Hamburglar A Chance

The golden arches of a McDonald’s restaurant are a ubiquitous feature of life in so many parts of the world, and while their food might not be to all tastes their comforting familiarity draws in many a weary traveler. There was a time when buying a burger meant a conversation with a spotty teen behind the till, but now the transaction is more likely to take place at a terminal with a large touch screen. These terminals have caught the attention of [Geoff Huntley], who has written about their surprising level of vulnerability.

When you’re ordering your Big Mac and fries, you’re in reality standing in front of a Windows PC, and repeated observation of start-up reveals that the ordering application runs under an administrator account. The machine has a card reader and a receipt printer, and it’s because of this printer that the vulnerability starts. In a high-traffic restaurant the paper rolls often run out, and the overworked staff often leave the cabinets unlocked to facilitate access. Thus an attacker need only gain access to the machine to reset it and they can be in front of a touch screen with administrator access during boot, and from that start they can do anything. Given that these machines handle thousands of card transactions daily, the prospect of a skimming attack becomes very real.

The fault here lies in whoever designed these machines for McDonalds, instead of putting appropriate security on the software the whole show relies on the security of the lock. We hope that they don’t come down on the kids changing the paper, and instead get their software fixed. Meanwhile this isn’t the first time we’ve peered into some McHardware.

Why You Should Totally Roll Your Own AES Cryptography

Software developers are usually told to ‘never write your own cryptography’, and there definitely are sufficient examples to be found in the past decades of cases where DIY crypto routines caused real damage. This is also the introduction to [Francis Stokes]’s article on rolling your own crypto system. Even if you understand the mathematics behind a cryptographic system like AES (symmetric encryption), assumptions made by your code, along with side-channel and many other types of attacks, can nullify your efforts.

So then why write an article on doing exactly what you’re told not to do? This is contained in the often forgotten addendum to ‘don’t roll your own crypto’, which is ‘for anything important’. [Francis]’s tutorial on how to implement AES is incredibly informative as an introduction to symmetric key cryptography for software developers, and demonstrates a number of obvious weaknesses users of an AES library may not be aware of.

This then shows the reason why any developer who uses cryptography in some fashion for anything should absolutely roll their own crypto: to take a peek inside what is usually a library’s black box, and to better understand how the mathematical principles behind AES are translated into a real-world system. Additionally it may be very instructive if your goal is to become a security researcher whose day job is to find the flaws in these systems.

Essentially: definitely do try this at home, just keep your DIY crypto away from production servers :)

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.

Hackaday Links Column Banner

Hackaday Links: June 12, 2022

“Don’t worry, that’ll buff right out.” Alarming news this week as the James Webb Space Telescope team announced that a meteoroid had hit the space observatory’s massive primary mirror. While far from unexpected, the strike on mirror segment C3 (the sixth mirror from the top going clockwise, roughly in the “south southeast” position) that occurred back in late May was larger than any of the simulations or test strikes performed on Earth prior to launch. It was also not part of any known meteoroid storm in the telescope’s orbit; if it had been, controllers would have been able to maneuver the spacecraft to protect the gold-plated beryllium segments. The rogue space rock apparently did enough damage to be noticeable in the data coming back from the telescope and to require adjustment to the position of the mirror segment. While it certainly won’t be the last time this happens, it would have been nice to see one picture from Webb before it started accumulating hits.

Continue reading “Hackaday Links: June 12, 2022”