AWS fixes internal credential access vuln file for RDS • The Register

A local file read vulnerability in Amazon’s relational database service (RDS) could be exploited to allow an attacker to access internal AWS credentials, the cloud giant has confirmed.

Cloud security firm Lightspin’s research team discovered the flaw and reported it to AWS, which applied an initial patch and worked with customers to mitigate the vulnerability.

While no in-the-wild attack exploited the bug, AWS confirmed that it allowed researchers to access “internal credentials specific to their Aurora cluster.”

“No cross-client or cross-cluster access was possible; however, highly privileged local database users who could exercise this problem could have potentially gained additional access to data hosted in their cluster or read files in the system. ‘exploitation of the underlying host running their database’, according to the AWS Security Bulletin.

After Lightspin alerted the cloud giant to the flaw, AWS “acted immediately” to fix the problem. This included updating Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL. It also deprecated some older versions of both products, meaning customers can’t create new instances with those versions.

In a blog post, Lightspin Security Research Director Gafnit Amiga detailed 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 log using an SQL interface and create foreign tables. Versions 9.6.2 and later of the Amazon RDS engines for PostgreSQL support this extension.

Amiga discovered that a user could bypass the validation of the log_fdw extension by removing the validation function: ALTER FOREIGN DATA WRAPPER log_fdw NO VALIDATOR;

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

From there, Amiga searched through the system files until it found one with the following temporary credentials: CSD_GROVER_API_CREDENTIALS.

As she explained:

Amiga exported the passkey, secret passkey, and session token using the AWS Security Token Service (STS) GetCallerIdentity API. This gave him the User ID, Account ID, and Amazon Resource Name (ARN) for Identity and Access Management (IAM) credentials, which gave him access to an AWS service internal.

“This is where my analysis and research ended,” Amiga wrote. “I have not attempted to enumerate IAM permissions or move further laterally into the internal AWS 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 patch.

By the end of March, AWS had contacted all of its affected customers and fixed 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,” Amiga concluded. “However, like any service provider, wrapping up third-party services such as PostgreSQL and trying to provide users with advanced functionality is sometimes a double-edged sword.” ®

Comments are closed.