AWS RDS Vulnerability Leads to AWS Internal Service Credentials

I wish you enumerated the identity’s Iam permissions or at least did a describe-db-clusters it would give good insights into the internal security of the Aws service roles , I would have thought such a role would be restricted to only be used via internal network leg of the RDS not over the internet. Now we will never know and have to take their word for it. Imagine if that role was able to describe all instances in the region, or dump a backup to a public bucket of every rds . Now that would be a sensationalistic headline !

Seems like an unusually simple exploit, essentially using an advanced postgres feature as intended. Impressive though!

The fact AWS overlooked access controls allowing a customer to reach system files, let alone the STS token, on a multi-tenant service is worrisome.

The article doesn't mention whether the token is limited to the account with the RDS database or can access additional resources.

I'd imagine it's only scoped to a single customer account but I'm curious what it gives access to.

This type of attacks is why i’m not a big fan of managed identities (instance roles) in cloud providers. Suddenly one has to be very careful on what is on the OS level which creates a higher risk for compromise. This risk increases further for the cloud service providers themselves to because there’s a need for control plane identities and the service-user identities.

It must be a fun job to spend the day poking software looking for holes.

Wish I could do this all day long...

Aside, the fact that it took almost 4 months to remediate all accounts is crazy. AWS and cloud in general was supposed to make it dumb easy to upgrade, patch and maintain infra software in production.

> This is where my analysis and research ended, I did not attempt to enumerate any IAM permissions [...]

I'm simply curious, is this standard (or a popular) etiquette among security researchers?