Hacking Oklahoma State University’s Student ID Cards

February 25, 2015 by Rick Osgood 39 Comments

[Sam] took an information security class at Oklahoma State University back in 2013. For his final project, he and a team of other students had to find a security vulnerability and then devise a theoretical plan to exploit it. [Sam’s] team decided to focus on the school’s ID cards. OSU’s ID cards are very similar to credit cards. They are the same size and shape, they have data encoded on a magnetic strip, and they have a 16 digit identification number. These cards were used for several different purposes. Examples include photo ID, physical access to some areas on campus, charges to an online account, and more.

[Sam] and his team analyzed over 100 different cards in order to get a good sample. They found that all cards started with same eight digits. This is similar to the issuer identification number found in the first six digits of a credit card number. Th analysis also showed that there were only three combinations used for the next two digits. Those were either 05, 06, or 11. With that in mind, the total possible number of combinations for card numbers was mathematically calculated to be three million.

OSU also had a URL printed on the back of each card. This website had a simple form with a single field. The user can enter in a 16 digit card number and the system would tell the user if that card was valid. The page would also tell you if the card holder was an employee, a student, or if there were any other special flags on the card. We’re not sure why every student would need access to this website, but the fact is that the URL was printed right on the back of the card. The website also had no limit to how many times a query could be made. The only hint that the university was aware of possible security implications was the disclaimer on the site. The disclaimer mentioned that usage of the tool was “logged and tracked”.

The next step was to purchase a magnetic card reader and writer. The team decoded all of the cards and analyzed the data. They found that each card held an expiration date, but the expiration date was identical for every single card. The team used the reader/writer to copy the data from [Sam’s] card and modify the name. They then wrote the data back onto a new, blank magnetic card. This card had no printing or markings on it. [Sam] took the card and was able to use it to purchase items from a store on campus. He noticed that the register reached back to a server somewhere to verify his real name. It didn’t do any checks against the name written onto the magstripe. Even still, the cashier still accepted a card with no official markings.

The final step was to write a node.js script to scrape the number verification website. With just 15 lines of code, the script will run through all possible combinations of numbers in a random sequence and log the result. The website can handle between three and five requests per second, which means that brute forcing all possible combinations can be completed in roughly two days. These harvested numbers can then be written onto blank cards and potentially used to purchase goods on another student’s account.

[Sam’s] team offers several recommendations to improve the security of this system. One idea is to include a second form of authorization, such as a PIN. The PIN wouldn’t be stored on the card, and therefore can’t be copied in this manner. The primary recommendation was to take down the verification website. So far OSU has responded by taking the website offline, but no other changes have been made.

Deleting Facebook Albums Without Permission

February 15, 2015 by Rick Osgood 17 Comments

[Laxman] was poking around Facebook looking for security vulnerabilities. Facebook runs a bug bounty program which means if you can find a vulnerability that’s serious enough, it can earn you cold hard cash. It didn’t take much for [Laxman] to find one worthy of a bounty.

The graph API is the primary way for Facebook apps to read and write to the Facebook social graph. Many apps use this API, but there are limitations to what it can do. For example, the API is unable to delete users’ photo albums. At least, it’s not supposed to be able too. [Laxman] decided to test this claim himself.

He started by sending a command to delete one of his own albums using a graph explorer access token. His request was denied. The application didn’t have the correct permissions to be able to perform that action. It seemed that Facebook was correct and the API was unable to delete photos. [Laxman] had another trick up his sleeve, though. He noticed that the wording of the response suggested that other apps would have the ability to delete the albums, so he decided to check the Facebook mobile application.

He decided to send the same request with a different token. This time he used a token from the Facebook for Mobile application. This actually worked, and resulted in his photo album being deleted. To take things a step further, [Laxman] sent the same requests, but changed the user’s ID to a victim account he had set up. The request was accepted and processed without a problem. This meant that [Laxman] could effectively delete photo albums from any other user without that user’s consent. The vulnerability did require that [Laxman] had permission to view the album in the first place.

Since [Laxman] is one of the good guys, he sent this bug in to the Facebook team. It took them less than a day to fix the issue and they rewarded [Laxman] $12,500 for his trouble. It’s always nice to be appreciated. The video below shows [Laxman] walking through how he pulled off this hack using Burp Suite. Continue reading “Deleting Facebook Albums Without Permission” →

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

