flawopen.com/보안 사고/Capital One SSRF

Capital One: 사소한 SSRF 결함이 클라우드 계정 전체를 장악당하게 만든 과정

Critical — 100M+ records CWE-918: Server-Side Request Forgery Disclosed July 2019
쉬운 설명 (ELI5)

손님이 적어준 주소라면 어디든 서류를 가지러 가는 심부름 직원이 있습니다. 회사 복도 끝에는 문을 두드리는 누구에게나 금고 열쇠를 내어주는 비밀 창구가 있습니다. 악의적인 손님이 심부름 직원에게 그 복도 끝 창구에 다녀오라고 시키자, 직원은 의심 없이 마스터 열쇠를 받아 손님에게 건넸습니다.

Why this incident reshaped cloud defaults

Capital One is the reason SSRF stopped being treated as a second-tier bug class. Before it, SSRF was often triaged as an information-disclosure nuisance. After it, the industry understood that in a cloud environment SSRF is a credential-theft primitive — because the cloud platform itself puts a credential vending machine at a fixed, well-known, unauthenticated address inside every instance.

AWS introduced IMDSv2 in November 2019, requiring a PUT to obtain a session token and defaulting to a low IP hop limit. Both changes specifically break the "one blind GET" pattern this attack relied on. Equivalent hardening exists across other cloud providers.

The lessons that actually transfer

FAQ

Does IMDSv2 make SSRF safe?

No — it removes one very high-value target. SSRF can still reach internal admin interfaces, databases, Kubernetes APIs, and other services that trust the network position of the caller. It remains a serious bug class on its own merits.

Would a WAF have stopped this?

The vulnerable component in this case was a web application firewall, which is a useful reminder that security appliances are applications too. Filtering rules can raise the cost of exploitation but do not address the underlying design, which is that a server will fetch whatever address it is told to.

Related reading

출처 및 공식 보안 권고