6 ms·
AWS RDS Vulnerability Leads to AWS Internal Service Credentials
- thinkmassive 5y agoSeems 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.
- Beltiras 5y agoI 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.
- omegalulw 5y agoThat's not a new problem, it's an age old problem with any complex system; they will always be emergent effects.
- rmbyrro 5y agoIt 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.
- pbalau 5y ago> 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.
- jdub 5y agoOK, 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.
- Nextgrid 5y agoThe 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.
- jdub 5y agoYes, it requires a little bit of work and scheduling. Very different to running the entire thing yourself, though!
- xiwenc 5y agoThis 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.
- nijave 5y agoThis 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)
- nijave 5y agoThe 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.
- brentcetinich 5y agoI 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 !
- rmbyrro 5y agoMaybe they did, but can't speak about?...
- vemv 5y ago> 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?
- noasaservice 5y agoPretty 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.