Security Hacks

1475 Articles

SingLock

SingLock Protects Your Valuables From Shy People

December 17, 2014 by 14 Comments

Two Cornell students have designed their own multi-factor authentication system. This system uses a PIN combined with a form of voice recognition to authenticate a user. Their system is not as simple as speaking a passphrase, though. Instead, you have to sing the correct tones into the lock.

The system runs on an ATMEL MEGA1284P. The chip is not sophisticated enough to be able to easily identify actual human speech. The team decided to focus their effort on detecting pitch instead. The result is a lock that requires you to sing the perfect sequence of pitches. We would be worried about an attacker eavesdropping and attempting to sing the key themselves, but the team has a few mechanisms in place to protect against this attack. First, the system also requires a valid PIN.  An attacker can’t deduce your PIN simply by listening from around the corner. Second, the system also maintains the user’s specific voice signature.

The project page delves much more deeply into the mathematical theory behind how the system works. It’s worth a read if you are a math or audio geek. Check out the video below for a demonstration. Continue reading “SingLock Protects Your Valuables From Shy People” →

Downloading Data Through The Display

December 14, 2014 by 75 Comments

HIPAA – the US standard for electronic health care documentation – spends a lot of verbiage and bureaucratese on the security of electronic records, making a clear distinction between the use of records by health care worker and the disclosure of records by health care workers. Likewise, the Federal Information Security Management Act of 2002 makes the same distinction; records that should never be disclosed or transmitted should be used on systems that are disconnected from networks.

This distinction between use and disclosure or transmission is of course a farce; if you can display something on a screen, it can be transmitted. [Ian Latter] just gave a talk at Kiwicon that provides the tools to do just that. He calls it ThruGlassXfer (TGXf), and it does exactly what it says on the tin: anything that can be displayed on a screen can be transmitted. All you need are the right tools.

Continue reading “Downloading Data Through The Display” →

Reverse Engineering Capcom’s Crypto CPU

December 12, 2014 by 26 Comments

There are a few old Capcom arcade titles – Pang, Cadillacs and Dinosaurs, and Block Block – that are unlike anything else ever seen in the world of coin-ops. They’re old, yes, but what makes these titles exceptional is the CPU they run on. The brains in the hardware of these games is a Kabuki, a Z80 CPU that had a few extra security features. why would Capcom produce such a thing? To combat bootleggers that would copy and reproduce arcade games without royalties going to the original publisher. It’s an interesting part of arcade history, but also a problem for curators: this security has killed a number of arcade machines, leading [Eduardo] to reverse engineering and document the Kabuki in full detail.

While the normal Z80 CPU had a pin specifically dedicated to refreshing DRAM, the Kabuki repurposed this pin for the security functions on the chip. With this pin low, the Kabuki was a standard Z80. When the pin was pulled high, it served as a power supply input for the security features. The security – just a few bits saved in memory – was battery backed, and once this battery was disconnected, the chip would fail, killing the game.

Plugging Kabuki into an old Amstrad CPC 6128 without the security pin pulled high allowed [Eduardo] to test all the Z80 instructions, and with that no surprises were found; the Kabuki is fully compatible with every other Z80 on the planet. Determining how Kabuki works with that special security pin pulled high is a more difficult task, but the Mame team has it nailed down.

The security system inside Kabuki works through a series of bitswaps, circular shifts, XORs, each translation different if the byte is an opcode or data. The process of encoding and decoding the security in Kabuki is well understood, but [Eduardo] had a few unanswered questions. What happens after Kabuki lost power and the memory contents – especially the bitswap, address, and XOR keys – vanished? How was the Kabuki programmed in the factory? Is it possible to reprogram these security keys, allowing one Kabuki to play games it wasn’t manufactured for?

[Eduardo] figured being able to encrypt new, valid code was the first step to running code encrypted with different keys. To test this theory, he wrote a simple ‘Hello World’ for the Capcom hardware that worked perfectly under Mame. While the demo worked perfectly under Mame, it didn’t work when burned onto a EPROM and put into real Capcom hardware.

