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.

Researchers Claim That HP Laser Printers Can Be Hijacked To Steal Data And Catch Fire

November 30, 2011 by Mike Nathan 36 Comments

hp-laserprinter-security-holes

The news was abuzz yesterday with coverage of a study released by Columbia University researchers warning consumers that HP laser printers are wide open to remote tampering and hacking. The researchers claim that the vast majority of printers from HP’s LaserJet line accept firmware updates without checking for any sort of digital authentication, allowing malicious users to abuse the machines remotely. The researchers go so far as to claim that modified firmware can be used to overheat the printer’s fuser, causing fires, to send sensitive documents to criminals, and even force the printers to become part of a botnet.

Officials at HP were quick to counter the claims, stating that all models built in 2009 and beyond require firmware to be digitally signed. Additionally, they say that all of the brand’s laser printers are armed with a thermal cutoff switch which would mitigate the fuser attack vector before any real fire risk would present itself. Despite HP’s statements, the researchers stand by their claims, asserting that vulnerable printers are still available for purchase at major office supply stores.

While most external attacks can easily be prevented with the use of a firewall, the fact that these printers accept unsigned firmware is undoubtedly an interesting one. We are curious to see if these revelations inspire anyone to create their own homebrew LaserJet firmware with advanced capabilities (and low toner warning overrides), or if this all simply fizzles out after a few weeks.