[Kuba Tyszko] like many of us, has been hacking things from a young age. An early attempt at hacking around with grandpa’s tractor might have been swiftly quashed by his father, but likely this was not the last such incident. With a more recent interest in cracking encrypted applications, [Kuba] gives us some insights into some of the tools at your disposal for reading out the encrypted secrets of applications that have something worth hiding. (Slides here, PDF.)
There may be all sorts of reasons for such applications to have an encrypted portion, and that’s not really the focus. One such application that [Kuba] describes was a pre-trained machine-learning model written in the R scripting language. If you’re not familiar with R, it is commonly used for ‘data science’ type tasks and has a big fan base. It’s worth checking out. Anyway, the application binary took two command line arguments, one was the encrypted blob of the model, and the second was the path to the test data set for model verification.
The first thing [Kuba] suggests is to disable network access, just in case the application wants to ‘dial home.’ We don’t want that. The application was intended for Linux, so the first port of call was to see what libraries it was linked against using the
ldd command. This indicated that it was linked against OpenSSL, so that was a likely candidate for encryption support. Next up, running
objdump gave some clues as to the various components of the binary. It was determined that it was doing something with 256-bit AES encryption. Now after applying a little experience (or educated guesswork, if you prefer), the likely scenario is that the binary yanks the private key from somewhere within itself reads the encrypted blob file, and passes this over to
libssl. Then the plaintext R script is passed off to the R runtime, the model executes against the test data, and results are collated.
[Kuba]’s first attack method was to grab the OpenSSL source code and drop in some strategic printf() function calls into the target functions. Next, using the LD_PRELOAD ‘trick’ the standard system OpenSSL library was substituted with the ‘fake’ version with the trojan
printfs. The result of this was the decryption function gleefully sending the plaintext R script direct to the terminal. No need to even locate the private key!
Continue reading “SUPERCON 2022: Kuba Tyszko Cracks Encrypted Software”
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 :)
You shouldn’t transmit encryption keys over Bluetooth, but that’s exactly what some popular wireless-enabled microcontrollers are already doing. This is the idea behind Screaming Channels, an exploit published by researchers at EUERCOM, and will be a talk at Black Hat next week. So far, the researchers have investigated side-channel attacks on Bluetooth-enabled microcontrollers, allowing them to extract tinyAES keys from up to 10 meters away in controlled environments. A PDF of the paper is available and all the relevant code is available on GitHub.
The experimental setup for this exploit consisted of a BLE Nano, a breakout board for a Nordic nRF52832 Bluetooth microcontroller, a Hack RF, a USRB N210 software defined radio from Ettus, and a few high-gain antennas and LNAs. The example attack relies on installing firmware on the BLE Nano that runs through a few loops and encrypts something with tinyAES. Through very careful analysis of the RF spectrum, the AES keys can be extracted from the ether.
Side channel attacks have received a bit more popularity over recent years. What was once limited to Three Letter Agency-level Van Eck phreaking can now be done inexpensively and in a system with devices like the ChipWhisperer.
Of course, this is only a demonstration of what is possible with side-channel attacks in a highly controlled environment with a significant amount of work gone into the firmware running on the microcontroller. This isn’t evidence that balaclava-wearing hackers are sniffing your phone from across the parking lot to get the password to your Instagram account, but it does show what is possible with relatively cheap, off-the-shelf hardware.
Getting cryptography right isn’t easy, and it’s a lot worse on constrained devices like microcontrollers. RAM is usually the bottleneck — you will smash your stack computing a SHA-2 hash on an AVR — but other resources like computing power and flash code storage space are also at a premium. Trimming down a standard algorithm to work within these constraints opens up the Pandora’s box of implementation-specific flaws.
NIST stepped up to the plate, starting a lightweight cryptography project in 2013 which has now come out with a first report, and here it is as a PDF. The project is ongoing, so don’t expect a how-to guide. Indeed, most of the report is a description of the problems with crypto on small devices. Given the state of IoT security, just defining the problem is a huge contribution.
Still, there are some concrete recommendations. Here are some spoilers. For encryption, they recommend a trimmed-down version of AES-128, which is a well-tested block cipher on the big machines. For message authentication, they’re happy with Galois/Counter Mode and AES-128.
I was most interested in hashing, and came away disappointed; the conclusion is that the SHA-2 and SHA-3 families simply require too much state (and RAM) and they make no recommendation, leaving you to pick among less-known functions: check out PHOTON or SPONGENT, and they’re still being actively researched.
If you think small-device security is easy, read through the 22-question checklist that starts on page twelve. And if you’re looking for a good starting point to read up on the state of the art, the bibliography is extensive.
Your tax dollars at work. Thanks, NIST!
And thanks [acs] for the tip!
[Blancmange] built a custom door chime using an ATtiny85. Unlike most commercial products out there, this one actually tries to be secure, using AES-CMAC for message signing.
The hardware is pretty simple, and a protoboard layout is shown in the image above. It uses the ATtiny85 for control, with an LM380N audio amplifier, and a low cost 315 MHz receiver.
The more impressive part of the build is the firmware. Using AVR assembly, [Blancmange] managed to fit everything into the 8 Kbytes of flash on the ATtiny85. This includes an implementation of AES-CMAC, an AES cypher based message authentication code. The transmitting device signs the request with a key shared between both devices, and the receiver verifies that the message is from a trusted transmitter.
Fortunately, the assembly code is very well commented. If you’ve ever wanted to take a look into some complex ASM assembly, this is a great project to check out. The source code has been released into the public domain, so the rest of us can implement crypto on this cheap microcontroller with much less effort.
Back in 2012, the LIFX light bulb launched on Kickstarter, and was quite successful. This wireless LED lightbulb uses a combination of WiFi and 6LoWPAN to create a network of lightbulbs within your house. Context Information Security took a look into these devices, and found some security issues.
The LIFX system has a master bulb. This is the only bulb which connects to WiFi, and it sends all commands out to the remaining bulbs over 6LoWPAN. To keep the network up, any bulb can become a master if required. This means the WiFi credentials need to be shared between all the bulbs.
Looking into the protocol, an encrypted binary blob containing WiFi credentials was found. This binary could easily be recovered using an AVR Raven evaluation kit, but was not readable since it was encrypted.
After cracking a bulb apart, they found JTAG headers on the main board. A BusBlaster and OpenOCD were used to communicate with the chip. This allowed the firmware to be dumped.
Using IDA Pro, they determined that AES was being used to encrypt the WiFi credentials. With a bit more work, the key and initialization vector was extracted. With this information, WiFi credentials sent over the air could be decrypted.
The good news is that LIFX fixed this issue. Now they generate an encryption key based on WiFi credentials, preventing a globally unique key from being used.
Since the Hackaday community started working on our offline password keeper, Mooltipass, we’ve received several similar projects in our tips line. The Final Key may be the most professional looking one yet. Similarly to the Mooltipass, it is based on an Atmel ATMega32U4 but only includes one button and one LED, all enclosed in a 3D printed case.
The Final Key is connected to the host computer via USB and is enumerated as a composite Communication Device / HID Keyboard, requiring windows-based devices to install drivers. AES-256 encrypted passwords are stored on the device and can only be accessed once the button has been pressed and the correct 256 bit password has been presented through the command line interface. Credentials management and access is also done through the latter. Unfortunately, the Arduino source code can’t be found on [cyberstalker]’s website, so if you see interesting features that you would like to be integrated in Mooltipass you may send us a message to our Google Group.