hacking

79 Articles

Uber Hack

Stumbling Upon An Uber Vulnerability

February 27, 2015 by 30 Comments

[Nathan] is a mobile application developer. He was recently debugging one of his new applications when he stumbled into an interesting security vulnerability while running a program called Charles. Charles is a web proxy that allows you to monitor and analyze the web traffic between your computer and the Internet. The program essentially acts as a man in the middle, allowing you to view all of the request and response data and usually giving you the ability to manipulate it.

While debugging his app, [Nathan] realized he was going to need a ride soon. After opening up the Uber app, he it occurred to him that he was still inspecting this traffic. He decided to poke around and see if he could find anything interesting. Communication from the Uber app to the Uber data center is done via HTTPS. This means that it’s encrypted to protect your information. However, if you are trying to inspect your own traffic you can use Charles to sign your own SSL certificate and decrypt all the information. That’s exactly what [Nathan] did. He doesn’t mention it in his blog post, but we have to wonder if the Uber app warned him of the invalid SSL certificate. If not, this could pose a privacy issue for other users if someone were to perform a man in the middle attack on an unsuspecting victim.

[Nathan] poked around the various requests until he saw something intriguing. There was one repeated request that is used by Uber to “receive and communicate rider location, driver availability, application configurations settings and more”. He noticed that within this request, there is a variable called “isAdmin” and it was set to false. [Nathan] used Charles to intercept this request and change the value to true. He wasn’t sure that it would do anything, but sure enough this unlocked some new features normally only accessible to Uber employees. We’re not exactly sure what these features are good for, but obviously they aren’t meant to be used by just anybody.

Facebook Bounty

Deleting Facebook Albums Without Permission

February 15, 2015 by 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” →

Using HID Tricks To Drop Malicious Files

January 27, 2015 by 38 Comments

[Nikhil] has been experimenting with human interface devices (HID) in relation to security. We’ve seen in the past how HID can be exploited using inexpensive equipment. [Nikhil] has built his own simple device to drop malicious files onto target computers using HID technology.

The system runs on a Teensy 3.0. The Teensy is like a very small version of Arduino that has built-in functionality for emulating human interface devices, such as keyboards. This means that you can trick a computer into believing the Teensy is a keyboard. The computer will treat it as such, and the Teensy can enter keystrokes into the computer as though it were a human typing them. You can see how this might be a security problem.

[Nikhil’s] device uses a very simple trick to install files on a target machine. It simply opens up Powershell and runs a one-liner command. Generally, this commend will create a file based on input received from a web site controlled by the attacker. The script might download a trojan virus, or it might create a shortcut on the user’s desktop which will run a malicious script. The device can also create hot keys that will run a specific script every time the user presses that key.

Protecting from this type off attack can be difficult. Your primary option would be to strictly control USB devices, but this can be difficult to manage, especially in large organizations. Web filtering would also help in this specific case, since the attack relies on downloading files from the web. Your best bet might be to train users to not plug in any old USB device they find lying around. Regardless of the methodology, it’s important to know that this stuff is out there in the wild.

Inventory Report

Security Problems With Gas Station Automated Tank Gauges

January 22, 2015 by 29 Comments

[HD Moore] recently posted an article on Rapid 7’s blog about an interesting security problem. They’ve been doing some research into the security of automated tank gauges (ATGs). These devices are used at gas stations and perform various functions including monitoring fuel levels, tracking deliveries, or raising alarms. [Moore] says that ATGs are used at nearly every fueling station in the United States, but they are also used internationally. It turns out these things are often not secured properly.

Many ATG’s have a built-in serial port for programming and monitoring. Some systems also have a TCP/IP card, or even a serial to TCP/IP adapter. These cards allow technicians to monitor the system remotely. The most common TCP port used in these systems is port 10001. Some of these systems have the ability to be password protected, but Rapid 7’s findings indicate that many of them are left wide open.

