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.
[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.
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.
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.
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 :)
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.
“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.
[Samuel]’s first foray into making DIY hardware authentication tokens was a great success, but he soon realized that a device intended for everyday carry and use has a few different problems to solve, compared to a PCB that lives and works on a workbench. This led to TurtleAuth 2.1, redesigned for everyday use and lucky for us all, he goes into detail on all the challenges and solutions he faced.
When we covered the original TurtleAuth DIY security token, everything worked fantastically. However, the PCB layout had a few issues that became apparent after a year or so of daily use. Rather than 3D print an enclosure and call it done, [Samuel] decided to try a different idea and craft an enclosure from the PCB layers themselves.
The three-layered PCB sandwich keeps components sealed away and protected, while also providing a nice big touch-sensitive pad on the top, flanked by status LEDs. Space was a real constraint, and required a PCB redesign as well as moving to 0402 sized components, but in the end he made it work. As for being able to see the LEDs while not having any component exposed? No problem there; [Samuel] simply filled in the holes over the status LEDs with some hot glue, creating a cheap, effective, and highly durable diffuser that also sealed away the internals.