Internal AWS credentials swiped by researcher via SQL payload

Amazon cloud service acts quickly to close security hole in RDS

A security researcher said they seized credentials for an internal AWS service by exploiting a local file read vulnerability on a Relational Database Service (RDS) EC2 instance.

Credit for the discovery goes to Gafnit Amiga, director of security research at Israeli cloud security firm Lightspin, who told The Daily Swig that the research was noteworthy “because the final payload is all SQL commands”.

The impact was obscured by the fact AWS declined to divulge the purpose or implementation of the vulnerable internal service, but it did tell Amiga that any abuse would not have imperilled customer data.

While recognizing the appeal of AWS services, the finding showed that “wrapping third-party services such as PostgreSQL and trying to provide users with advanced features is sometimes a double-edged sword”, said Amiga.

AWS has comprehensively addressed the vulnerability and said it had found no evidence of hostile exploitation, according to the researcher.

Path to the breakthrough

Amiga began the research by spinning up an RDS instance using the Amazon Aurora PostgreSQL engine and connecting to the database using psql, according to a blog post documenting the process.

She set out to access the underlying machine running PostgreSQL, “so I searched for something that will allow me to run OS commands, send network requests or read local files,” the researcher explained.

YOU MIGHT ALSO LIKE TruffleHog v3: API key leak detection tool adds support for more than 600 types

“After trying all simple known techniques, I decided to go over the extensions.”

RDS supports many extensions for PostgreSQL, “but I felt that the chances they will miss something there are higher because it is not that simple to do a secure integration to a third-party code”, she continued.

The researcher examined the functionality of 8-10 such extensions and the objects they created within Postgres before alighting on one that yielded a potential breakthrough: log_fdw.

Bypassing validation

Using the log_fdw extension, Amiga attempted a path traversal when creating a foreign table, but this prompted an exception saying “the log file path specified was invalid”.

After testing another relative path, she identified the source of the error as a validation function.

AWS created a custom foreign data wrapper – which can obtain data from external files – for log_fdw with handler and validator functions.

A potential breakthrough arose when it transpired that the validator function is optional for foreign data.

Amiga potentially had permission to update the validator function using the rds_superuser role. “I just hoped that they validate the path only in the validation function,” she said.

This hope was fulfilled when the researcher dropped the validator function and the path traversal succeeded.

She then found temporary identity and access management (IAM) credentials at csd-grover-credentials.json, comprising a publicKey and privateKey, that turned out to be connected to an internal role by the name of csd-grover-role.

Amiga was then able to discover and access a corresponding internal, ‘Grover’ service.

The vulnerability was reported to AWS on December 9. AWS applied an initial patch for recent versions of RDS and Aurora PostgreSQL engines on December 14, then confirmed on March 22 that all current supported versions were fixed and that potentially affected customers had been given mitigation instructions.