The vulnerability was initial reported to Rapid 7 by [Jack Chadowitz]. He discovered the problem due to his work within the industry and developed his own web portal to help people test their own systems. [Jack] approached Rapid 7 for assistance in investigating the issue on a much larger scale.

Rapid 7 then scanned every IPv4 address looking for systems with an open port 10001. Each live system discovered was then sent a “Get In-Tank Inventory Report” request. Any system vulnerable to attack would respond with the station name, address, number of tanks, and fuel types. The scan found approximately 5,800 systems online with no password set. Over 5,300 of these stations are in the United States.

Rapid 7 believes that attackers may be able to perform such functions as to reconfigure alarm thresholds, reset the system, or otherwise disrupt operation of the fuel tank. An attacker might be able to simulate false conditions that would shut down the fuel tank, making it unavailable for use. Rapid 7 does not believe this vulnerability is actively being exploited in the wild, but they caution that it would be difficult to tell the difference between an attack and a system failure. They recommend companies hide their systems behind a VPN for an additional layer of security.

[Thanks Ellery]

Mario Hack

Reprogramming Super Mario World From Inside The Game

January 22, 2015 by 72 Comments

[SethBling] recently set a world record speed run of the classic Super Nintendo game Super Mario World on the original SNES hardware. He managed to beat the game in five minutes and 59.6 seconds. How is this possible? He actually reprogrammed the game by moving specific objects to very specific places and then executing a glitch. This method of beating the game was originally discovered by Twitch user [Jeffw356] but it was performed on an emulator. [SethBling] was able to prove that this “credits warp” glitch works on the original hardware.

If you watch the video below, you’ll see [SethBling] visit one of the first available levels in the game. He then proceeds to move certain objects in the game to very specific places. What he’s doing here is manipulating the game’s X coordinate table for the sprites. By moving objects to specific places, he’s manipulating a section of the game’s memory to hold specific values and a specific order. It’s a meticulous process that likely took a lot of practice to get right.

Once the table was setup properly, [SethBling] needed a way to get the SNES to execute the X table as CPU instructions. In Super Mario World, there are special items that Mario can obtain that act as a power up. For example, the mushroom will make him grow in size. Each sprite in the game has a flag to tell the SNES that the item is able to act as a power up. Mario can either collect the power up by himself, or he can use his friendly dinosaur Yoshi to eat the power up, which will also apply the item’s effects to Mario.

The next part of the speed run involves something called the item swap glitch. In the game, Mario can collect coins himself, or Yoshi can also collect them by eating them. A glitch exists where Yoshi can start eating a coin, but Mario jumps off of Yoshi and collects the coin himself simultaneously. The result is that the game knows there is something inside of Yoshi’s mouth but it doesn’t know what. So he ends up holding an empty sprite with no properties. The game just knows that it’s whatever sprite is in sprite slot X.

Now comes the actual item swap. There is an enemy in the game called Chargin’ Chuck. This sprite happens to have the flag set as though it’s a power up. Normally this doesn’t matter because it also has a set flag to tell the game that it cannot be eaten by Yoshi. Also, Chuck is an enemy so it actually hurts Mario rather than act as a power up. So under normal circumstances, this sprite will never actually act as a power up. The developers never programmed the game to properly handle this scenario, because it was supposed to be impossible.

If the coin glitch is performed in a specific location within the level, a Chargin’ Chuck will spawn just after the coin is collected. When the Chuck spawns, it will take that empty sprite slot and suddenly the game believes that Yoshi is holding the Chuck in his mouth. This triggers the power up condition, which as we already know was never programmed into the game. The code ends up jumping to an area of memory that doesn’t contain normal game instructions.

The result of all of this manipulation and glitching is that all of the values in the sprite X coordinate table are executed as CPU instructions. [SethBling] setup this table to hold values that tell the game to jump to the end credits. The console executes them and does as commanded, and the game is over just a few minutes after it began. The video below shows the speed run but doesn’t get too far into the technical details, but you can read more about it here.

