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”
[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.
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.
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.
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.
When you think about hacking laptops, it’s highly unlikely that you would ever consider the battery as a viable attack vector. Security researcher [Charlie Miller] however, has been hard at work showing just how big a vulnerability they can be.
As we have been discussing recently, the care and feeding of many batteries, big and small, is handled by some sort of microcontroller. [Charlie] found that a 2009 update issued by Apple to fix some lingering MacBook power issues used one of two passwords to write data to the battery controllers. From what he has seen, it seems these same passwords have been used on all batteries manufactured since that time as well. Using this data, he was subsequently able to gain access to the chips, allowing him to remotely brick the batteries, falsify data sent to the OS, and completely replace the stock firmware with that of his own.
He says that it would be possible for an attacker to inject malware into the battery itself, which would covertly re-infect the machine, despite all traditional removal attempts. Of course, replacing the battery would rectify the issue in these situations, but he says that it would likely be the last thing anyone would suspect as the source of infection. While using the battery to proliferate malware or cause irreversible damage to the computer would take quite a bit of work, [Charlie] claims that either scenario is completely plausible.
He plans on presenting his research at this year’s Black Hat security conference in August, but in the meantime he has created a utility that generates a completely random password for your Mac’s battery. He says that he has already contacted Apple to in order to help them construct a permanent fix for the issue, so an official patch may be available in the near future.