Amazon RDS snapshots allow extensive leakage of personally identifiable information (PII)

Fifty-one columns and 10,000 rows appear to summarize car rental transactions. 

Among the transactions are names, contact information and marital status of renters; occasion for rental; enquiry segments (“company,” “commercial,” “fleet owner,” “individual”); customer category type; car makes and models; and even expected delivery dates — scores of personally identifiable information (PII). 

This MySQL database from a car rental agency was exposed for a full month. It is just one example of the hundreds of databases that are exposed monthly — with extensive PII leakage — via Amazon Relational Database Service (Amazon RDS) snapshots, according to research out today from Mitiga. 

>>Don’t miss our new special issue: Zero trust: The new security paradigm.<<

“Hundreds of databases are shared publicly at any given moment,” said Ofer Maor, CTO of Mitiga, a cloud incident-response company. “Some are even shared for extended periods such as months or years, possibly unintentionally. These might contain sensitive data and might be easily accessed by threat actors.”

Uncovering a widespread problem

As part of its regular research on data exfiltration scenarios from cloud environments and its product development, Mitiga essentially put itself “in the shoes of the attacker,” said Maor.

Notably, it researched potential scenarios to exfiltrate data from databases on Amazon Web Services (AWS) and through Amazon RDS snapshots.

One question the company sought to ask: “If I have a foothold on the account and can access the RDS data, what are the ways I can exfiltrate it?”

One method it employed was making a snapshot of the database and then sharing it publicly. As Maor noted, researchers then questioned: “What if it is already happening? How would we be able to detect this in the wild?”

In addition, in the last few years, the company has witnessed several attacks and research involving the use of public EBS snapshots — which were, in fact, addressed by AWS in their CloudTrail logging. However, Maor pointed out, they saw less attention to a problem that posed a similar risk: Public RDS snapshots.

“Organizations should be aware of the potential misuse of publicly sharing a snapshot and take steps to reduce the risk through detection and prevention,” said Maor. 

RDS snapshots explained

Released in October 2009, the Amazon RDS is a popular platform-as-a-service (PaaS) that provides a database platform based on a few optional engines (such as MySQL or PostgreSQL). 

When using the RDS service in AWS, developers can take RDS snapshots. This is a storage volume snapshot that backs up the entire database instance (not just individual databases). 

“An RDS snapshot is an intuitive feature that helps you to back up your database,” Mitiga researchers Ariel Szarf, Doron Karmi and Lionel Saposnik wrote in a blog post. 

These snapshots can then be shared across different AWS accounts, in or out of the on-premises organization. RDS snapshots can also be made publicly available, allowing users to share public data or a template database to an application. 

A public RDS snapshot can be valuable when a user wants to share a snapshot with colleagues; this can be done publicly for just a few minutes.

“In this case, the user can share the snapshot publicly for just a few minutes and think it is OK,” said Maor. “Even worse, they might forget it.”

Either scenario can “unintentionally leak sensitive data to the world, even if you use highly secure network configurations,” wrote Szarf, Karmi and Saposnik. 

This can be a great asset for a threat actor either during the “reconnaissance phase of the cyber kill chain,” or for extortion or ransomware campaigns.

“Attackers are always looking for new ways to put their hands on confidential information of organizations, mostly for financial gain,” wrote Szarf, Karmi and Saposnik. 

Exposure examples

In its research, Mitiga focused on a one-month timeframe: September 21 through October 20, 2022. During that period, they saw 2,783 snapshots. Of those: 

• 810 were exposed during the full analyzed timeframe. 
• 1,859 were exposed for 1 to 2 days. 

Researchers developed an AWS-native technique that scanned, cloned and extracted potentially sensitive information from RDS snapshots in scale. This mimicked the type of tool that can be developed and used by attackers to later abuse information. 

The tool hourly scanned snapshots — from all regions — that were marked as public. Those were then cloned to Mitiga’s AWS account, listed, prepared, extracted and cleaned. 

In one example, a MySQL database that appeared to be from a dating application database was exposed for roughly four hours. The database was created on April 14, 2016, but the snapshot was taken more than six years later, on October 2, 2022. A table lists around 2,200 users and included their emails, password hashes, birthdates and personal image links. Another table, meanwhile, contained private messages. 

In another example, a MySQL database was exposed for an entire month. This appeared to be a telephone app company database, and the snapshot was taken on September 12, 2022.

One table summarizes all logins to company applications; it features data including user IDs, phone device models, mac addresses, client access tokens and application IDs. 

Ultimately, wrote Szarf, Karmi and Saposnik, it’s “not an overstatement to assume the worst-case scenario.”

“When you are making a snapshot public for a short time, someone might get that snapshot’s metadata and content,” they wrote.

Simply put, to ensure their own privacy and that of their customers, organizations should not make snapshots public if they’re not 100% sure there is no sensitive data in the content or in the metadata, they say.

Visibility is lacking, but orgs can take action

Ultimately, Maor lamented a lack of optimal visibility. 

“As forensics investigators, we were disappointed by the lack of ability to detect if a publicly shared snapshot was accessed by a third party using the logs,” he said. 

The company did approach AWS about the issue, and they had created a feature request, he reported.

But in any case, organizations using Amazon RDS snapshots must take action now, he said. For one, implement least-privileged permissions: Don’t give unnecessary permissions when they are not needed.

Also, encrypt snapshots when possible; these cannot be shared publicly. Use the available AWS toolset (AWS Trusted Advisor, AWS config) to detect public snapshots. And, use AWS CloudTrail logs to check historically if a snapshot was created and shared publicly or to an unknown account. 

Most of all, said Maor, “educate, educate, educate: Understand the potential misuse and implications of sharing a resource publicly, even for a few seconds.”

Originally appeared on: TheSpuzz