Capital One 2019年 WAFの設定の誤りからクラウドの鍵へ

外から送った命令が、AWS の上のWAFのサーバーに届いて実行され、そのサーバーの役割の資格情報を持ち出された。持ち出した資格情報は外からそのまま使え、役割に付いた権限で保管庫を一覧し、複製できた。

2026年11月時点。Capital One の発表、米国司法省と連邦裁判所の文書、米国通貨監督庁 OCC の命令、AWS の公式文書で書いています。裁判資料は攻撃者の手順の細部を伏せている。

要点

入口はWAFの設定の誤り。外から送った命令がサーバーに届いて実行され、役割の資格情報が取れた。
その役割は、普段は呼ばない保管庫の一覧を呼べ、700を超えるフォルダやバケットの名を返し、一部を複製できた。
侵入は2019年3月。記録には残っていたが、会社が知ったのは7月17日の外部からの届け出だった。
根本の直しは、WAFに外の命令を通させないことと、役割の権限を役目の分だけにすること。IMDSv2、外からの資格情報の利用の検知は、その次に重ねる層。
OCC は、クラウドへ移す前のリスク評価、網の守り、データの持ち出しの防止、警告の処理の欠けを挙げ、8,000万ドルの制裁金を科した。

何が起きたか

図1 2019年の流れ

日付	出来事
2015年ごろ	OCC の認定では、銀行はIT の運用をクラウドへ移す前に、有効なリスク評価の手順を作らなかった[10]
2019年3月12日	VPN の出口のアドレスから、データへの接続の試み[4]
2019年3月22日、23日	不正な接続。3月22日、WAFの役割で保管庫の一覧の命令が Tor の出口から何度も走り、複製の命令で申込のデータを含むファイルが写された[1][4]
2019年4月21日	再び一覧の命令。同じ日の時刻の付いたファイルが GitHub に置かれた[4]
2019年7月17日	外部の人が、Capital One の脆弱性の届け出用のメールアドレスへ、GitHub に漏れたデータがあると知らせた[1][4]
2019年7月19日	Capital One が不正な接続があったと判断し、FBI に連絡した[1][3]
2019年7月29日	Capital One が公表。同じ日に容疑者が逮捕され、刑事告訴が出た[1][3]
2020年8月6日	OCC が8,000万ドルの制裁金と、業務改善の命令を出した[9]
2022年6月17日	陪審が、通信詐欺1件とコンピューター詐欺と濫用6件で有罪とした[6][8]
2022年10月4日	連邦地裁が、勾留の期間で刑を済ませた扱いとし、5年の保護観察と3年の自宅拘禁を言い渡した。賠償は40,745,000ドル[8]
2025年3月17日	第9巡回控訴裁判所が、刑が軽すぎるとして量刑を取り消し、差し戻した[7]
2025年11月3日	連邦地裁が、差し戻しの後も同じ長さと種類の刑を言い渡した[8]

数字

項目	数
影響を受けた人	米国で約1億人、カナダで約600万人[1]
中身	2005年から2019年初めまでのクレジットカードの申込。氏名、住所、電話、メール、生年月日、申告した収入。顧客の信用の点数、限度額、残高、支払いの履歴。2016年から2018年のうち計23日分の取引の断片[2]
米国の社会保障番号	約14万件。2021年1月27日に約4,700件を追加で確認[2]
紐づく銀行口座の番号	約8万件[1]
カナダの社会保険番号	約100万件[1]
漏れていないもの	カードの番号とログインの資格情報[2]
会社の見積もり	2019年の追加の費用を1億から1億5,000万ドルと見込んだ[1]
規制と訴訟	OCC の制裁金8,000万ドル[9]。顧客の訴訟の和解1億9,000万ドル[6]
同じ者の被害者	少なくとも200の組織から資格情報を取り、少なくとも30の組織からデータを盗んだと控訴審が認定した[7]

控訴審の判決は、Capital One から米国人9,800万人分の個人を特定できる情報が持ち出されたと書く[7]。会社の発表の約1億人とは数え方が違う。

通った道筋

図2 公表された資料から分かる道筋

WAFの設定の誤りのため、外から送った命令がそのサーバーに届いて実行された[4][5]。
1つ目の命令で、*****-WAF-Role という役割の資格情報が取れた[4]。起訴状は、誤った設定のサーバーへ命令を送り、顧客の役割の資格情報を得たと書く[5]。
資格情報は攻撃者の機械に保存された[7]。
2つ目の命令でその役割を使って保管庫の一覧を取り、3つ目の Sync の命令で、役割に権限のあるフォルダやバケットを複製した[4]。

資料に書かれていないこと

刑事告訴と起訴状は、命令がサーバーの中のどの仕組みに届いて資格情報を返させたかを書かない。WAFのどの設定項目が誤っていたかも公表されていない。下の節のメタデータの窓口の話は、EC2 の役割の資格情報がどこから配られるかという AWS の仕様と、AWS が事件の後に出した対策からの説明で、裁判所の認定ではない。裁判資料は SSRF という語も使わない。