That’s where this story ends, at least for the time being. The new, encrypted code is valid, Mame runs the encrypted code, but until [Eduardo] or someone else can figure out any additional configuration settings inside the Kabuki, this project is dead in the track. [Eduardo] will be back some time next week tearing the Kabuki apart again, trying to unravel the mysteries of what makes this processor work.

Keurig

Dead Simple Hack Allows For “Rebel” Keurig K-Cups

December 10, 2014 by 141 Comments

If you haven’t actually used a Keurig coffee machine, then you’ve probably at least seen one. They are supposed to make brewing coffee simple. You just take one of the Keurig “k-cups” and place it into the machine. The machine will punch a hole in the foil top and run the water through the k-cup. Your flavored beverage of choice comes out the other side. It’s a simple idea, run by a more complex machine. A machine that is complicated enough to have a security vulnerability.

Unfortunately newer versions of these machines have a sort of DRM, or lockout chip. In order to prevent unofficial k-cups from being manufactured and sold, the Keurig machines have a way to detect which cups are legitimate and which are counterfeit. It appears as though the machine identifies the lid specifically as being genuine.

It turns out this “lockout” technology is very simple to defeat. All one needs to do is cut the lid off of a legitimate Keurig k-cup and place it on top of your counterfeit cup. The system will read the real lid and allow you to brew to your heart’s content. A more convenient solution involves cutting off just the small portion of the lid that contains the Keurig logo. This then gets taped directly to the Keurig machine itself. This way you can still easily replace the cups without having to fuss with the extra lid every time.

It’s a simple hack, but it’s interesting to see that even coffee machines are being sold with limiting technology these days. This is the kind of stuff we would have joked about five or ten years ago. Yet here we are, with a coffee machine security vulnerability. Check out the video demonstration below. Continue reading “Dead Simple Hack Allows For “Rebel” Keurig K-Cups” →

YikYak

Yik Yak MITM Hack (Give The Dog A Bone)

December 10, 2014 by 24 Comments

Yik Yak is growing in popularity lately. If you are unfamiliar with Yik Yak, here’s the run down. It’s kind of like Twitter, but your messages are only shared with people who are currently within a few miles of you. Also, your account is supposed to be totally anonymous. When you combine anonymity and location, you get some interesting results. The app seems to be most popular in schools. The anonymity allows users to post their honest thoughts without fear of scrutiny.

[Sanford Moskowitz] decided to do some digging into Yik Yak’s authentication system. He wanted to see just how secure this “anonymous” app really is. As it turns out, not as much as one would hope. The primary vulnerability is that Yik Yak authenticates users based solely on a user ID. There are no passwords. If you know the user’s ID number, it’s game over.

The first thing [Sanford] looked for was an encrypted connection to try to sniff out User ID’s. It turned out that Yik Yak does actually encrypt the connection to its own servers, at least for the iPhone app. Not to worry, mobile apps always connect to other services for things like ad networks, user tracking, etc. Yik Yak happens to make a call to an analytics tool called Flurry every time the app is fired. Flurry needs a way to track the users for Yik Yak, so of course the Yik Yak App tells Flurry the user’s ID. What other information would the anonymous app have to send?

Unfortunately, Flurry disables HTTPS by default, so this initial communication is in plain text. That means that even though Yik Yak’s own communications are protected, the User ID is still exposed and vulnerable. [Sanford] has published a shell script to make it easy to sniff out these user ID’s if you are on the same network as the user.

Once you have the user ID, you can take complete control over the account. [Sanford] has also published scripts to make this part simple. The scripts will allow you to print out every single message a user has posted. He also describes a method to alter the Yik Yak installation on a rooted iPhone so that the app runs under the victim’s user ID. This gives you full access as if you owned the account yourself.

Oh, there’s another problem too. The Android app is programmed to ignore bad SSL certificates. This means that any script kiddie can perform a simple man in the middle attack with a fake SSL certificate and the app will still function. It doesn’t even throw a warning to the user. This just allows for another method to steal a user ID.

