security

463 Articles

Ambient Computer Noise Leaks Your Encryption Keys

December 20, 2013 by 65 Comments

[Daniel, Adi, and Eran], students researchers at Tel Aviv University and the Weizmann Institute of Science have successfully extracted 4096-bit RSA encryption keys using only the sound produced by the target computer. It may sound a bit like magic, but this is a real attack – although it’s practicality may be questionable. The group first described this attack vector at Eurocrypt 2004. The sound used to decode the encryption keys is produced not by the processor itself, but by the processor’s power supply, mainly the capacitors and coils. The target machine in this case runs a copy of GNU Privacy Guard (GnuPG).

During most of their testing, the team used some very high-end audio equipment, including Brüel & Kjær laboratory grade microphones and a parabolic reflector. By directing the microphone at the processor air vents, they were able to extract enough sound to proceed with their attack. [Daniel, Adi, and Eran] started from the source of GnuPG. They worked from there all the way down to the individual opcodes running on the x86 processor in the target PC. As each opcode is run, a sound signature is produced. The signature changes slightly depending on the data the processor is operating on. By using this information, and some very detailed spectral analysis, the team was able to extract encryption keys. The complete technical details of the attack vector are available in their final paper (pdf link).

Once  they had the basic methods down, [Daniel, Adi, and Eran] explored other attack vectors. They were able to extract data using ground fluctuations on the computers chassis. They even were able to use a cell phone to perform the audio attack. Due to the cell phone’s lower quality microphone, a much longer (on the order of several hours) time is needed to extract the necessary data.

Thankfully [Daniel, Adi, and Eran] are white hat hackers, and sent their data to the GnuPG team. Several countermeasures to this attack are already included in the current version of GnuPG.

Google Security Certificates Forged

December 9, 2013 by 23 Comments

Recently, Google discovered that a certificate authority (CA) issued forged certificates for Google domains. This compromises the trust provided by Transport Layer Security (TLS) and Secure HTTP (HTTPS), allowing the holder of the forged certificates to perform a man-in-the-middle attack.

To validate that the website you’re visiting is actually who they claim to be, your browser ensures that the certificate presented by the server you’re accessing was signed by a trusted CA. When someone requests a certificate from a CA, they should verify the identity of the person making the request. Your browser, and operating system, have a set of ultimately trusted CAs (called root CAs). If the certificate was issued by one of them, or a intermediate CA that they trust, you will trust the connection. This whole structure of trust is called a Chain of Trust.

With a forged certificate, you can convince a client that your server is actually http://www.google.com. You can use this to sit between a client’s connection and the actual Google server, eavesdropping their session.

In this case, an intermediate CA did just that. This is scary, because it undermines the security that we all rely on daily for all secure transactions on the internet. Certificate pinning is one tool that can be used to resist this type of attack. It works by associating a host with a specific certificate. If it changes, the connection will not be trusted.

The centralized nature of TLS doesn’t work if you can’t trust the authorities. Unfortunately, we can’t.

Update: SD Card Locker Now Supports Password Protect

November 27, 2013 by 19 Comments

sdlocker2_1

[Karl Lunt] has updated his Secure Digital Card locker to support password based locking. [Karl’s] original design only supported write locking via the TMP_WRITE_PROTECT  bit. The new design gives the user an option: TMP_WRITE_PROTECT, or password protection. [Karl] goes into further detail this time around about the bit fields used with CMD42, and how they are set. The passwords in this case are up to 16 bytes. The bytes don’t necessarily have to be printable characters – any binary value can be used. Unfortunately, [Karl’s] locker doesn’t utilize a user interface beyond the buttons, so any password must be “baked in” to the SD Card locker firmware. We would love to see the option of even a basic serial interface for entering a password (most likely in hex).

[Karl] tried his device out with several different cards, and several computers. While not an exhaustive test, he did find that the computers always behaved the same: A locked SD card would not show up. In the case of windows, no beep, no drive, nothing. He goes into the security possibilities of using password locking: Financial data could be stored and physically transferred via SD or microSD, with the password sent separately (say in an email or SMS). Any unenlightened data thief attempting to use the card would think they have a broken device on their hands.

We don’t know how secure the password lock feature is – brute forcing a variable length 16 byte binary password would take some time. It all comes down to how quickly each password attempt takes. Some cursory web searching didn’t bring up any information about successful SD card password cracking. Sounds like a challenge for our readers!

Getting A Shell On Any Android Device

November 17, 2013 by 29 Comments

If you’re an Evil Customs Agent or other nefarious Three Letter Agency Person, you’re probably very interesting in getting data off people’s phones. Even if the screen is locked, there’s a way around this problem: just use the Android Debug Bridge (ADB), a handy way to get a shell on any Android device with just a USB cable. The ADB can be turned off, though, so what is the Stasi to do if they can’t access your phone over ADB? [Michael Ossmann] and [Kyle Osborn] have the answer that involves a little-known property of USB devices.