This isn’t the first time we’ve seen this type of hack. Speed runs have been performed on Pokemon with very similar techniques. Another hacker managed to program and execute a version of single player pong all from within Pokemon Blue. We can’t wait to see what these game hackers come up with next. Continue reading “Reprogramming Super Mario World From Inside The Game” →

PasswordManagerCode

Tearing Apart An Android Password Manager

January 18, 2015 by 22 Comments

With all of the various web applications we use nowadays, it can be daunting to remember all of those passwords. Many people turn to password management software to help with this. Rather than remembering 20 passwords, you can store them all in a (presumably) secure database that’s protected by a single strong password. It’s a good idea in theory, but only if the software is actually secure. [Matteo] was recently poking around an Android password management software and made some disturbing discoveries.

The app claimed to be using DES encryption, but [Matteo] wanted to put this claim to the test. He first decompiled the app to get a look at the code. The developer used some kind of code obfuscation software but it really didn’t help very much. [Matteo] first located the password decryption routine.

He first noticed that the software was using DES in ECB mode, which has known issues and really shouldn’t be used for this type of thing. Second, the software simply uses an eight digit PIN as the encryption key. This only gives up to 100 million possible combinations. It may sound like a lot, but to a computer that’s nothing. The third problem was that if the PIN is less than eight characters, the same digits are always padded to the end to fill in the blanks. Since most people tend to use four digit pins, this can possibly lower the total number of combinations to just ten thousand.

As if that wasn’t bad enough, it actually gets worse. [Matteo] found a function that actually stores the PIN in a plain text file upon generation. When it comes time to decrypt a password, the application will check the PIN you enter with the one stored in the plain-text file. So really, you don’t have to crack the encryption at all. You can simply open the file and reveal the PIN.

[Matteo] doesn’t name the specific app he was testing, but he did say in the Reddit thread that the developer was supposedly pushing out a patch to fix these issues. Regardless, it goes to show that before choosing a password manager you should really do some research and make sure the developer can be trusted, lest your secrets fall into the wrongs hands.

[via Reddit]

Paypal CSRF

Hacking PayPal Accounts With CSRF

December 4, 2014 by 17 Comments

The computer security industry has made many positive changes since the early days of computing. One thing that seems to be catching on with bigger tech companies is bug bounty programs. PayPal offers such a program and [Yasser] decided to throw his hat in the ring and see if he could find any juicy vulnerabilities. His curiosity paid off big time.

Paypal is a huge player in the payment processing world, but that doesn’t mean they aren’t without their flaws. Sometimes the bigger the target, the more difficult it is to find problems. [Yasser] wanted to experiment with a cross-site request forgery attack. This type of attack typically requires the attacker to trick the victim into clicking a malicious link. The link would then impersonate the victim and make requests on the victim’s behalf. This is only made possible if the victim is logged into the target website.

PayPal has protection mechanisms in place to prevent this kind of thing, but [Yasser] found a loophole. When a user logs in to make a request, PayPal gives them an authentication token. This token is supposed to be valid for one user and one request only. Through experimentation, [Yasser] discovered a way to obtain a sort of “skeleton key” auth token. The attacker can attempt to initiate a payment transfer without first logging in to any PayPal account. Once the transfer is attempted, PayPal will request the user to authenticate. This process produces an auth token that apparently works for multiple requests from any user. It renders the authentication token almost entirely ineffective.

Once the attacker has a “universal auth token”, he can trick the victim into visiting a malicious web page. If the user is logged into their PayPal account at the time, the attacker’s webpage can use the universal auth token to trick the victim’s computer into making many different PayPal requests. Examples include adding email addresses to the account, changing the answers to security questions, and more. All of this can be done simply by tricking the user into clicking on a single link. Pretty scary.

[Yasser] was responsible with his disclosure, of course. He reported the bug to PayPal and reports that it was fixed promptly. It’s always great to see big companies like PayPal promoting responsible disclosure and rewarding it rather than calling the lawyers. Be sure to catch a video demonstration of the hack below. Continue reading “Hacking PayPal Accounts With CSRF” →