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 !

Maybe they did, but can't speak about?...

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.

I think it just speaks to the complexity we are reaching in software engineering. Feature A and feature B might be safe in and of themselves but a composition contains a vulnerability.

That's not a new problem, it's an age old problem with any complex system; they will always be emergent effects.

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.

This wasn't really an instance role, though. It was plain old credentials for a web service saved to disk (could have easily been a username/password or public/private key pair)

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.

OK, now run the same remediation process except now you're maintaining all of your high availability database clusters yourself. :-)

RDS, simple as it may seem on the surface, is one of the things I'm most grateful for in AWS.

The reason it took 4 months is because I don't think classic RDS can upgrade databases online. You'll either need to failover or have a few minutes of downtime. This is no different to on-prem.

Aurora might be a different situation, not sure.

Yes, it requires a little bit of work and scheduling. Very different to running the entire thing yourself, though!

> 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.

Easy doesn't mean fast.

> 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?

Pretty much, yep.

Once you get creds, you stop and report. You don't use, you don't enumerate, you dont do shit with them.

Getting and reporting is good faith. Getting and using is likely starting a felony case.