[ericalexander3]

SSRF to metadata service to S3 access was the entry point. There's a lot of focus on the SSRF and metadata service components but the S3/IAM component is possibly more intriguing. Did the role/account follow the principle of least privilege? If not, how did they miss it? This is the company that opened sourced Cloud Custodian. They're capable of identifying risks and creating tooling to reduce lead time on finding those risks.

Possibly more intriguing: I'll bet Capital One deals with more compliance initiatives than 99% of the public sector. Another Heartland Payment Systems example? Did leadership have a false sense of safety after passing an audit?

[jcims]

That was a bush league SSRF that should have been caught by just about any static analysis tooling. That tells me something broke down early in the process.

That said, it's almost impossible to implement least privilege with EC2 instance roles unless you manage application identity in a separate control plane. Otherwise you have a single role that must satisfy the union of all access requirements for infrastructure automation, software deployment, logging, monitoring and discrete application runtime components. It's a mess and IMHO a terrible architecture.

The fact that the STS creds for that role are then made available via unauthenticated network service which then are by default active from any endpoint on the planet unless explicitly locked down is insanity. Furthermore, locking said roles down requires discrete references to VPC endpoints and CIDR ranges that are unique to individual regions and have to be able to breathe with the environment. This makes your IAM lockdown policies gnarly and volatile, not a good recipe for availability.

It's no mean feat to really prevent this kind of thing in a fast-moving environment. Defense in depth is essential.