外から渡した要求を、サーバーが自分の位置から内側へ出してしまう形は、A01 の SSRF の型と同じ所に守りを置く。サーバーが置かれた網とサーバーの権限を、外の者が借りる。

どこで止められたか

図3 止められた層と、実際に働いた層

1 WAFの設定

刑事告訴は、ファイアウォールの設定の誤りが、命令をそのサーバーに届かせ実行させたと書く[4]。起訴状は、AWS の利用者のうち、WAFの設定を誤ったサーバーを公開の側から探すスキャナーを作って使ったと書く[5]。狙いは1社ではなく、設定の誤りを持つ相手を広く探す形だった[7]。
WAFや中継のサーバーは、外の要求を受け、内側へ出す役目を持つ。行き先を利用者が決められる、あるいは決まった送り先以外へも出せる設定は、そのサーバーが居る網と権限を外へ貸す。
守る側で確かめること。中継が送る先は固定の一覧に限るか。サーバーから出てよい先を網の層でも絞っているか。リンクローカルの 169.254.169.254 のような、そのサーバーの中でしか意味を持たない先へ、外からの要求で出られないか。

2 メタデータの窓口 IMDSv1 と IMDSv2

EC2 のインスタンスに役割を付けると、その中のアプリは、インスタンスのメタデータの iam/security-credentials/ の下から役割の一時の資格情報を取る。資格情報は自動で更新される[14]。AWS は、利用者の代わりに HTTP の要求を出す仕組み、例えば HTTP の中継や XML の取り込みが、この資格情報を外へ出さないよう注意している[14]。

図4 IMDSv1 と IMDSv2 の違い

AWS は2019年11月19日、開いたWAF、開いた中継、SSRF に対する多層の守りとして IMDSv2 を出した。開いたWAFは PUT をまず通さないこと、中継は X-Forwarded-For を付けるのでそれを持つ要求に鍵を出さないこと、鍵の応答の IP の TTL を1にしてインスタンスの外へ届く前に捨てさせることを、それぞれの守りの理由として挙げる[11]。
IMDSv2 では、PUT で作った鍵を以後の GET に付ける。必須にすると、鍵の無い要求や切れた鍵は 401 になる。鍵の寿命は最長6時間[12]。
既定ではどちらの方式も通る。インスタンスごとに IMDSv2 だけを受ける設定にでき、アカウントの既定、AMI の設定、起動の時の指定で決まる。IAM の条件や SCP で、IMDSv2 を求めない起動を止められる[12][13]。
IMDSv2 は多層の1つで、根本の直しではない。AWS 自身も、静的なヘッダを求めるだけの方式より常に強い、という言い方にとどめている[11]。要求の手順とヘッダを自由に決められる SSRF には、1の層の直しが要る。

起動テンプレートの例。架空の設定で、IMDSv2 を必須にし、応答の届く範囲を1にする

"MetadataOptions": {
  "HttpTokens": "optional",   // IMDSv1 も通る
  "HttpTokens": "required",   // 鍵の無い要求は 401
  "HttpPutResponseHopLimit": 1,
  "HttpEndpoint": "enabled"      // メタデータを使わないなら disabled
}

コンテナを中で動かすと、届く範囲1では困る場合があると AWS は書く[13]。範囲を広げるときは、コンテナに役割を直接与える方式を先に考える。

3 役割の権限

Capital One によれば、*****-WAF-Role は通常の業務で保管庫の一覧の命令を呼ばない。その役割で一覧が取れ、700を超えるフォルダやバケットの名が実在のものと一致し、権限のある所から複製できた[4]。資格情報が漏れたときの被害は、その役割でできることの範囲で決まる。

