AWS Fixes Internal Reference Access File Vulnerability for RDS • The Register

A local file-reading vulnerability in Amazon’s Relational Database Service (RDS) could have been exploited by an attacker to access internal AWS credentials, the cloud giant has confirmed.

The research team at cloud security company Lightspin discovered the flaw and reported it to AWS, who applied an initial patch and worked with customers to mitigate the vulnerability.

While no in-the-wild attacks took advantage of the bug, AWS confirmed it gave researchers access to “internal credentials specific to their Aurora cluster.”

“No cross-customer or cross-cluster access was possible; highly privileged local database users who could exert this problem might have been able to gain additional access to data hosted in their cluster or read files in the operating system of the underlying host on which their database,” according to an AWS security bulletin.

After Lightspin warned the cloud giant about the flaw, AWS “immediately went over” to fix the problem. This included updating Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL. It has also discontinued some older versions of both products, meaning customers with these versions will not be able to create new instances.

In a blog post, Lightspin Director of Security Research Gafnit Amiga described how she exploited the vulnerability on the RDS EC2 instance using the log_fdw extension.

The log_fdw extension allows users to access the database engine’s log through SQL and build strange tables. Versions 9.6.2 and later of Amazon RDS for PostgreSQL engines support this extension.

Amiga found that a user could bypass the log_fdw extension’s validation process by dropping the validator function: ALTER FOREIGN DATA WRAPPER log_fdw NO VALIDATOR;

Extension validation occurs in the validator function, the handler function, or both. But because the validator function is optional, it can be removed without damaging the functionality. This allows the user to create a table without validation in the handler function.

From here, Amiga rummaged through system files until she found one with the following temporary credentials: CSD_GROVER_API_CREDENTIALS.

As she explained:

Amiga exported the access key, secret access key and session token using the GetCallerIdentity API of the AWS Security Token Service (STS). This gave her the user ID, account ID, and Amazon Resource Name (ARN) for identity and access management (IAM) credentials, and this gave her access to an internal AWS service.

“This is where my analysis and research ended,” Amiga wrote. “I haven’t tried to list IAM permissions or get further sideways into AWS’s internal environment.”

Lightspin reported the vulnerability to AWS on December 9, and five days later, the cloud provider rolled out an initial patch while working on a full fix.

By the end of March, AWS had contacted all of its affected customers and repaired all supported versions of Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL.

“The AWS Cloud is a boon to many developers, architects and security professionals around the world because of its pay-as-you-go model and diversity of service offerings,” concluded Amiga. “However, like any service provider, packing in third-party services like PostgreSQL and trying to provide users with advanced features is sometimes a double-edged sword.”

Leave a Comment