Last week, news broke over a data breach at Uber’s cloud servers in 2016, which resulted in the loss of data belonging to 57 million customers and drivers. At the time of the incident, instead of disclosing the news to the public and warning affected users, Uber’s security team forked over $100,000 to the hackers, asking them to delete the data and remain silent.
Though the hackers remained true to their end of the bargain, the breach didn’t remain secret. More than a year later, a board-commissioned investigation into the security team’s work uncovered it. Consequently, the company fired Joe Sullivan, its chief security officer, and Craig Clark, a senior lawyer who reported to Sullivan.
After its disclosure, the hack has become the subject of an investigation by the New York Attorney General. Uber is also looking at a class action lawsuit for its negligence in handling the data breach.
But the reshuffling of the executives will do little good to the 50 million customers whose names, email addresses and telephone numbers were spilled. Neither will it help the 7 million drivers who were affected by the hack, including 600,000 whose driver’s license numbers were included in the trove of lost data. Other hackers will probably seek the information and combine it with other data points to stage phishing scams, identity theft, or other cyberattacks.
In fairness to Uber, Equifax’s disastrous data breach earlier this year was far worse than that of the ride-sharing giant both in size and sensitivity of the information. Nonetheless, Uber’s hack and the company’s poor handling of it does have some important takeaways and critical reminders.
Here’s what we learned.
Executives: Hiding security incidents is a bad idea
The first thing that other CSOs, CISOs and other executives that make decisions should take away from Uber’s fiasco is that erasing data breaches is impossible, especially one of this magnitude. Things will eventually surface and until they do, you’ll always have to look over your shoulder. Meanwhile, the cover-up also prevented the company from warning the affected users of the compromise of their data and helping them protect themselves against potential cyberattacks.
But what’s worse is trying to cover it up by paying hackers under the guise of paying for a bug bounty. As was predictable, the $100,000 bribe to the attackers didn’t help much in hiding the hack. But more generally, paying hackers also has the negative effect of encouraging extortion and turning their crimes into a lucrative business.
In retrospect, if the Uber security team has chosen transparency, they would’ve saved a hundred thousand dollars, helped customers protect themselves against future attacks, prevent more damage against the already damaged reputation of the company, avoided a potential fine that will be slapped against Uber for mishandling the incident. Oh yeah, and they probably would’ve kept their jobs. I don’t know about you, but when I weigh all that against the one-year cover-up of the hack, I know which one I’d choose.
Developers: Storing credentials in source code is bad practice—and more so on Github
Uber lost the 57 million user records because the hackers were able to gain access to a private Github account the company’s developers used. In case you don’t already know, Github is an online platform where developers can collaborate on projects, track bugs, and distribute early versions of software. Many open-source projects use Github as the main hub to distribute and maintain their software.
It’s not clear how hackers gained access to the private Github account. But what’s for certain is that the source code stored in the Github account contained plain text login credentials to one of Uber’s Amazon servers. That’s where the stolen data was stored.
Programmers frequently add credentials to their source code to allow their software to access privileged data or services automatically. And when they publish that source code on publicly accessible platforms such as Github, they don’t do enough to restrict access to it. This means anyone searching through their code can find those credentials.
This isn’t the first time that Uber is making ill use of Github. In 2015, a security key stored in a public Github account belonging to Uber allowed hackers to access the data of 50,000 drivers.
Neither is Uber the only company to have Github credential mishaps. In 2016, Slack developers were found to post their Slack login credentials on publicly available GitHub accounts. All hackers needed to do was search those accounts for the prefix to the login credentials.
Instead of opting for the easier-to-setup username/password scheme, developers should usually look for alternatives when linking software and services. There are often other options, even if they require a few extra steps to setup. Play it safe, not easy.
Everyone: We really need to rethink how we store user data
The best way to protect user data is not to store it. I’ve previously discussed here the problem we’re currently facing. Service providers store a wealth of sensitive information about their users and often fail to take the necessary measures to protect that information. Meanwhile, the users, to whom the data belongs, have little or no control on how that data is stored and protected.
We need to be looking for alternative methods to store user information. One potential fix for the problem are blockchain-based data and identity platforms, where users are in charge of their own data. Some platforms are exploring the concept where users have their own secure repositories where they store their data. Under this model, applications no longer need to store user information. Instead they request access to specific data points in the user’s store.
Services that depend on gobbling up and mining user data won’t like relinquishing it, but given the disastrous incidents that are often coming to pass, they might want to rethink their strategy. If they don’t, they should prepare themselves for the day users come knocking on their doors to reclaim their precious data.