Why Organizations Are Still Learning From the Uber Breach

Photo by Dan Freeman on Unsplash

This has been a rough month for Vasile Mereacre and Brandon Glover. These two gentlemen were arrested for their parts as the hackers who stole millions of users’ data from Uber in 2016, and were also indicted on federal hacking and extortion charges for stealing user data from 55,000 accounts of LinkedIn’s Lynda service. The ensuing legal drama will make headlines, fingers will be pointed, and ultimately Mereacre and Glover will spend significant time in prison.

The Uber breach was huge; the CSO was fired, more than a dozen were lawsuits filed, massive fines have been levied, and incalculable damage to Uber’s brand will linger for a long time. But the story didn’t start, nor will it stop, with hackers.

The issue with both the Uber and Lynda breaches is that doors to valuable data were left wide open, and while there is no excuse for what Mereacre and Glover did, there is still culpability on the part of companies and IT organizations who do not take the necessary measures to understand what’s happening in their environments. Awareness of security risk and its ramifications is now part of the landscape of IT organizations. Inaction is no longer an option.

However, awareness is apparently not enough because it’s not working. People who are responsible for security operations know how to thwart breaches and gird organizations against vulnerabilities, yet AWS buckets are continually left open when they should be closed, dead accounts available to provide masked access to unauthorized users, and cloud accounts continue to be fertile ground for bad actors to ply their trade under cover of darkness.

The Uber breach gives us insight into the ease of hacking into an AWS environment and the magnitude of ensuing damage. It also calls into question the ability, in this day and age, and with the technology available, how this could happen. At Lacework, we work with organizations who specifically want to avoid the fate of Uber and look to us to provide the foundation for doing so.

From many analyses of the breach, we know that the company did not implement cloud security best practices or policies about AWS rules and policies. Culturally, the organization did not operate with a security perspective, but it also allowed for basic elements of their AWS environment to be vulnerable.

In fact, an FTC investigation discovered the following:

• Employees and contractors with legitimate access to data were not required to use multi-factor authentication.
• An automated tool used to monitor employee access to driver and customer data was abandoned less than a year after being deployed.
• There was a failure to require the use of distinct access keys. This resulted in virtually all company engineers to use a single AWS key to access the company’s entire S3 datastore.
• As far back as 2014, employees across the company had access to a tool called “God view” that tracked user’s rides and other user data.
• User PII was stored in an AWS S3 bucket in, “clear, readable text – rather than encrypting the information”
• An Uber engineer publicly posted an access key to GitHub, and hackers were able to access files containing 100,000+ files containing Uber customer PII.

Specifically, the FTC called out Uber for their failures of data and user protection in two ways: “…first by misrepresenting the extent to which it monitored its employees’ access to personal information about users and drivers, and second by misrepresenting that it took reasonable steps to secure that data.”

This is what we at Lacework talk to customers about every day. Public cloud is still relatively new for many, but it’s not some esoteric thing. It’s complex and a bit gnarly in its vastness, but between the smart application of best practices and automated, continuous monitoring, organizations can gain control over their cloud environments and begin to exercise a strategy of rapid response for critical issues.

Many security vendors look at the public cloud as a series of different components, each of which needs a unique solution. At Lacework, we approach things with an understanding that the best type of awareness comes from a comprehensive view. Rather than just inspect CloudTrail logs, network flows, or focus just on the configurations of AWS accounts, we apply an automated approach over every activity that happens in your cloud. The Lacework agent is deployed into the cloud to scan configurations, credentials, and all activities that store and transact data. The agent consumes and processes raw kernel audit events occurring in account events. That data is analyzed at a behavioral level and anomalies are identified based on deviations from normalized behavior. From that analysis, the Lacework platform makes qualified decisions about abnormal behavior that requires alerts.

Rather than just looking for an “either/or” scenarios, Lacework takes into account what constitutes normal activity, which means organizations can make changes to rules and policies without getting false alerts for things they have approved. It also means abnormal and nefarious activity is caught immediately, rather than having to be investigated manually.

Put that all into the context of the Uber scenario. Lacework analyzes and systematically baselines the behaviors of all users who SSH into the server hosts within an AWS cloud. Since the Uber attack was a server-side breach, an agent deployed inside the environment would have been able to generate deep insights into what this activity means and issue actionable and immediate alerts on whether users are doing anything out of the ordinary.

Because Lacework uses an agent that is deployed across hosts in EC2, we would have been able to alert Uber’s security team precisely when the hackers assumed the role of the Uber engineer and illicitly accessed the hosts. Vasile Mereacre was able to access Uber’s environment through an SSH session to an Uber host in AWS from an unknown IP address in Canada. Once connected to that host, Vasile had free access to Uber’s S3 bucket containing the customer and driver data he eventually exfiltrated. This sequence of behavior was anomalous for that

Uber needed this level of awareness; they also needed to codify this type of approach across their cloud security operations. But awareness by itself is only part of the solution. Applying a checklist methodology just doesn’t work and it can’t scale, so automating is also essential. Seeing the users, resources, applications, and other elements of the cloud as connected is also important. Unfortunately for them, the cost was more than $148 million in legal settlements, as well as the ensuing brand damage which continues to throw shade on them today.

Hackers will continue to innovate and test the limits of unguarded organizations. It’s the job of the caretakers of data to use the tools available to them and apply smart practices to prevent another Uber-type of disaster. It’s within reach, and with the right alignment of tools, priorities, and best practices, organizations can do the right thing and protect their own assets and the privacy of their users.