Thousands of Amazon RDS Snapshots Are Leaking Corporate PII

Legions of databases are being inadvertently exposed monthly, through a feature of an Amazon cloud-based data-backup service. The situation gives threat actors access to personally identifiable information (PII) that they can use in extortion, ransomware, or other threat activity, researchers have found.

Amazon RDS is a popular platform-as-a-service that provides a database based on several optional engines, including MySQL and PostgreSQL. An RDS snapshot, or a storage volume snapshot of a database instance, is an intuitive feature that helps organizations back up their databases, allowing users to share public data or a template database to an application, researchers said.

The Mitiga Research Team recently discovered the leaks in the form of numerous Amazon Relationship Database Service (RDS) snapshots that are being shared publicly — whether intentionally or by mistake.

Over the course of one month, the researchers said that they observed 2,783 RDS snapshots, 810 of which were exposed publicly during the entire time frame. Additionally, 1,859 snapshots of the 2,783 were exposed for one to two days, which is still enough time for attackers to pounce upon the leak, they reported.

Individuals within an organization also can share these snapshots with colleagues by using the feature without having to worry about user profiles or roles — a scenario that leads to the snapshot being shared publicly, the researchers said.

"These snapshots can be shared across different [Amazon Web Services] accounts — in or out of the on-premises organization, as well as AWS accounts that make the RDS snapshots publicly available," the researchers wrote. "With that, one might unintentionally leak sensitive data to the world, even if you use highly secure network configuration."

Some of the exposures last for months, and some for just a short period of time, in both cases potentially allowing threat actors to take advantage, they said in a blog post shared online Nov. 16.

Uncovering Cloud Misconfigurations & User Errors

The exposure once again highlights the potential for exploitation of the fragile security posture of cloud-based services that allow for enterprise resources to be shared on the public Internet, Mitiga researchers Ariel Szarf, Doron Karmi, and Lionel Saposnik noted in the post.

"Attackers are always looking for new ways to put their hands on confidential information of organizations, mostly for financial gain," they wrote. "Some cloud services that allow sharing cloud resources widely to the world [are] exposing a new threat to organizations — unintentional sharing of information through resources like disk snapshots (EBS), or in our case DB snapshots (RDS)."

To conduct their research, the Mitiga team developed a AWS-native technique, using AWS Lambda Step Function and boto3, that can easily be integrated into an AWS environment and customized to investigate snapshot exposure.

Unfortunately, attackers also can develop such a tool to view public snapshots and perform the same tasks, allowing them to steal data from these public-facing resources and abuse it later to extort money from organizations that own it, the researchers said.

The researchers outlined several specific instances in which they could access data from exposed snapshots during a month-long investigation.

One was a MySQL database exposed for the entire month that that appeared to be from a car rental agency. Exposed data included information from car-rental transactions, including PII of customers; business-knowledge data such as the type of cars in the company's fleet; and other specific rental information.

Another snapshot exposed for less than four hours came from a database of a now-defunct dating application that included a user table containing emails, password hashes, birth dates, links to personal images, private messages, and other personal data of about 2,200 users of the app.

No PII? Still a Problem

Even if an RDS snapshot that's exposed publicly includes no PII, there is still a way for threat actors to find out who the database and thus its data belongs to, the researchers said.

In their investigation, they were able to identify who owned account IDs for many snapshots by simply looking at the snapshot name and seeing the company name in it, they said.

Moreover, every snapshot metadata contains a field called "MasterUsername," which is the main database username, the researchers explained. In many cases, that username includes either the name of the company that owns the database fully spelled out or identified in acronyms and shortcuts; or a name of a person working at the company, they said.

In the latter case, by using a method that they admitted was "a little creepy, but useful," researchers conducted LinkedIn searches to find out where the people identified in the username worked, noting that this is a method threat actors could employ to do the same.

Mitigating the Problem

As many organizations using Amazon RDS may not even know if they have public snapshots, identifying if there are any in their respective environments is the first step toward mitigating the issue, the researchers said.

Helpfully, Amazon sends an email quickly to users if they share a snapshot publicly, notifying them about the public snapshot to ensure that it was intended to be publicly available. In the case of a test done by the researchers, this email was received 23 minutes after exposure.

Researchers also outlined a step-by-step way to conduct a historical check using CloudTrail logs to discover if someone created a public snapshot that potentially can be abused.

To prevent the creation of public Amazon RDS snapshots at all, enterprises should manage permissions well by adopting a practice of "least-privilege permissions," giving them only on a strict, as-needed basis.

They also can set service control policies (SCPs), which are AWS organizational-level policies that can specify the maximum permissions for an organization, researchers said. Applying SCP on an AWS root account to deny certain operations on RDS snapshot will prevent unintended sharing of RDS DBs, they said.

Organizations also can encrypt snapshots in AWS using a KMS key, and the researchers confirmed in their investigation that it's not possible to share a snapshot publicly encrypted in this way, they said.

One roadblock to mitigation is that currently there's no way to know if someone has copied a public snapshot of an Amazon RDS database, as there is no log event for copying a public snapshot to another account or restoring a database instance from another account in the snapshot owner's account, the researchers said.

Mitiga approached AWS about the issue and, upon confirmation that "logging an RDS copy and restore operation is currently unavailable," made a feature request to support its addition to the platform, researchers said.