USB mini and micro plugs have five pins – power, ground, D+, D-, and an oft-overlooked ID pin. With a particular resistance between this ID pin and ground, the USB multiplexor inside your phone can allow anyone with the proper hardware to access the state of the charger, get an audio signal, mess around with the MP3s on your device, or even get a shell.

To test their theory, [Michael] and [Kyle] rigged up a simple USB plug to UART adapter (seen above) that included a specific value of resistor to enable a shell on their test phone. Amazingly, it worked and the thought of having a secure phone was never had again.

The guys went farther with some proprietary Samsung hardware that could, if they had the service manual, unlock any samsung phone made in the last 15 years. They’re working on building a device that will automagically get a shell on any phone and have built some rather interesting hardware. If you’re interested in helping them out with their project, they have a project site up with all the information to get up to speed on this very ingenious hack.

Continue reading “Getting A Shell On Any Android Device” →

Keep Your SD Cards Data Safe With The SD Locker

November 12, 2013 by 41 Comments

sdlocker_1

[Karl Lunt] has come up with a simple circuit for protecting data you have stored on SD cards. As is relatively well-known, the little lock switch on the side of most SD cards really doesn’t do anything more than the switch on floppies or the tabs on VHS or cassette decks. It’s up to the reader/writer to check the status of the tab and decide if it should write to the card or not. Not a very safe system. However, it’s not the only write protection system built into SD and SDHC cards. As part of the standard, cards have three protection methods: A TMP_WRITE_PROTECT bit, a PERM_WRITE_PROTECT bit, and a PWD register.

The PERM_WRITE_PROTECT bit permanently write protects the card. The bit can not be reset, so you should be really sure you want to keep the data on the card forever. The PWD register is a password register. The card will not allow any access (read or write) unless a password is provided. The TMP_WRITE_PROTECT bit is a temporary write protect. This is the bit that [Karl] is working with. When TMP_WRITE_PROTECT is set, the card can be read but not written. Note that there is no true protection here, as anyone can modify the bit. However, this should stop grandma from accidentally deleting your wedding pictures.

[Karl’s] device is very simple. A card is inserted into an Altoids tin enclosure. One button locks the card, another unlocks it. Three LEDs return status – power, card locked, and card unlocked. Under the hood, he’s using an Atmel ATmega328 to set and clear the TMP_WRITE_PROTECT bits. Power is provided by two AA batteries, and regulated with a Pololu 3.3v boost regulator. [Karl] has also included a serial port for control and debug information. We think this is a great hack, however one thing we’re not sure of is how or if these features are implemented in all cards. We’re relatively sure the name brand cards stick to the SD/SDHC spec sheet, but what about all the knockoff and no name brands from overseas?

Running Custom Code On Cheap One-time Password Tokens

October 15, 2013 by 41 Comments

One-time passwords (OTP) are often used in America but not so much in Europe. For our unfamiliar readers, OTP tokens like the one shown above generate passwords that are only valid for one login session or transaction, making them invulnerable to replay attacks. [Dmitry] disassembled one eToken (Aladin PASS) he had lying around and managed to reprogram it for his own needs.

Obviously, these kind of devices don’t come with their schematics and layout files so [Dmitry] had to do some reverse engineering. He discovered six holes in a 3×2 arrangement on the PCB so he figured that they must be used to reprogram the device. However, [Dmitry] also had to find which microcontroller was present on the board as its only marking were “HA4450” with a Microchip logo. By cross-referencing the number of pins, package and peripherals on Microchip parametric search tool he deduced it was a PIC16F913. From there, it was just a matter of time until he could display what he wanted on the LCD.

We love seeing tiny consumer hardware hacked like this. Most recently we’ve been enthralled by the Trandscend Wi-Fi SD card hacking which was also one of [Dmitry’s] hacks.

Wi-Fi Enabled Garage Door Opener

September 26, 2013 by 27 Comments

Normally, internet-controlled household devices are a cobbled together mashup of parts. This is great for a prototype, but if you’re looking for something that will last a decade in your garage, you’ll need something a little cleaner and more robust. [Phil]’s Internet-enabled garage door opener is just that, replete with a custom-made enclosure for his Arduino powered system.

The main hardware for [Phil]’s build is a Freetronix EtherTen, an Arduino clone with a built-in Ethernet interface. Aside from that, the electronics are simple: a relay, transistor, and diode provide the connection from the EtherTen to the garage door opener.

The software for this setup consists of a main file that sets up the web page, the serial monitor, and loops through the main program. There are a bunch of classes for initializing the web page, writing passwords to the EEPROM, activating the door, and setting the MAC and IP addresses.

Opening the door with this remote is a snap: with any WiFi enabled smartphone or tablet, [Phil] only needs to log onto his network, surf on over to the page hosted on the Arduino, and enter a password. From there, opening the door is just a press of a button. Passwords and other configuration settings cane be entered with MegunoLink. This software also includes a serial monitor to log who opened the door and when.

It’s an interesting and compact system, and handy to boot. You might sometimes forget your garage door opener, but we’re thinking if you ever find yourself without your phone, a closed garage door is the least of your problems.