Security Hacks

1543 Articles

Samy Kamkar Illustrates How To Be A Hardware Hacker

December 19, 2016 by 4 Comments

Samy Kamkar is well known for many things, but lately it has been his hardware security hacks that have been turning heads. The nice thing to know is that, despite not having a background in hardware, Samy is able to run with the best of hardware researchers. At the Hackaday SuperConference he offered words of advice for anyone trying to walk the path of discovery with an exciting new piece of electronics. One might say it’s a crash-course in how to be a hardware hacker.

Continue reading “Samy Kamkar Illustrates How To Be A Hardware Hacker” →

Eavesdropping Via Headphones

December 18, 2016 by 22 Comments

We all know that speakers are microphones and microphones are speakers, right? If not, take a moment to plug your headphones into a microphone jack and yell into them. It’s not exactly hi-fi, but it works.

So it’s not a huge surprise that three security researchers in Israel have managed to turn the combination headphone and microphone input jacks that are present on most laptops into an eavesdropping device. (Paper here as PDF, with an obligatory demo video on YouTube, embedded below.) Speake(a)r is a neat proof-of-concept and a horrid pun. Continue reading “Eavesdropping Via Headphones” →

Reliably Exploiting Apport In Ubuntu

December 16, 2016 by 17 Comments

[Donncha O’Cearbhaill] has successfully exploited two flaws in Apport, the crash report mechanism in Ubuntu. Apport is installed by default in all Ubuntu Desktop installations >= 12.10 (Quantal). Inspired by [Chris Evan] work on exploiting 6502 processor opcodes on the NES, [Donncha] describes the whole process of finding and exploiting a 0-day on a modern linux system.

One of the flaws, tracked as CVE-2016-9949, relies on a python code injection in the crash file. Apport blindly uses the python eval() function on an unsanitized field (CrashDB) inside the .crash file. This leads directly to arbitrary python code execution. The other flaw, tracked as CVE-2016-9950, takes advantage of a path traversal attack and the execution of arbitrary Python scripts outside the system hook_dirs. The problem arises when another field (Package) from the crash report file is used without sanitizing when building a path to the package hook files.

CVE-2016-9949 is easily exploitable, if an attacker can trick a user into opening a specially crafted file (apport .crash file), the attacker can execute the python code of his/her choice. Two details make it a very interesting exploit.

The first thing to note is the exploit’s reliability. Given that it is pure python code execution, an attacker doesn’t have to worry about ASLR, Non-Exec Memory, Stack Canaries and other security features that Ubuntu ships by default. As the author notes:

“There are lots of bugs out there which don’t need hardcore memory corruption exploitation skills. Logic bugs can be much more reliable than any ROP chain.”

Another interesting detail is that the exploit file doesn’t need to have the .crash extension, as long as its content starts with the string “ProblemType: ” and the file extension is not associated already with other software, Ubuntu considers it being of mime-type type=”text/x-apport” (for example, .ZlP or .0DF). This significantly improves the chances of an unsuspecting user being fooled into open the file.

Continue reading “Reliably Exploiting Apport In Ubuntu” →

Chris Conlon: Device Security 101

December 14, 2016 by 10 Comments

We all wring our hands over the security (or lack thereof!) of our myriad smart devices. If you haven’t had your home network hacked through your toaster, or baby cam, you’re missing out on the zeitgeist. But it doesn’t have to be this way — smart devices can be designed with security in mind, and [Chris Conlon] came to Pasadena to give us a talk on the basics.

He starts off the talk with three broad conceptual realms of data security: data in transit, data at rest on the device, and the firmware and how it’s updated. A common thread underlying all of this is cryptography, and he devotes the last section of his  talk to getting that right. So if you’d like a whirlwind tour of device security, watch on!

Continue reading “Chris Conlon: Device Security 101” →

TP-Link Debug Protocol Gives Up Keys To Kingdom

December 14, 2016 by 25 Comments

If the headline makes today’s hack sound like it was easy, rest assured that it wasn’t. But if you’re interested in embedded device hacking, read on.

