Thousands of Amazon RDS Snapshots Are Leaking Corporate PII

A service that allows organizations to back up data in the cloud can accidentally leak sensitive data to the public Internet, paving the way for abuse by threat actors.

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.
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 companys 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.
Even if an RDS snapshot thats 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.
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 its not possible to share a snapshot publicly encrypted in this way, they said.
One roadblock to mitigation is that currently theres 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 owners 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.

Last News
▸ Debunking Machine Learning in Security. ◂ Discovered: 23/12/2024 Category: security	▸ Researchers create BlackForest to gather, link threat data. ◂ Discovered: 23/12/2024 Category: security	▸ Travel agency fined £150,000 for breaking Data Protection Act. ◂ Discovered: 23/12/2024 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
Thousands of Amazon RDS Snapshots Are Leaking Corporate PII