Stumbling Upon an Uber Vulnerability

[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.

ChipWhisperer Hits Kickstarter

Even the most well designed crypto algorithms can be broken if someone is smart enough to connect an oscilloscope to a processor. Over the last 15 years or so, an entire domain of embedded security has cropped up around the techniques of power and side channel analysis. The tools are expensive and rare, but [Colin O’Flynn] and the ChipWhisperer are here to bring a new era of hardware security to the masses.

The ChipWhisperer was the second place winner of last year’s Hackaday Prize. It’s an interesting domain of security research, and something that was previously extremely expensive to study. If you’re looking for a general overview of what the ChipWhisperer does, you might want to check out when we bumped into [Colin] at DEFCON last year.

While the original goal of the ChipWhisperer was to bring the cost of the tools required for power and side channel analysis down to something a hackerspace or researcher could afford, this was still too expensive for a Kickstarter campaign. To that end, [Colin] designed the ChipWhisperer Lite, a cut-down version, but still something that does most of what the original could do.

There are two parts to the ChipWhisperer Lite – the main section contains a big microcontroller, a big FPGA, and a high gain, low noise amplifier. This is the core of the ChipWhisperer, and it’s where all the power analysis happens. The other part is a target board containing an XMega microcontroller. This is where you’ll run all your encryption algorithms, and where you’ll find out if they can be broken by power analysis. The main board and target board are held together by a break-away connection, so if you want to run a power analysis on another board, just snap the ChipWhisperer in half.

[Colin] is offering up a ChipWhisperer Lite for around $200 USD – far, far less than what these tools cost just a year ago. We’re looking forward to a successful campaign and all the neat findings people with this board will find.

Hacking Oklahoma State University’s Student ID Cards

[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.

Another Garage Door Opener, This Time With Security

We’ve been seeing a lot of garage door opener hacks, whether it’s because one person inspired everyone else to build their own Internet-connected GDO or because there’s something in the water that’s caused the simultaneous building of one specific type of project, we’re not sure. However, the latest one we’ve seen adds a little something extra: motion-based security.

[DeckerEgo] really went all out with this one, too. The core of the project is a Raspberry Pi hardwired to a universal garage door remote. The Pi also handles a small webcam and runs a program called motion, which is a Linux program that allows for all kinds of webcam fun including motion detection. While the other builds we see usually use a button or limit switch to tell whether the door is open or closed, this one just watches the door with the webcam so [DeckerEgo] can actually see what’s going on in the garage. As a bonus, the motion software can be configured to alert him if anything suspicious is going on in the garage.

The build is full-featured as well, with an interesting user interface overlaid on the live picture of the garage door. According to [DeckerEgo] the camera is a necessity because he wouldn’t trust a simple status indicator, but if you wanted to try one of those before breaking out the Raspberry Pi, we’ve featured one recently that you can check out.

AES-CMAC on an ATtiny85

[Blancmange] built a custom door chime using an ATtiny85. Unlike most commercial products out there, this one actually tries to be secure, using AES-CMAC for message signing.

The hardware is pretty simple, and a protoboard layout is shown in the image above. It uses the ATtiny85 for control, with an LM380N audio amplifier, and a low cost 315 MHz receiver.

The more impressive part of the build is the firmware. Using AVR assembly, [Blancmange] managed to fit everything into the 8 Kbytes of flash on the ATtiny85. This includes an implementation of AES-CMAC, an AES cypher based message authentication code. The transmitting device signs the request with a key shared between both devices, and the receiver verifies that the message is from a trusted transmitter.

Fortunately, the assembly code is very well commented. If you’ve ever wanted to take a look into some complex ASM assembly, this is a great project to check out. The source code has been released into the public domain, so the rest of us can implement crypto on this cheap microcontroller with much less effort.

Deleting Facebook Albums Without Permission

[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”

War Gaming for Security Cred

Maybe you are an elite hax0r. But probably not. Maybe you feel like you should know more about how systems are compromised, and we’re all about that. You can’t keep the black hats out if you have no idea how they go about breaking in in the first place. That’s why war-gaming sites sprouted up in the first place. We find this one in particular to be delightfully engaging. OverTheWire’s Wargames teach you a little about security while the uninitiated also learn about simple concepts like SSH and, well… Linux!

On-the-job training is the best way to learn, and this is pretty close to it. Instead of providing an artificial avenue of learning the creators of OverTheWire have used the real thing to illustrate poor online security. You don’t “play the game” on an artificial web interface, you do it on legitimate platforms. The very first level (appropriately named Level 0) starts by figuring out how to connect to a system using Secure Shell (aka SSH). From there you’re prompted to use Linux command line tools to figure out where to go next.

Even veteran Linux/Security users should find this offering entertaining. The early stages are both quick and simple to navigate as an experienced admin while providing a welcoming learning platform for those who aren’t quite there yet. Work your way through a few different “servers” and before long your own knowledge will be tested. This isn’t a new platform, mentions of the site in Hackaday comments go back to 2010. But if you haven’t given it a try, Wargames is well worth adding to your weekend entertainment list.

[Thanks NightPhoenix]