AWS fixes local file vuln on internal credential access for Relational Database Service

Lightspin threat researchers discovered the bug, which AWS fixed

A local file read vulnerability in Amazon's Relational Database Service (RDS) could have been exploited by an attacker to gain access to internal AWS credentials, the cloud behemoth has confirmed.

Cloud security company 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 attacks exploited the bug, AWS confirmed it gave researchers access "to internal credentials that were specific to their Aurora cluster."

"No cross-customer or cross-cluster access was possible; however, highly privileged local database users who could exercise this issue could potentially have gained additional access to data hosted in their cluster or read files within the operating system of the underlying host running their database," according to an AWS security bulletin.

After Lightspin alerted the cloud giant to the flaw, AWS "moved immediately" to fix the issue. This included updating Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL. It also deprecated some older versions of both products, which means customers can't create new instances with these versions.

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

The log_fdw extension lets users access the database engine log via SQL and build foreign tables. Versions 9.6.2 and higher of Amazon RDS for PostgreSQL engines support this extension.

Amiga discovered 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 happens in the validator function, the handler function, or both. But because the validator function is optional, it can be dropped without damaging the functionality. This allows the user to create a table without validation in the handler function.

From here, Amiga poked around in system files until she found one with the following temporary credentials: CSD_GROVER_API_CREDENTIALS. 

As she explained:

The "publicKey" and the "privateKey" values looks like STS "AccessKeyId" and "SecretAccessKey" respectively. The signs that suggest this are the "publicKey" prefix of "ASIA" (as specified in the Unique Identifiers section of the AWS IAM User Guide) and the additional "token" parameter.

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

"This is where my analysis and research ended," Amiga wrote. "I did not attempt to enumerate any IAM permissions or move further laterally into AWS' internal environment."

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

By late March, AWS had reached out to all of its affected customers and fixed all supported versions of Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL.

"The AWS Cloud is a blessing for many developers, architects, and security professionals around the world due to its pay-as-you-go model and diversity of service offerings," Amiga concluded. "However, like any service provider, wrapping third-party services such as PostgreSQL and trying to provide users with advanced features is sometimes a double-edged sword." ®