Capital Oneのクラウド設定ミスによる情報漏えいを技術的に分析
Josh Stella
2019年8月1日
0 分で読めます編集者注
このブログ記事は、もともとfugue.coに掲載されていました。Fugueは2022年にSnykの一員となり、Snyk IaCの重要な構成要素となっています。
更新：2019年8月26日
この記事の公開後、AWSは情報漏えいについていくつかの見解を公表し、何が起きた可能性が高いのかが明らかになりました。AWSはロン・ワイデン上院議員への回答で、次のように述べています。
「Capital Oneが公表したとおり、この攻撃は、Capital Oneが設置したファイアウォールのアプリケーション層における 設定ミス が原因で発生し、さらにCapital Oneが意図していた範囲を超えていた可能性のある権限設定が事態を悪化させました。設定ミスのあるファイアウォールを通じてアクセスし、より広範なリソースへのアクセス権限を得た後、SSRF攻撃が使われたと考えています（これは、設定ミスのあるファイアウォール経由で侵入した攻撃者が、データにアクセスするために利用できた可能性のある複数の手段の一つです）。」
「前述のとおり、SSRFはこの攻撃の主な要因ではありません。AWSのお客様において、ほかに注目すべきSSRFによる侵害があったとは認識していません。」
今回の情報漏えいでSSRFが使われた可能性が大きく取り上げられていますが、AWSが明らかにしたとおり、それは攻撃の主な要因ではありませんでした。原因は、クラウドリソースに過剰な権限が設定されていたことです。この記事では、そうしたリソースがどのように設定ミスを起こし、その設定ミスがどのように悪用された可能性があるのかを詳しく説明します。
初回公開：2019年8月1日
この記事では、刑事告発状で確認できる証拠をもとに、Capital Oneの情報漏えいがどのように発生した可能性があるのかを技術的に探ります。まず、Capital Oneのクラウドチームを深く尊敬しており、チームには友人もいることをお伝えしたいと思います。同社はクラウドコンピューティングをリードしてきましたが、同じことはほぼどの企業にも起こり得たでしょう。また、以前勤務していたAmazon Web Services（AWS）を批判する意図もありません。AWSは安全なサービスを提供しており、私は同社を心から尊敬しています。この記事の目的は、ファイアウォール、IAM、S3を組み合わせた攻撃を検証し、クラウドを利用するすべての組織が注意すべきクラウド設定ミスの危険性を示すことです。
この記事を書くにあたり、FBIの告発状に記載された技術的な詳細を分析し、攻撃がどのように行われた可能性があるか仮説を立てました。その後、開発用アカウントで攻撃をシミュレーションし、記事で具体的な詳細を説明できるようにしました。
判明している事実
FBIの告発状と、犯人とされる人物のソーシャルメディアへの投稿から、攻撃について断片的な情報がわかっています。攻撃者はTorとIPredatorを併用して身元を隠し、それらのサービスを通じて、Capital OneのAWS環境に設定ミスのあるファイアウォールを発見したようです。これがCapital Oneを狙った攻撃だったのか、それとも設定ミスを見つけたことで機会をうかがって実行した攻撃だったのかは明らかではありません。
攻撃者の動機や経歴については多くの記事で取り上げられているため、ここでは技術的な詳細に焦点を当てます。わかっている攻撃の要素は、次の4つです。
ファイアウォールの設定ミス
EC2インスタンスへのアクセス獲得
IAMロールを通じたS3へのアクセス獲得
S3バケットの発見と複製
以下で、それぞれについて詳しく見ていきます。
攻撃がどのように行われた可能性があるか
詳細はわかっているものの、情報は限られているため、判明している事実に基づいてかなりの推測と解釈を行いました。以下、攻撃の各手順を説明する中で、推測については明確に示します。下の図は、Capital Oneの情報漏えいの一部をシミュレーションしたサンドボックス環境です。
この環境には、次のものが含まれます。
基本的なVPCネットワーク
HTTP(S)とSSHを許可するセキュリティグループ
プライベートS3バケット
IAMロール2つ（S3アクセス権ありと、なし）
パブリックIPアドレスを持ち、S3アクセス権のないIAMロールが割り当てられたEC2インスタンス
EC2インスタンスのシェルアクセスから、プライベートバケット内のS3データにアクセスしてコピーできる状態にすることを目指しました。
各手順を詳しく見る前に、FBIが、サーバーのIPアドレスと3つのコマンドを含むGitHub上のファイルに関する通報をきっかけにアクセスを得たことを指摘しておきます。
「Capital Oneは、4月21日のファイルに3つのコマンドのコードと、700を超えるデータフォルダーまたはバケットの一覧が含まれていたことを確認した。」 これらのコマンドがそれぞれどのようなものだった可能性があるのか、また攻撃者がどのような戦略を使った可能性があるのかを詳しく見ていきます。
ステップ1：ファイアウォールの設定ミス
FBIの告発状によると、「ファイアウォールの設定ミスにより、コマンドがそのサーバーに到達して実行され、フォルダーまたはバケットへのアクセスが可能になった。（III.A.10）」
明示されてはいませんが、これはローカルファイアウォールではなく、サーバーの外部にあるファイアウォールを示唆しています。AWSでは多くの仮想ファイアウォールアプライアンスが利用できますが、一般的にはセキュリティグループでしょう。いずれの種類のファイアウォールが使われていたにせよ、危険なポートが開放されており、これが攻撃の最初の侵入口になった可能性があります。メンテナンス期間中にSSHポートが開放されたままだったのかもしれません。あるいは、開発作業で使われたサーバーが放置され、すでに利用されていなかった可能性もあります。また、MongoDBやElasticSearchなど、動作にポートの開放が必要なアプリケーションをサーバーで実行していたものの、ファイアウォールを通じてインターネットに公開すべきではなかった、という可能性もあります。詳細はどうあれ、攻撃者はCapital Oneのクラウドコンピューティング基盤への侵入経路を見つけました。
ステップ2：EC2インスタンスへのアクセス獲得
FBIの告発状では侵害された対象が「サーバー」と記載され、攻撃者がそこからIAM認証情報を抽出できたとされています。このことから、EC2インスタンスが侵害されたようです。アプリケーションまたはOSの脆弱性が利用された可能性がありますが、実際のところはわかりません。攻撃のシミュレーションでは、攻撃者がインスタンスのroot権限ではなくシェルアクセスを得たと仮定しました。残りの手順は、基本的なシェルアクセスだけで実行できるためです。
ステップ3：IAMロールを通じたS3へのアクセス獲得
…「Capital Oneは、最初のコマンドを実行すると、***-WAF-Roleというアカウントのセキュリティ認証情報が取得され、それによってCloud Computing CompanyにあるCapital Oneの特定のフォルダーへのアクセスが可能になったと判断した。（III.A.11）」
この情報漏えいで大きな役割を果たしたのは、侵害されたサーバーからAWS CLIコマンドを実行し、IAMロール経由でプライベートS3バケットにアクセスしたことのようです。これまで報道ではロール名が大きく取り上げられてきましたが、このサーバー自体がWAFだったことを示す確かな証拠はありません。動的なAWS環境でIAMロールを「借りる」ことはよくあります（よい慣行とは言えませんが、一般的です）。また、以下の例のように、ポリシーとの関連付けを変更でき、名前に「Role」が含まれることもよくあります。管理ツールのダッシュボードに表示するタグもないまま、サーバーが放置されていただけかもしれません。孤立したリソースがどこかに残っていない、大規模なAWSアカウントを見たことはほとんどありません。
サーバー自体がWAFであり、個人識別情報（PII）を含むバケットやオブジェクトへの読み書きアクセス権を意図的に持っていたのであれば、明らかな理由から、それは安易な防御戦略です。特に、ファイアウォールの設定ミスひとつで、機密データを守るためのすべてのアーキテクチャ上の防御を突破できてしまいます。ただし、これだけが情報漏えいの説明ではありません。柔軟性を目的に設計されたIAMとEC2の機能が、追加の権限を付与する形で誤用された可能性もあり、実際にはもっと複雑な事情があったと考えています。
「最初のコマンド」という表現から、AWS CLIスクリプトを指していると考えるのが妥当でしょう。EC2インスタンスがすでにS3へのアクセス権を持っていたなら、攻撃者は次のようなコマンドを実行するだけでよかったはずです。
このコマンドは、EC2インスタンスのメタデータから、ロールに現在割り当てられている一時的なIAM認証情報を取得します。出力は次のようになります。
S3バケットとその内容にアクセスするには、これだけで十分です。
しかし、「最初のコマンド」が何をしたのかについては別の可能性もあり、AWSを使うすべての人が知っておく必要があります。侵害されたサーバーにプライベートS3バケットへのアクセス権がなくても、IAMポリシーを一覧表示して割り当てる権限があれば、攻撃者はその機能を使い、アクセス権を得られる認証情報を探し出した可能性があります。IAM権限はIPレベルのネットワークアクセス制御と結び付いていないことが多く、AWSサービス間の接続にはIAMが使われます。そのため、ロールとポリシーは従来型のネットワークと同様に保護する必要がある、もう一つのネットワークのようなものを形成します。IAMは、クラウド環境内での「ラテラルムーブメント」の主要な手段になります。
たとえば、以下のコマンドは、あるIAM権限のセットを別のセットに置き換えます。
実行すると次のように表示され、既存のIAM権限がDemonstrationEC2Roleポリシーの権限に正常に置き換わったことがわかります。
このような探索に使えるほかのコマンドには、次のものがあります。
これらのコマンドは、名前のとおり、攻撃者がEC2インスタンスのシェルアクセスを得た後に利用できるIAMリソースの一覧を表示します。
この例では、制限付きのIAMプロファイルを、S3への追加権限を持つものに置き換えました。Capital Oneの情報漏えいでも、攻撃者が同様の手法を使った可能性は否定できません。実際にそうだったかどうかにかかわらず、EC2インスタンスのIAMロールを設定する際には、特にインターネットに公開されるインスタンスについて、この機能を重要なリスクとして認識しておく必要があります。IAM権限によって、環境内のプライベートリソースにも実質的に「飛び移る」ことができるためです。
どちらのシナリオでも、攻撃者はS3から情報を取得し、その情報を複製するために必要な認証情報を入手しました。
ステップ4：S3バケットの発見と複製
「Capital Oneは、3番目のコマンド（「Syncコマンド」）を実行すると、***-WAF-Roleを使い、***-WAF-Roleアカウントに必要な権限があるCapital Oneのストレージ領域内のフォルダーまたはバケットからデータを抽出またはコピーしたと判断した。（III.A.11）」
これはAWS CLIコマンドの`aws s3 sync`が使われたことを示唆しています。攻撃者がEC2インスタンスのシェルアクセスを得て、AWS CLIでこれらのコマンドを実行したという見方を裏付ける証拠でもあります。司法省の告発状によると、攻撃者は2番目のコマンドでS3バケットを一覧表示しました。つまり、使用したIAMロールには、S3の読み取り権限だけでなく一覧表示権限もあったようです。1つのIAMロールにこれほど広範なS3権限があることの危険性が浮き彫りになります。標的のバケットを見つける手段がなければ、この段階でも攻撃者はほとんど、あるいはまったくデータを取得できなかったでしょう。
推奨事項
過剰な権限を持つセキュリティグループや、0.0.0.0/0からのアクセスを許可するその他の仕組みを常時監視しましょう。プロビジョニング時の確認は必要ですが、それだけでは到底不十分です。クラウドインフラはAPI経由で作成・変更されるため、さまざまなチームや担当者が操作するうちに、時間の経過とともに設定がずれていくことがよくあります。
最小権限の原則を適用し、ロールを使用するリソースの業務機能に必要な範囲にIAMロールを厳しく制限しましょう。S3の場合、読み取り操作用と書き込み操作用に異なるパブリックエンドポイントを用意し、互いの機能を実行できない別々のIAMロールを割り当てる方法が考えられます。S3バケットの一覧表示を有効にする本番環境でのユースケースはすべてなくし、共有シークレットなどの仕組みに置き換えましょう。
本番環境では、IAMロールのポリシーを割り当てたり置き換えたりできる権限をEC2インスタンスに与えないでください。
過去の開発や本番環境のデバッグで使われ、不要になったクラウドリソース（特にサーバーとS3バケット）は、徹底的に整理して削除しましょう。
ペネトレーションテストに、クラウドインフラの設定ミスの検証を含めましょう。外部のペネトレーションテスターを活用し、クラウドの設定ミスを発見して悪用する方法に精通していることを確認してください。