Last weekend, DEF CON held their “SAFE MODE” conference: instead of meeting at a physical venue, the entire conference was held online. All the presentations are available on the official DEF CON YouTube channel. We’ll cover a few of the presentations here, and watch out for other articles on HaD with details on the other talks that we found interesting.

Lock Picking

We don’t often dabble with physical security in our weekly roundup, but the lockpicking track is a big part of DEF CON. It’s a perfect excuse. So first up is a presentation about safe-cracking by [Jared Dygert]. You know the scene in the movie where the super thief cracks the safe by listening to it as he spins the dial? Yeah, forget that. The real technique doesn’t have anything to do with sound. A typical three-number combination safe has a trio of wheels inside the locking mechanism. Each of these wheels have a narrow slot, or gate, cut into them. When the three gates are lined up, the locking bar can fall into the slots, and a fourth wheel pulls the lock open.

That fourth wheel is the key to cracking a safe, as the locking bar rides directly on the outer surface of that wheel. The gate there is shaped differently from the others, with a curved edge on one side. It’s possible to feel exactly when the locking bar begins to drop into that gate. Because of the shape of that special fourth gate, it’s possible to measure the width, and by extension discover how far the locking bar has dropped. As the three wheels with unknown gates aren’t perfectly the same size, it’s possible to map the surface of the largest wheel and discover where the gate is. For a demonstration, watch the video linked above.

It’s hard to mention lock pickers without giving a shout-out to a pair of YouTubers, [Bosnianbill] and [LockPickingLawyer]. I came across a video this week from the lawyer of this dynamic duo, and it’s the most polite-yet-savage burn I’ve seen in a long while. Before you watch, know that the tool he uses is the Sparrows Disk Pick, and he and [Bosnianbill] worked together to design and beta test the tool.

A Dragon’s Achilles Heel

Snapdragon processors are quite popular in high end Android devices. These processors are packaged in a System on a Chip (SoC), which really contains a number of processors and devices. A Snapdragon SoC has a processor, GPU, Wifi modem, Image Signal Processor, and Digital Signal Processor. We talk a lot about security vulnerabilities in the software that runs on the CPU. What if I told you there were vulnerabilities in software running on those other processor cores, too? Well yeah, there will obviously be poorly written code there too. What hasn’t been obvious is how to find those vulnerabilities, and then how to attack them. Now, thanks to the researchers at Checkpoint Security, and their work on Achilles, we know a way to attack the dragon’s heel.

When an app needs to use the Snapdragon DSP, it invokes a serialization library, referred to as a stub.so file. Once the data is serialized, it is transferred to the DSP over shared memory, using the DSRPC driver. Along with the data to be processed, the application also sends along the processing library. This library is essentially the program that will run on the DSP. There is a code signing requirement. The DSP will only run code that has been signed by Qualcomm, but there is no version checking or revocation mechanism. In essence, any DSP library Qualcomm has ever signed is allowed to run on every DSP. To make matters worse, an Android app can access the DSP with no special permissions. Even if only one vulnerable DSP library were created, the weak code-signing scheme means that every Qualcomm DSP is vulnerable.

A few articles are suggesting that a malicious video or audio file downloaded from the net can trigger the vulnerability. This is incorrect. So far, only an application with direct access to the DSP can launch the attack. During the virtual press conference on Thursday, this was addressed by a Checkpoint researcher. While it’s theoretically possible for a video file to trigger a yet-to-be-found vulnerability, the flaw they found is a deserialization bug that is only triggered by a malicious serialization process. This means data processed using the official serialization process can’t trigger this vulnerability. The deserialization bug is actually rooted in the Software Development Kit that is distributed to OEMs and used to build the individual libraries. To put it simply, it’s not just one or two DSP library that is vulnerable, but all of them, which is where the “400 vulnerabilities” comes from.

Once a malicious application uses the vulnerability to break the deserialization routine and achieve code execution, what’s next? Qualcomm did at least do proper user/kernel separation, and an additional vulnerability is needed to escalate privilege up to full compromise. Once there, the primary threat is data leakage. The malware on the DSP can examine all the data that other applications share for processing. This likely means full access to the device’s microphone, and potentially camera when it is use. I was able to ask Checkpoint if they had managed to permanently modify the DSP’s firmware, as this sort of modification could survive through even a full factory reset. Their response is that they had investigated this question, and had been unable to make a permanent modification. This isn’t surprising as firmware of this nature is often not stored on the SoC itself, but is loaded from the main system flash memory as a part of the boot process.

So far, this set of vulnerabilities doesn’t pose a huge risk to the everyday user. The normal advice of not installing untrusted applications is still the best solution. The major danger here is that DSP malware could be used by an installed application to access the microphone audio without having any permissions. The process of fixing this set of vulnerabilities will be a headache for years to come. Not only will the individual vulnerable libraries need to be updated, the signing problems will need to be addressed so vulnerable libraries can’t be trivially executed. It does not appear that any fixes are available at this time.

For your viewing pleasure, one of the other excellent talks from DEF CON is below, where [Christopher Wade] dives deeply into firmware hacking, primarily on Android devices.

Intel Leaks 20 GB

A very large dump of Intel code and documentation was made public last week. The official Intel explanation a partner or customer must have abused their access to Intel’s “Resource and Design Center”, and leaked the documents from there. According to ZDnet’s coverage, though, the leaker claims to have found the documentation on a CDN server that wasn’t properly configured.

Regardless, the leak seems to be genuine. Time will tell what interesting tidbits are contained in the 20 GB that were just released. As the information is all marked confidential, there is a bit of a legal grey area as to what programmers are allowed to do with the information.

Robot Exorcist?

And finally, just for fun, researchers at McAfee found a set of vulnerabilities in the “temi” teleconference robot. In a surprisingly detailed write-up, they describe how an attacker can possess the robot without any valid credentials, use it to drive the robot around and spy on whatever is nearby. McAfee researchers have shared all their findings with temi’s vendor, and fixes are already available.