[Andres] wanted to install a custom OS firmware on a cheap home router, so he bought a router known to be reflashable only to find that the newer version of the firmware made that difficult. We’ve all been there. But instead of throwing the device in the closet, [Andres] beat it into submission, discovering a bug in the firmware, exploiting it, and writing it up for the manufacturer.  (And just as we’re going to press: posting the code for the downgrade exploit here.)

This is not a weekend hack — this took a professional many hours of serious labor. But it was made a lot easier because TP-Link left a debugging protocol active, listening on the LAN interface, and not requiring authentication. [Andres] found most of the information he needed in patents, and soon had debugging insight into the running device.

Continue reading “TP-Link Debug Protocol Gives Up Keys To Kingdom” →

All I Want For Christmas Is A 4-Factor Biometric Lock Box

December 13, 2016 by 24 Comments

It’s the most wonderful time of the year! No, we’re not talking about the holiday season, although that certainly has its merits. What we mean is that it’s time for the final projects from [Bruce Land]’s ECE4760 class. With the giving spirit and their mothers in mind, [Adarsh], [Timon], and [Cameron] made a programmable lock box with four-factor authentication. That’s three factors more secure than your average Las Vegas hotel room safe, and with a display to boot.

Getting into this box starts with a four-digit code on a number pad. If it’s incorrect, the display will say so. Put in the right code and the system will wait four seconds for the next step, which involves three potentiometers. These are tuned to the correct value with a leeway of +/- 30. After another four-second wait, it’s on to the piezo-based knock detector, which listens for the right pattern. Finally, a fingerprint scanner makes sure that anyone who wants into this box had better plan ahead.

This project is based on Microchip’s PIC32-based Microstick II, which [Professor Land] starting teaching in 2015. It also uses an Arduino Uno to handle the fingerprint scanner. The team has marketability in mind for this project, and in the video after the break, they walk through the factory settings and user customization.

We have seen many ways to secure a lock box. How about a laser-cut combination safe or a box with a matching NFC ring?

Continue reading “All I Want For Christmas Is A 4-Factor Biometric Lock Box” →

Neutralizing Intel’s Management Engine

November 28, 2016 by 189 Comments

Five or so years ago, Intel rolled out something horrible. Intel’s Management Engine (ME) is a completely separate computing environment running on Intel chipsets that has access to everything. The ME has network access, access to the host operating system, memory, and cryptography engine. The ME can be used remotely even if the PC is powered off. If that sounds scary, it gets even worse: no one knows what the ME is doing, and we can’t even look at the code. When — not ‘if’ — the ME is finally cracked open, every computer running on a recent Intel chip will have a huge security and privacy issue. Intel’s Management Engine is the single most dangerous piece of computer hardware ever created.

Researchers are continuing work on deciphering the inner workings of the ME, and we sincerely hope this Pandora’s Box remains closed. Until then, there’s now a new way to disable Intel’s Management Engine.

Previously, the first iteration of the ME found in GM45 chipsets could be removed. This technique was due to the fact the ME was located on a chip separate from the northbridge. For Core i3/i5/i7 processors, the ME is integrated to the northbridge. Until now, efforts to disable an ME this closely coupled to the CPU have failed. Completely removing the ME from these systems is impossible, however disabling parts of the ME are not. There is one caveat: if the ME’s boot ROM (stored in an SPI Flash) does not find a valid Intel signature, the PC will shut down after 30 minutes.

A few months ago, [Trammell Hudson] discovered erasing the first page of the ME region did not shut down his Thinkpad after 30 minutes. This led [Nicola Corna] and [Frederico Amedeo Izzo] to write a script that uses this exploit. Effectively, ME still thinks it’s running, but it doesn’t actually do anything.

With a BeagleBone, an SOIC-8 chip clip, and a few breakout wires, this script will run and effectively disable the ME. This exploit has only been confirmed to work on Sandy Bridge and Ivy Bridge processors. It should work on Skylake processors, and Haswell and Broadwell are untested.

Separating or disabling the ME from the CPU has been a major focus of the libreboot and coreboot communities. The inability to do so has, until now, made the future prospects of truly free computing platforms grim. The ME is in everything, and CPUs without an ME are getting old. Even though we don’t have the ability to remove the ME, disabling it is the next best thing.