The Capital One thing wasn't a password problem

So by now you've probably seen the headline: Capital One got hit, something like 106 million people in the US and another 6 million up in Canada had their data exposed, and the FBI already picked up the person they think did it. Her name's Paige Thompson, she used to work at Amazon Web Services, and she got arrested on Monday. That part's been everywhere since it broke Monday afternoon, so I'm not going to rehash the whole timeline. What I actually want to talk about is the boring technical detail buried in the complaint, because it's more interesting than "hacker breaks in" and it's the part most of the coverage is glossing over.

It wasn't a stolen password. It wasn't some zero-day nobody could've caught. According to the filing, the attack chain ran through a misconfigured web application firewall sitting in front of one of Capital One's AWS-hosted apps. That misconfiguration let the attacker perform what's called a server-side request forgery, basically tricking the server into making requests on her behalf, and one of those requests went to something called the instance metadata service.

If you haven't worked with AWS, that service is a little internal endpoint every EC2 instance can hit at 169.254.169.254. It hands back info about the instance, and critically, it can hand back temporary security credentials for whatever IAM role is attached. Here's the part that bugs me: as of this writing, that endpoint doesn't require any special authentication to query from inside the instance. Anything that can make the server issue a request to itself can potentially ask for those keys and get them back in plain text. Once you have valid temporary credentials, you don't need to "hack" S3 in any dramatic sense, you just ask it nicely for the buckets, and it says yes because as far as AWS is concerned you're a trusted piece of the account.

I've set up IAM roles for tiny side projects and even at that scale it's easy to over-scope a policy because the alternative (getting the permissions exactly right) takes actual thought and most tutorials just tell you to attach AdministratorAccess and move on. I'd bet real money that's roughly what happened here at a much bigger scale, some role had more reach into S3 than it needed, and a single SSRF turned into access to two decades of credit application data, including around 140,000 Social Security numbers and 80,000 linked bank account numbers. That's the actual lesson, not "cloud bad" (people were quick to make it about AWS being inherently risky, which is lazy) but that permissions sprawl inside a cloud account is exactly as dangerous as an unlocked door, and way easier to lose track of than a physical one.

I've got a Capital One card, the Quicksilver one I got mostly for the 1.5% cash back, so I spent about forty minutes Tuesday night doing the thing everyone does now: checking their credit monitoring email, then going and freezing my file with all three bureaus. Equifax's site was, unsurprisingly, still a pain to use even after everything from 2017 (you'd think they'd have fixed the UX by now, but no). Experian's freeze form kept timing out on me and I had to restart twice. TransUnion at least worked on the first try. None of that is really Capital One's fault, but it's a good reminder that when this stuff happens, the actual cleanup work always lands on you, not the company that lost the data.

What I keep coming back to is how unglamorous the root cause is. No mysterious hacking group, no nation-state angle, just a firewall rule that let a specific kind of request through it shouldn't have, sitting on top of a metadata endpoint that hands out the keys to the kingdom if you ask the right way. I don't think that's a knock on Capital One specifically, it's the kind of mistake I could see happening at basically any company running infrastructure at that scale. It's just that when it happens at a bank, the blast radius is 106 million people's SSNs instead of some internal dashboard nobody outside the company ever sees.