High profile AWS breaches & how to avoid them

A few days before Christmas 2021, employees and clients of appointment scheduling service Flexbooker realized threat actors had taken ten million lines of customer ID information – including photos, driver’s licenses, and hashed passwords. 

Attackers made off with millions of pieces of personally identifiable information (PII) because Flexbooker had misconfigured its AWS account, specifically an AWS S3 bucket that left its contents exposed to the public. This AWS breach was big news – but not because it was novel.  Capital One, Twilio, Uber, and more have all suffered AWS breaches, too. In these cases, attackers hadn’t breached AWS itself but had breached a company via an AWS misconfiguration.

Despite the breadth of these breaches, the root of cloud security problems is typically the same: misconfigurations. Cloud security is built on a shared responsibility model, which means that the provider keys the infrastructure securely, but it's up to the customer to deploy their applications in a secure manner — all environments, not just prod. In most cases, simple misconfigurations of deployed applications or services leave gaps just big enough for a breach.

In this article, we’re going to explain some of the high-profile AWS security breaches that have happened in the past few years due to misconfigurations and explore how you can prevent breaches with better security practices. 

Capital One: A misconfigured firewall affects 100 million customers 

In July 2019, major bank and financial services provider Capital One revealed that a former Amazon employee had hacked its AWS servers. 

The hack affected over 100 million customers and exposed personally identifiable information like Social Security Numbers, bank account numbers, credit scores, and more. Amazon has been clear that AWS was not at fault and that the underlying cloud services weren’t compromised. Instead, as Capital One admitted, the hacker gained access via a misconfigured open source Web Application Firewall (WAF). 

Customers filed a class action lawsuit that Capital One settled, granting customers as much as $25,000 per claim. Claimants argued Capital One "knew of the particular security vulnerabilities that permitted the data breach" but didn’t fix them. Capital One didn’t agree or disagree with the suit, instead saying it would settle "in the interest of avoiding the time, expense and uncertainty of continued litigation."

Pegasus Airlines: An unprotected S3 bucket exposes 6.5 terabytes of data

In May 2022, Turkish airline Pegasus Airlines discovered, via the work of a security firm, that it had misconfigured an AWS S3 bucket. The bucket contained sensitive flight data, including flight charts, navigation materials, and the personally identifiable information of numerous employees. 

The open S3 bucket also revealed some of the company’s source code, which contained plain-text passwords and secret keys – both of which potential attackers could have used to access even more sensitive data. 

In total, the security firm found almost 23 million exposed files – about 6.5 terabytes of data. They noted that “This exposure could impact the safety of every Pegasus passenger and crew member around the world.”

The security firm notified Pegasus Airlines and, according to the firm, “The AWS S3 bucket was promptly secured and PegasusEFB later replied, thanking us for the notification.”

Twilio: An exposed S3 bucket enables attackers to inject malicious code

In July 2020, cloud communications company Twilio confirmed attackers accessed a misconfigured S3 bucket and modified the JavaScript SDK for its tool TaskRouter. 

Attackers used a misconfiguration in the S3 bucket that hosted the library for Twilio’s TaskRouter JS SDK (TaskRouter is a tool that Twilio customers can use to route tasks). Once altered by the attack, the library made browsers load an extra URL – one that people later linked to the infamous Magecart attacks. 

Twilio explained in a disclosure that they remediated the incident within fifteen minutes and reconfigured the S3 bucket an hour later. Further, Twilio said the attackers neither gained access to customer data nor internal systems. 

Twilio was transparent, explaining that “We had not properly configured the access policy for one of our AWS S3 buckets.” Twilio implemented this particular path in 2015 and, at the time, it was not vulnerable. But a few months later, Twilio explained, the company didn’t “properly reset” permissions after troubleshooting a problem. 

Uber: Weak authentication revealed secret keys that gave hackers access to AWS S3 data stores containing 600,000 US driver records

In November 2017, ride-sharing company Uber revealed that – back in 2016 – attackers had stolen the personal information of over 50 million passengers and drivers and 600,000 US driver records complete with license numbers.

Attackers could access Uber’s GitHub repository because the company hadn’t enabled multi-factor authentication. Despite the lack of security, these repositories contained important AWS credentials and with those credentials, attackers were able to access Uber’s AWS S3 data stores. 

Uber explained that they secured the data, shut down the unauthorized access, convinced the attackers to delete the data, and strengthened controls on their cloud-based storage accounts. However, subsequent reporting revealed that Uber had disguised the initial hack as a successful bug bounty and paid the attackers $100,000 for their silence. 

Imperva: An exposed AWS API key offers attackers access to a database with customer email addresses and passwords

In October 2019, cybersecurity provider Imperva revealed that attackers had stolen customer data by exploiting a misconfigured AWS instance.

The Imperva CEO explained that attackers used an administrative API key found in one of the company’s AWS accounts to access a database snapshot containing email addresses and passwords. 

Imperva was transparent about the mistakes that led to the AWS security breach, explaining that four primary steps ultimately led to the exposure of customer data:

1. Imperva created a database snapshot for testing while they were evaluating AWS.

2. Imperva made an internal compute instance accessible to the public even though it contained an AWS API key.

3. Attackers compromised the compute instance and stole the AWS API key.

4. Attackers used the AWS API key to access the database snapshot and all the data it contained. 

The company has since taken numerous corrective actions, including tightening security access controls and implementing access audits. 

Three lessons learned from AWS data breaches

There are a few lessons you can take away from these AWS breaches to make your company’s usage of AWS more secure:

1. Know your environment: Many AWS breaches happen because of misconfiguration errors. The better you know and audit your environment, the less likely there will be a misconfiguration attackers can exploit. 

2. Empower your developers: Developers are in the best position to catch and fix misconfiguration mistakes. Companies can better prevent AWS breaches if they give developers the tools and guidance to build secure environments. 

3. Focus on prevention and secure design: Many of these AWS breaches could have been prevented if the affected companies focused more on secure design. With tools like Snyk's AWS vulnerability scanning, companies can identify vulnerabilities before attackers can. Learn how Snyk integrates with AWS security tooling here.

If you’re interested in learning more about cloud security, download our eBook The Five Fundamentals of Cloud Security. And if you want to learn more about how Snyk and AWS integrate, check out the AWS Quick start guide.