December 10, 2014 by Rick Osgood 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” →

Bad Code Results In Useless Passwords

December 7, 2014 by Rick Osgood 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]

Hiding Executable Javascript In Images That Pass Validation

November 15, 2014 by Mike Szczys 18 Comments

Here’s an interesting proof-of-concept that could be useful or hazardous depending on the situation in which you encounter it. [jklmnn] drew inspiration from the work of [Ange Albertini] who has documented a way to hide Javascript within the header of a .gif file. Not only does it carry the complete code but both image and the Javascript are seen as valid.

With just a little bit of work [jklmnn] boiled down the concept to the most basic parts so that it is easy to understand. Next, a quick program was written to automate the embedding of the Javascript. Grab the source code if you want to give it a try yourself.

Let’s get back to how this might be useful rather than harmful. What if you are working on a computer that doesn’t allow the browser to load Javascript. You may be able to embed something useful, kind of like the hack that allowed movies to be played by abusing Microsoft Excel.

Raiders Of The Lost ROM

September 14, 2014 by Rick Osgood 29 Comments

Once upon a time, arcades were all the rage. You could head down to your local arcade with a pocket full of quarters and try many different games. These days, video arcades are less popular. As a result, many old arcade games are becoming increasingly difficult to find. They are almost like the artifacts of an ancient age. They are slowly left to rot and are often lost or forgotten with time. Enter, MAME.

MAME (Multiple Arcade Machine Emulator) is a software project, the goal of which is to protect gaming history by preventing these arcade machines from being lost or forgotten. The MAME emulator currently supports over 7000 titles, but there are still more out there that require preservation. The hackers who work on preserving these games are like the digital Indiana Jones of the world. They learn about lost games and seek them out for preservation. In some cases, they must circumvent security measures in order to accurately preserve content. Nothing as scary as giant rolling boulders or poison darts, but security nonetheless.

Many of the arcade cabinets produced by a publisher called NMK used a particular sound processor labeled, “NMK004”. This chip contains both a protected internal code ROM and an unprotected external ROM that controls the sound hardware. The actual music data is stored on a separate unprotected EEPROM and is different for each game. The system reads the music data from the EEPROM and then processes it using the secret data inside the NMK004.

The security in place around the internal ROM has prevented hackers from dumping its contents for all this time. The result is that NMK games using this chip have poorly emulated sound when played using MAME, since no one knows exactly how the original chip processed audio. [trap15] found it ridiculous that after 20 years, no one had attempted to circumvent the security and dump the ROM. He took matters into his own hands.

The full story is a bit long and contains several twists and turns, but its well worth the read. The condensed version is that after a lot of trial and error and after writing many custom tools, [trap15] was able to finally dump the ROM. He was able to accomplish this using a very clever trick, speculated by others but never before attempted on this hardware. [trap15] exploited a vulnerability found in the unprotected external ROM in order to trick the system into playing back the protected internal ROM as though it were the sound data stored on the EEPROM. The system would read through the internal ROM as though it were a song and play it out through the speakers. [trap15] recorded the resulting audio back into his PC as a WAV file. He then had to write a custom tool to decode the WAV file back into usable data.

[trap15] has released all of his tools with documentation so other hackers can use them for their own adventures into hardware hacking. The project was a long time in the making and it’s a great example of reverse engineering and perseverance.

[Thanks Ryan]

A Better Way To Hack IClass RFID Readers

November 20, 2012 by Mike Szczys 18 Comments

iClass is an RFID standard that is aimed at better security through encryption and authentication. While it is more secure than some other RFID implementations, it is still possible to hack the system. But initial iClass exploits were quite invasive. [Brad Antoniewicz] published a post which talks about early attacks on the system, and then demonstrates a better way to exploit iClass readers.

We remember seeing the talk on iClass from 27C3 about a year and a half ago. While the technique was interesting, it was incredibly invasive. An attacker needed multiple iClass readers at his disposal as the method involved overwriting part of the firmware in order to get a partial dump, then patching those image pieces back together. [Brad] makes the point that this is fine with an off-the-shelf system, but high-security installations will be using custom images. This means you would need to get multiple readers off the wall of the building you’re trying to sneak into.

But his method is different. He managed to get a dump of the EEPROM from a reader using an FTDI cable and external power source. If you wan to see how he’s circumventing the PIC read protection you’ll have to dig into the source code linked in his article.