悪い例と直した例。どちらも架空の方針で、実際の方針は公表されていない

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::example-waf-rules/*"
}

AWS は、EC2 の役割には、アプリが要る API の呼び出しだけに絞った最小の権限の方針を付けるよう求める。IAM Access Analyzer は CloudTrail の記録から、その役割が実際に使った権限だけの方針の雛形を作れる[16]。
WAFのような入口の機械の役割と、顧客のデータを読む役割を分ける。入口が破られても、データの保管庫に届かない形にする。
保管庫の側の方針で、読める主体と経路を限る。静的な鍵と短命の資格情報の違いは A02 の型3、鍵の権限の絞り方は秘密の鍵の扱いにある。

4 データの保護

刑事告訴によれば、持ち出された申込の情報のうち、社会保障番号などの一部はトークン化か暗号化がされていたが、氏名、住所、生年月日、信用の履歴はトークン化されていなかった[4]。会社の発表でも、社会保障番号が漏れたのは全体の1%に満たない[2]。保管庫を読まれても、項目ごとに守った値は使えない。この層は一部で効いた。

5 検知と記録

記録はあった。Capital One の記録には、3月22日に WAF の役割が Tor の出口から一覧の命令を何度も呼んだこと、4月21日の一覧の時刻が GitHub のファイルの時刻と合うことが残っていた[4]。それでも会社が侵入を知ったのは、7月17日の外部からの届け出だった[1]。
OCC は、網の守りの設計と実装、データの持ち出しの防止、警告の有効な処理の欠けと、内部監査が弱点を見つけず監査委員会に伝えなかったことを認定した[10]。
今の AWS GuardDuty には、EC2 の役割のために作られた一時の資格情報が AWS の外のアドレスから使われると出る InstanceCredentialExfiltration.OutsideAWS、Tor の出口から API が呼ばれると出る TorIPCaller の検出がある[15]。この事件の型は、どちらにも当たる。

CloudTrail の記録の形。値はすべて架空

{
  "eventSource": "s3.amazonaws.com",
  "eventName": "ListBuckets",                 // この役割が普段呼ばない操作
  "sourceIPAddress": "203.0.113.45",          // インスタンスの外のアドレス
  "userIdentity": {
    "type": "AssumedRole",
    "arn": "arn:aws:sts::111122223333:assumed-role/example-waf-role/i-0123456789abcdef0"
  }
}

インスタンスの役割の資格情報が、そのインスタンスと違う所から使われた時点で、漏れたと扱ってよい。役割ごとに普段呼ぶ操作の一覧を持ち、外れたら知らせる。記録から警告と対応までのどこで途切れるかは A09 にある。

6 外からの届け出の窓口

Capital One は、脆弱性の届け出を受けるメールアドレスを開けていた[4]。7月17日の届け出から2日で侵入を判断し、12日で公表した[1]。米国の連邦検事は、Capital One が速く知らせたことで FBI が侵入を追えたと述べた[3]。この事件で実際に働いた層はここで、自前の検知ではなかった。日本での届け出の流れは脆弱性の届け出にある。

守り方

根本の直し方

WAFや中継のサーバーが外の要求を任意の先へ出せない設定にする。送り先は固定の一覧にし、サーバーから出てよい先を網の層でも絞る。A01 の SSRF の型4。
役割の権限を役目の分だけにする。入口の機械の役割に、保管庫の一覧と顧客データの読み出しを付けない。実際に使った権限から方針を作り直す[16]。A02 の型3。
クラウドへ移す前と設定を変える時に、リスク評価をする。OCC が最初に挙げたのはこの欠けだった[10]。

緩和の策

全部のインスタンスで IMDSv2 を必須にし、メタデータを使わないインスタンスでは窓口を切る。IAM の条件や SCP で、IMDSv2 を求めない起動を止める[12][13]。
インスタンスの資格情報の外からの利用、Tor からの呼び出し、役割が普段呼ばない操作を検知し、警告を処理する人と手順を決めておく[15]。A09。
個人を特定できる項目は、保管庫の暗号化とは別に、項目ごとにトークン化か暗号化をする[4]。
脆弱性と漏えいの届け出の窓口を公開し、届いたものをすぐ調べる体制にする。脆弱性の届け出。
漏れた役割の資格情報は、無効化と差し替えを先にする。順は秘密の鍵の扱い。

参照

Capital One Announces Data Security Incident Capital One、2019年7月29日
Information on the Capital One Cyber Incident Capital One
Seattle Tech Worker Arrested for Data Theft Involving Large Financial Services Company 米国司法省ワシントン州西部地区連邦検事局、2019年7月29日
United States v. Paige A. Thompson, Complaint, No. MJ19-344 米国ワシントン州西部地区連邦地方裁判所、2019年7月29日
United States v. Paige A. Thompson, Superseding Indictment, No. CR19-0159 米国ワシントン州西部地区連邦地方裁判所、2021年6月17日
Former Seattle tech worker convicted of wire fraud and computer intrusions 米国司法省ワシントン州西部地区連邦検事局、2022年6月17日
United States v. Thompson, No. 22-30179, Opinion 米国第9巡回区控訴裁判所、2025年3月17日
United States v. Thompson, No. CR19-159RSL, Order on Resentencing 米国ワシントン州西部地区連邦地方裁判所、2025年11月3日。CourtListener の写し
OCC Assesses $80 Million Civil Money Penalty Against Capital One 米国通貨監督庁 OCC、2020年8月6日
Consent Order, AA-EC-20-51, Capital One, N.A. and Capital One Bank USA, N.A. 米国通貨監督庁 OCC、2020年
Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service AWS Security Blog、2019年11月19日
Use the Instance Metadata Service to access instance metadata Amazon EC2 User Guide
Configure the Instance Metadata Service options Amazon EC2 User Guide
Retrieve security credentials from instance metadata Amazon EC2 User Guide
GuardDuty IAM finding types Amazon GuardDuty User Guide
IAM roles for Amazon EC2 Amazon EC2 User Guide