Three Simple Steps To Prevent Hacks Like The Uber Hack

Omar Masri
3 min readDec 1, 2017

I use Uber and UberEats, so the recent news about a 2016 Uber data breach really hits close to home. Hackers stole the names, e-emails, and phone numbers of 57 million Uber riders and drivers along with driver license numbers of around 600,000 drivers. What’s really scary is that according to hackmageddon.com the Uber attack was one of hundreds of attacks in 2016, with attacks in 2017 already doubling.

If you have data in databases that you want to secure, then you’re going to love this blog post. I’m going to show you three simple steps that any business, regardless of size or network complexity, can do to keep their data safe. This would have definitely prevented the Uber hack.

Up front, I want to clarify that I’m not a security expert, I’m a database and data infrastructure expert. Security experts focus on all the network layers, application secret management solution, people, and policy around things that access a database. While database experts consider all those layers compromised and secure the database regardless of the extra layers.

Details of the Uber hack

According to news sources the following occurred:

  • Developers hard-coded credentials in their code, and then checked the code into a Github repository, which was accessed by the hackers.
  • Hackers then used a VPN service to hide their attack IP address, connected to the UBER cloud AWS driver database, and extracted the data.

The response to the attack from security experts was typical. They focused on GitHub security, developer practices for secrets management, and AWS AIM management. Unfortunately, none of them focused on the single most critical flaw; the fact that a random European IP address could access the database.

Three steps to prevent a hack

  1. Restrict IP database access to only a known set of servers by using a simple firewall or whitelisting IP addresses to your cloud databases. This alone would have prevented the Uber data breach.
  2. Require that all ad hoc human access to databases be secured through a database multi-factor access solution like Cirro Secure Connect from cirro.com. Secure Connect gives you a single multi-factor login to all your databases across all your different networks, using your standard client tools. It doesn’t require any database changes or agents, and works across all database types and versions. It is a load-and-go secure DB access server. Click to see an example of DB MFA via SAASPASS
  3. If possible, avoid using shared .pem keys or named logins to access production servers or any machines that could be used as jump boxes.

Just implementing Cirro Secure Connect will allow you to publicly publish your database credentials and database IP addresses and still be confident that hackers won’t be able to steal your data.

To prove this works, I have a publicly exposed Postgres database server that I can connect to via my Cirro server from any external IP in the world.

Below are the details. I challenge anyone to hack it.

Machine IP : hackmeifyoucan.cirro.com (104.131.129.20)

UserName : postgres

Password : password

Editors Note: Put a WEBGAP between you and the malware with a browser isolation technology or by leveraging a remote browser service.

--

--