So now you have control over some poor user’s account but at least they are still anonymous, right? That depends. The Yik Yak app itself appears to keep anonymity, but by analyzing the traffic coming from the client IP address can make it trivial to identify a person. First of all, [Sanford] mentions that a host name can be a dead giveaway. A host named “Joe’s iPhone” might be a pretty big clue. Other than that, looking out for user names and information from other unencrypted sites is easy enough, and that would likely give you everything you need to identify someone. Keep this in mind the next time you post something “anonymously” to the Internet.

[via Reddit]

The Last Week Of The Mooltipass Approacheth

December 8, 2014 by 46 Comments

A year and two days ago, [Mathieu] started out on a quest to develop some hardware with the help of Hackaday readers. This project became known as the Mooltipass, an open source offline password keeper that’s pretty much a password management suite or Post-It notes on a monitor, except not horribly insecure.

The product has gone through multiple iterations of software, [Mathieu] flew out to China to get production started, and the project finally made it to a crowdfunding site. That crowdfunding campaign is almost over with just eight days left and just a little bit left to tip this project into production. This is the last call, all hands in, and if you’re thinking about getting one of these little secure password-storing boxes, this is the time.

You can check out the Developed on Hackaday series going over the entire development of the Mooltipass, made with input from Mooltipass contributors and Hackaday readers. The Venn diagram of those two groups overlaps a lot, making this the first piece of hardware that was developed for and by Hackaday readers.

Even if you have a fool-proof system of remembering all your passwords and login credentials, the Mooltipass is still a very cool-looking Arduino-compatible board. Note that (security device) and (Arduino thing) are two distinct operating modes that should not be conflated.

[Mathieu] and other contributors will be in the comments below, along with a bunch of ‘security researchers’ saying how this device ‘is horrifying’, ‘full of holes’, and ‘a terrible idea’. One of these sets of people have actually done research. Guess which?

Arris Vulnerability

Bad Code Results In Useless Passwords

December 7, 2014 by 18 Comments

[HeadlessZeke] was excited to try out his new AT&T wireless cable box, but was quickly dismayed by the required wireless access point that came bundled with it. Apparently in order to use the cable box, you also need to have this access point enabled. Not one to blindly put unknown devices on his network, [HeadlessZeke] did some investigating.

The wireless access point was an Arris VAP2500. At first glance, things seemed pretty good. It used WPA2 encryption with a long and seemingly random key. Some more digging revealed a host of security problems, however.

It didn’t take long for [HeadlessZeke] to find the web administration portal. Of course, it required authentication and he didn’t know the credentials. [HeadlessZeke] tried connecting to as many pages as he could, but they all required user authentication. All but one. There existed a plain text file in the root of the web server called “admin.conf”. It contained a list of usernames and hashed passwords. That was strike one for this device.

[HeadlessZeke] could have attempted to crack the passwords but he decided to go further down this rabbit hole instead. He pulled the source code out of the firmware and looked at the authentication mechanism. The system checks the username and password and then sets a cookie to let the system know the user is authenticated. It sounds fine, but upon further inspection it turned out that the data in the cookie was simply an MD5 hash of the username. This may not sound bad, but it means that all you have to do to authenticate is manually create your own cookie with the MD5 hash of any user you want to use. The system will see that cookie and assume you’ve authenticated. You don’t even have to have the password! Strike two.

Now that [HeadlessZeke] was logged into the administration site, he was able to gain access to more functions. One page actually allows the user to select a command from a drop down box and then apply a text argument to go with that command. The command is then run in the device’s shell. It turned out the text arguments were not sanitized at all. This meant that [HeadlessZeke] could append extra commands to the initial command and run any shell command he wanted. That’s strike three. Three strikes and you’re out!

[HeadlessZeke] reported these vulnerabilities to Arris and they have now been patched in the latest firmware version. Something tells us there are likely many more vulnerabilities in this device, though.

[via Reddit]