Webセキュリティの第一人者が語る、個人情報流出事件の裏側
徳丸浩氏：ただいまご紹介いただきました、EGセキュアソリューションズの徳丸でございます。本日は「米国金融機関を襲った個人情報大規模流出事件の真相」というテーマでお話をさせていただきます。
アジェンダですが、Capital Oneという会社が事件の舞台になっておりますので、この会社の説明をさせていただいた後、事件の概要。そして技術的な解説をいたしますが、実はこれが本題ではなくて、この事件に至った背景の考察が今日のテーマとなります。
簡単に自己紹介させていただきます。私は徳丸と申します。もともと製造業の会社でソフトウェアを書いていましたが、だんだんWebに親しむようになりまして、Webアプリケーションを書くようになりました。
そこからWebのセキュリティの重要性に気がつきまして、そちらを事業化し、2008年に自分の会社、現在のEGセキュアソリューションズを設立いたしました。今は取締役CTOという立場でございます。
また、著書がこちらの青い表紙の本（『体系的に学ぶ 安全なWebアプリケーションの作り方 第2版』）ですが、通称「徳丸本」という愛称で大変多くの方に読んでいただいております。
また、コロナの頃からYouTubeチャンネルを始めました。『徳丸浩のウェブセキュリティ講座』というタイトルになっておりますが、YouTubeで「徳丸浩」で検索していただければ、すぐに見つかると思います。こちらもよろしければご覧ください。
事件が起きたのは、ITに精通したアメリカの大手金融機関
さて、本題に入ってまいりますが、まずはCapital Oneという会社の紹介です。Capital Oneは日本ではあまり馴染みがないかもしれませんが、米国の非常に大手の金融機関で、個人向けの銀行、クレジットカード、自動車ローンなどを手掛けております。
ニューヨーク証券取引所に上場しておりまして、「Fortune 500」では99位、Fortuneの「働きがいのある企業ベスト100」で15位という、堂々たる大企業でございます。
さらに銀行というと、日本でもわりと手堅いITの使い方をする会社が多いと思うんですが、こちらはクラウドとオープンソースにフルコミットメントしておりまして、2020年には独自データセンターからAWSへの移行を完了しております。
またオープンソースにフルコミットしておりまして、DevOps、あるいはDevSecOpsという最先端の開発手法を早くから推進しております。このため、独自のDevOps支援ツールをオープンソースで公開していたりします。
役員・取締役会のメンバー全員がITに精通しておりまして、そのうちの1人はAmazonの元CISO、セキュリティの責任者であるという、非常に堂々たる構成でございます。
ITに特化していることがCapital One社の強みだった
こちらはCapital One社のDevOpsの取り組みの紹介記事で、2017年7月のものです。簡単に読みますが、Capital Oneは2014年から本格的に動き始めました。ウォーターフォールのプロセス、ソースコードがオープンでないソフトウェア、たくさんの手動作業がスタート地点だったんです。
さらに、ソフトウェアなどをほとんど外注していたということでしたが、3年にわたってアジャイルプロセスを導入し、開発を内製化し、組織の壁を撤廃したとあります。
同社のプロダクトマネージャーは、どのようにして完全に自動化されたパイプラインを構築したのか。ソフトウェアのクラウド移行、それからオープンソース化、DevOpsのオープンソースとして、Hygieiaが有名であるという紹介でした。
こちらはCapital One社の開発プロセスです。非常に細かくてちょっと読み上げは無理なんですが、この中で開発テストのプロセスはこれだけ詳細に書いています。「WhiteSource」「Fortify」「Checkmarx」などの、著名なソフトウェアのセキュリティチェックのツールなども使っている様子がわかります。
そしてCapital One社はDevSecOpsの先駆的企業ということで、こちらは2018年5月の記事です。日本では、まだまだDevSecOpsの導入例が少ないわけでございますが、今から5年前にこのような記事が出ていたということで、先端的な取り組みがうかがえます。
こちらは、その責任者の弁です。「私たちは、高品質で機能するソフトウェアをより速く提供する」ということで、銀行ではあるんですが、ITに特化したことこそが競争力の会社になっているということです。
さらに「高品質」の定義です。セキュリティ上の欠陥がないこと、コンプライアンスに準拠していること、欠陥が最小限であるという言葉で定義をしております。
不正アクセスにより、1億人以上の個人情報が流出
こちらはQualysという非常に著名な脆弱性スキャナーの会社の記事広告です。このQualys社がCapital One社に導入されて、DevSecOpsの中でこの製品が組み込まれている様子を示しております。
Capital OneがQualysを選んだ理由は、QualysAPIがCapital One社のDevOpsツールと統合して、コードのセキュリティとコンプライアンスのスキャンを自動化する。あるいはAmazon Machine Image（AMI）とDockerコンテナの両方で脆弱性と設定ミスの評価を提供します、ということです。
ちょっと技術的な用語が出てまいりましたが、要はクラウドですね。あるいはコンテナという先端的な技術の中で、ちゃんと脆弱性や設定ミスの評価をやっている。こちらも5年前の記事ではありますが、今の日本の目で見ても、まだまだ先端的な内容と言ってよいかと思います。
ということで、Capital One事件の概要に入ってまいります。こちらはpiyokangoさんという著名なブロガーの記事を引用させていただいておりますが、2019年7月29日、Capital Oneは不正アクセスにより1億人を超える個人情報が流出したと発表。
WAF（Webアプリケーションへの不正なサイバー攻撃を防ぐために開発された専用防御ツール）の設定ミスに起因して、Server Side Request Forgery（SSRF：正規のサーバーが持つ権限を悪用して不正なコマンドを実行する）攻撃を許したとなっております。
影響範囲は、米国で1億人、カナダで600万人という非常に多くの方の個人情報です。金融機関ですから、この中には与信の情報といった機微な情報も含まれていました。
設定に潜んでいた脆弱性が大規模事件の原因に
では、このような大規模な事件がどのようにして起こったのか。まずは技術的な側面を解説していきます。
WAFの設定ミスとありましたが、Mod SecurityというオープンソースのWAFを使っていたことがわかります。Mod Securityは、Apacheという著名なWebサーバー、この場合はリバースプロキシという使い方ですが、Apache+Mod Securityの両方がオープンソースのソフトウェアです。
これをWebサーバーの手前側に立てて、ファイアウォールですから、防火壁のように使っていたということですね。（スライドの）左に利用者がいますが、このWAFリバースプロキシ経由でWebサーバーに接続して、何か攻撃的なアクセスがあればMod SecurityのWAFが止めるという構成です。
Apache、Mod Security、どちらもオープンソースですから、みなさまが使うことも当然できるわけでして、ここでは導入の例を示しております。
AmazonAWS上で、Amazon Linuxでインストールする手順です。yumというコマンドでソフトウェアをインストールしまして、設定をちょっと編集する。このように、10行足らずの設定をするだけで設定が終わります。
Apacheを再起動してやれば終わりなんですが、実は脆弱性があります。どこかと言いますと、1行目の「ProxyRequests On」という設定。これは絶対にダメですが、状況証拠的にこれが入っていたのではないかというのが私の推測です。
WAFの設定ミスを突き、大量の個人情報が盗み出される
こちらはApacheのドキュメントでございます。該当のProxyRequestsについての説明ですが、「サーバーを安全にするまでProxyRequestsは有効にしないでください。オープンプロキシサーバーは、あなた自身のネットワークにとっても、インターネット全体にとっても危険です」という大変恐ろしい注意書きがございます。ですが、どうもこれが有効になっていたのではないかと私は考えています。
これが攻撃の模様で、ハッカーがSSRF攻撃をしたと報道されております。WAFを経由して、通常はWebサーバーにつなぐんですが、Webサーバーではなく「169.254.169.254」というAWSの仮想的なエンドポイント、つまり仮想的なサーバーにつないだと考えられます。
（スライドの）下をご覧ください。Amazon S3とありますが、こちらはストレージ、つまりファイルサーバーのようなものですが、こちらに大量の個人情報が保管されていました。
これにアクセスするクレデンシャルというパスワードのようなものが、この「169.254.169.254」にアクセスすると取れる。取ったクレデンシャル、パスワードのようなものを使って、下側のストレージ、ファイルサーバーのようなものから1億件超の情報を盗んだと考えられます。
先ほどから出ている「169.254.169.254」は、インスタンスメタデータサービス（IMDS：クラウド上の仮想サーバーの設定情報を受け取る仕組み）と呼ばれるものです。
これはクラウド上の仮想サーバーですが、こちらからIMDSにアクセスすると、左側のWebサーバーの設定が取れる。実際にはこのIPアドレスのサーバーはないんですが、仮想的な技術によってそういうことになっています。
サーバーのさまざまな情報が取れます。例えば、IPv4アドレス。IPアドレスを取得するには、このようなURLで取れます。（スライド）赤字のIPアドレスが取れた例でございます。
ずさんな設定によりアクセス権限を過剰に割り当て
インスタンスメタデータサービスにアクセスする様子を説明いたします。AWSのEC2、仮想サーバーに接続しまして、curlコマンドというもので「169.254.169.254」にアクセスしております。
ちょっと長いURLですが、これがS3、つまりファイルサーバーのようなもののクレデンシャルで、トークンというパスワードみたいなものですね。これがあれば、S3ストレージ、ファイルの保管庫にアクセスができるということになります。
ということで、なぜ攻撃を受けたかですが、そもそもS3ストレージに大量の個人情報が保存されていた。これがいいかどうかは議論が分かれるところでございますが、インターネット上のストレージに個人情報が保存されていました。
次が問題でございます。こちらにアクセスするためのトークン、つまりパスワードのようなものがWAFのサーバーから取れるように設定されていました。WAFはファイアウォールですから、ストレージ、つまりファイルにアクセスする必要はないんですが、ずさんな設定で過剰に権限が割り当てられていたことになります。
また「オープンプロキシ」といって、WAFが非常に危険な設定になっていたということ。それからIMDSです。「169.254.169.254」が無効化されておらず、有効だったということが考えられます。ここまでが、Capital One事件の技術的な模様です。
Capital One社の事件は、各機関も研究・調査を実施
エンジニアでも知らない人が多い、比較的最近の攻撃手法ですが、このような事件がなぜ起こったのかについて説明をしてまいります。
Capital One事件は非常に大規模な事件であったことと、著名な金融機関が起こしてしまったということで、米国ではさまざまな研究がなされております。
マサチューセッツ工科大学（MIT）からは、ここに紹介する2本の論文が出ております。今日は、2021年の11月に発表されたこちらの（スライド右側・赤枠の）論文の情報を元に紹介してまいります。
論文の調査方法ですが、まずはインシデントや関連する損失についての情報収集、つまり事件の内容や損失、損害の情報でございます。こちらは最初に紹介したような内容ですね。
それからステップ2で、システムの安全性とセキュリティを確保する階層的な制御構造をモデル化する。つまりこれは「どうあるべきだったか」「本来こうなってるべきだよね」という内容で、いわゆるTo beです。
ステップ3は、損失を防ぐのに失敗した理由を特定し、各管理者の責任を調査。さまざまな管理者の役割と責任を特定し、どのような管理が不十分であったか、欠落していたか、または効果がなかったかを判断する。
技術的な原因は先ほど説明したとおりなんですが、本来どうあるべきだったかということに対して、現実にはどうなっていたのか。つまり「As is」、現実の姿はどうであったかを分析しております。
ステップ4は、コントロール構造全体の欠陥、包括的な前提条件やシステムの環境条件を明らかにするということで、さらに深堀りをした要因を見ております。ステップ5は、将来への改善ということになります。
監視システムが効果的ではなかったという指摘も
攻撃が成功した技術的な要因です。先ほど少しお話しした内容と重複しますが、リバースプロキシが誤設定されてオープンプロキシになっていた。また、メタデータサービスへのクエリを可能にしたという、先ほどの「169.254.169.254」ですね。
「クラウドインフラストラクチャーの脆弱性」と書いてありますので、実はAmazonのクラウドの責任も追及しております。
また、S3ストレージバケットへのアクセスを許可する、過剰にプロビジョニングされたIAMロールの存在。少し難しい言葉でございますが、要はファイルサーバーにアクセスするパスワードのようなものが、本来必要のないWAFのサーバーに割り当てられていたという意味です。
また、暗号化がされていたんだけど、実際には効果がなかった。あるいは侵入検知や監視システムが効果的でなかったという点に触れております。
「新技術こそ優れている」という思い込み
さて、ここが大変興味深い内容でございますが、脆弱性を生んだメンタルモデルです。Capital One社は非常にハイテク企業でございまして、現在の目から見てもかなり進んだ技術を使っておりましたが、エンジニアあるいは経営層の中に「新技術こそ優れている」という思い込みが存在したということです。
最先端のクラウド、あるいはセキュリティのソフトウェア、サービスを使っていることで、従来から実績のある枯れたセキュリティ技術よりも優れているという思い込みがあった。
「AWSに対する過度な信頼と責任共有モデルの理解不足」とありますが、クラウドを過剰に信頼してしまったことと、「クラウド任せではいけない、自分たちの責任もある」ということが理解されてなかったということで、自らの責任を放棄してしまっていた。
また「曖昧さによるセキュリティへの依存」と書いてありますが。内部が非常に複雑なシステムなので、ハッカーが侵入しようと思ってもできないだろうという思い込みがあったという意味です。
また、エンジニアの統制の不足ということで、エンジニアが自由にさまざまな技術を選択できたために、セキュリティエンジニアがそれをチェックすることが困難になっていたとあります。
セキュリティを守るはずのWAFが攻撃の侵入口に
「IAMロールの設定が脆弱だった原因の考察」と、ちょっと難しい言葉がまた出てまいりましたが、要は権限の設定ですね。長いので読み上げは割愛いたしますが、（要点は）赤字のところです。
開発速度が優先され、セキュリティに対する警戒心が低下していた。それから、非常に複雑なシステムであったため、すべてのデータを完全に可視化できていなかった。これらの結果として、データのセキュリティは優先度が下がってしまっていたという可能性が指摘されております。
次に、WAFオープンソースのMod Securityに関する考察です。そもそも、なぜMod Securityを選択したのか。
Mod Securityは非常に著名なオープンソースソフトウェアではありますが、私も経験がございまして、なかなか扱いがやっかいなものです。洗練された画面のコントロールパネルもないということで、取り扱いが非常に面倒なものでございます。
なぜ使ったのかという考察ですが、おそらくCapital One社が方針として、クラウドとオープンソースにコミットしていたからではないかということで、結果としてエラーが起きやすい環境になっていたと考察しております。
それからWAFはセキュリティ機能ですので、セキュリティを守るためのものです。しかし今回は、WAF自体が攻撃の侵入口になってしまったんですが、そういった可能性があるという考慮が十分なされなかったのではないかと指摘しております。
セキュリティエンジニアの人員不足と高い離職率
また、従業員に関する考察です。「セキュリティエンジニアの離職率の高さ」ということで、サイバーセキュリティチームの従業員の3分の1が2018年に退職しており、高いストレス、業務量の多さ、人員不足、離職率の高さなどが裏付けられます。
例として、EndgameというソフトウェアはEDR（エンドポイントの操作や動作の監視を行い、サイバー攻撃を受けたことを発見し対処するもの）で、非常に高価なソフトウェアなんですが、1年経ってもソフトウェアの導入が終わってなかった。理想とは裏腹に、現実のセキュリティはおろそかになっていたのだと思います。
また、AWS側の責任についても述べておりまして、SSRF攻撃の緩和策を実施していなかったということです。他社は対策をしていたんですが、この点が不十分だったということと、Amazon社は十分なガイダンスを提供していなかった。事件後になって、ようやく強化版を出したと書いてあります。
Amazon社がセキュリティ改善を後回しにした理由についても考察されていますが、クラウド間の競争が激化する中で、イノベーションと新機能開発に重点を置いていたのではないかという考察です。
WAFの設定が脆弱だったわけですが、脆弱性診断等ではこれが見抜けなかったのかと思いまして、私はNessusという有名なツールでチェックしてみたんですが、チェックされております。
（実際に使用されたものとは）ツールが違いますので、これと（診断結果が）同じかどうかはわからないんですが、QUALISでは検出されなかったのか、あるいは検出はしたが軽視したのか、診断では防げていなかったのは事実でございます。
また、最近はクラウド設定監査が盛んに利用されておりますが、そこで基準として使われるCISベンチマークというものがあります。IMDSに関する監査項目は事件当時はなかったということで、監査でも見落としてしまった可能性がございます。
形式的なチェックによってセキュリティ改善が疎かに
「形式的なコンプライアンスの偏重」ということで、たぶんこれは日本も米国も同じなんですが、金融機関なので、さまざまな規制当局がバラバラのセキュリティ要件を要求していて、非常に煩雑になってしまうわけですね。
コンプライアンスを（遵守）したいと思っても、何々庁とか何々省とかさまざまな機関がバラバラの要求をしてくることで、非常に形式的なコンプライアンスになってしまっていたのではないか。ここ（スライド）に書いてありますが、官僚的なコンプライアンスに重点が置かれていた。
つまり、チェックリストにただチェックをしていくだけみたいな感じになっていて、実質的なセキュリティ改善が疎かになっていた。ですから、その規制当局側にも問題があると指摘をしております。
こちらは経営陣への分析と提言です。経営陣は、ソフトウェア企業にシフトするために大胆かつリスクのある戦略的決定を行ってきましたが、イノベーションに焦点を当てた結果、セキュリティへの配慮がおろそかになってしまっていた。
企業はサイバーリスク管理を強化し、情報セキュリティチームの高い離職率にも早急に対応する必要があった。取締役会もITには通じていたんですが、セキュリティ責任者（CISO）から直接の、あるいは密接なフィードバックを得ていなかったということで、これらが改善すべきであると指摘されております。
ハイテク企業で大規模事件が起きた原因のまとめ
まとめです。Capital One事件が起こるに至った原因を考察しました。技術的には、WAFを構成するリバースプロキシの誤設定によるSSRF攻撃が原因です。
これは従来からわかっていて、Capital One社は表向きは非常にハイテクなDevSecOpsをいち早く取り入れた企業でありましたが、その実態はもろいものでした。クラウドのセキュリティ機能に対する過信。あるいはシステムが複雑なので、攻撃を受けるはずがないという過信。
一方でセキュリティエンジニアの高い離職率によるセキュリティ運用の低下。それと、それを生んだ風土ですね。あるいはコンプライアンスの偏重による外見のみのセキュリティ施策ということで。
クラウド利用は日本でも進んでおりますが責任共有モデルというものを理解して、自分たちの責任を果たしましょう。主体的に行動しましょう。また、その新しい技術もいいんですが、昔からある枯れた技術が別に間違っているわけではないので、そういった枯れたセキュリティ施策を今後も実施してまいりましょう。
以上で私の発表を終わります。最後までご視聴いただきありがとうございました。
