Who’s Driving Security for Uber?

The news was just released that a massive breach hit Uber in October of 2016. The personal information of 57 million Uber users and 7 million Uber drivers were stolen, including names, email addresses and phone numbers. In addition, about 600,000 drivers’ license numbers of Uber drivers were also stolen. This type of breach typically warrants a notification to the affected users as well as notification to regulators of the breach. Instead, Uber paid the hackers $100,000 to ‘delete’ the data and not go public with the breach. Today Uber fired the CISO and a deputy of the CISO because of their role in covering up the breach.

What’s even more troubling is the fact that this breach occurred while Uber was being investigated for a breach that occurred a few years earlier. Instead of coming clean and informing affected users, Uber decided to cover up the breach and not inform anyone affected. It also paid the hackers $100,000 to ‘delete’ the data and not go public. There’s absolutely no assurances the hackers deleted this data; they could still have it and hold it for ransom whenever they want.

Uber has truly failed in their duty to their customers to protect their privacy, and even went so far as to actively prevent their users from finding out that a breach took place. This is simply unacceptable. Companies need to protect themselves from breaches wherever possible, but if a breach does occur, they have an obligation to their user base to inform them they could be at risk.

So what happened? How did the hackers gain this data? Unfortunately, this seems to be a very easy attack. The hackers first went to one of Uber’s public GitHub repositories. The attackers scoured the files in the GitHub repository and eventually found credentials which allowed them to login to Uber’s AWS account. The AWS account had archives of personal rider and driver information. So in a nutshell, all the attacker had to do was look through GitHub, find some creds, login to AWS and download data. Way too easy.

At it’s heart, this is what we at WhiteHat classify as a hard coded password or a clear text password depending on what file the credentials are in. It’s an easy mistake to make. A developer, trying to make their life easier puts the credentials somewhere in a comment in the code, or creates a text file so they can easily remember it. It also allows other that are reviewing the code to quickly understand what they were doing and how to access whatever account needed to be accessed. Configuration file, text files and property files are also sometimes used to store these credentials for similar reasons. They then either forget to take the credentials out, or thinks since it’s only source code or on a file on GitHub that no one will ever see. Uber proves that this thinking is flawed. Passwords should never be written down anywhere in the code or stored anywhere in the repository. You can never be sure where the code will end up and who will have access to it and the files.

At WhiteHat we find this vulnerability regularly with our Static Analysis service. If you are a WhiteHat SAST customer you are already being scanned for this. Users are encouraged to look through their Sentinel interface and search for Authentication.Password.HardCoded and Authentication.Password.Cleartext. If either of these vulnerabilities are present in your findings, take immediate action to remove these credentials from the effected files. It’s that easy!

Cookie Use

We use cookies to store information on your computer that are either essential to make our site work or help us personalize and improve the user experience. By using this site, you consent to the placement of these cookies. To learn more, see our Cookie Policy.