AWSに潜む見逃せないセキュリティ脅威とは？クラウド活用で知っておくべきその攻撃手法

本記事のサマリ

目次

1. AWS環境を取り巻く脅威
2. 擬似攻撃の手法
　　- 攻撃シナリオ
　　- 構成
　　- 攻撃内容
3. まとめ

1. AWS環境を取り巻く脅威

2019年6月に発覚したCapital One社のセキュリティインシデントは、大規模なAWS環境への攻撃事例として、世間に影響を与えました。このセキュリティインシデントは、WAFとして動作していたEC2インスタンスの設定ミスが原因と言われています。攻撃者はWAFの脆弱性を突いたSSRF（Server Side Request Forgery）攻撃を成功させ、最終的にS3バケットへアクセスして1億人以上の個人情報を窃取しました。

このインシデントをきっかけに、AWS責任共有モデルにおけるユーザの責任、及びAWSセキュリティ対策の重要性が広く認識されました。しかし、皆様は攻撃者がAWS環境へどのように攻撃するのか、具体的な手法についてイメージはお持ちでしょうか。正直なところ、筆者自身はAWSセキュリティの重要性は認識していても、攻撃者が何を標的とし、目的実行に至るまでどのような振る舞いを行うのか、具体的なイメージを持っていませんでした。そこで、AWSセキュリティ学習ツール『CloudGoat』を利用してAWS環境へ擬似攻撃を行いました。その内容を、少しでも皆様の理解の一助になればと考え、本記事にまとめています。

想定されるAWS環境への侵入経路は様々ありますが、共通して言えることは「攻撃者の最初の標的は認証情報である」ということです。攻撃者の最終目的は、AWS上に保管されているデータの窃取・破壊、あるいは大量のEC2インスタンスを立ててマイニングに利用すること、です。これらを実行するために、初めからrootアカウントを入手できれば苦労はないですが、rootアカウントは入手が困難なうえ、ログインするとセキュリティツール検知にされる可能性があります。そのため、多くの場合は何らかの方法で一部の権限のみを持つアカウントを入手し、権限昇格によって目的のサービスを目指します。

2. 擬似攻撃の手法

攻撃シナリオ

前提として、攻撃者は標的企業のEC2インスタンスのIPアドレスを入手しています。

① EC2インスタンスの探索
攻撃者は入手済みIPアドレスへアクセスします。その結果、EC2インスタンスがリバースプロキシとして動作しており、さらにEC2インスタンスメタデータサービス（以下、IMDS）について脆弱な設定が残っていることが判明します。

② EC2インスタンスの一時的な認証情報（以下、インスタンスプロファイル）の取得
攻撃者はインスタンスプロファイルを入手します。インスタンスプロファイルとは、通常、EC2インスタンスを他のAWSサービスと連携して利用するために利用されます。

③ IAMの情報を探索
インスタンスプロファイルにどのような権限が付与されているかを確認します。その結果、S3へのアクセス権限が付与されていることが判明します。

④ S3へのアクセス
重要情報が保管されているS3バケットを探し当て、アクセスします。

⑤ S3バケットからの情報窃取
S3バケットに保存されていたファイルをローカルにダウンロードします。

構成

リージョン内にS3、VPCのサブネット内にEC2インスタンスが稼働しています。S3が意図せず公開されており情報漏洩につながるインシデント事例は多数ありますが、今回の擬似攻撃におけるS3バケットは非公開の設定になっています。

攻撃内容

① EC2インスタンスの探索
攻撃者は、入手済みのIPアドレス宛にHTTPリクエストを送信します。EC2インスタンスがどのような役割を持っているサーバなのかを調べるためです。リクエストの結果、レスポンスとして以下が表示されます。

記載の通り、「169.254.169.254」をヘッダに付与して、再度EC2インスタンスにHTTPリクエストを送信します。その結果、IMDSのAPIが一覧表示されます。
＊169.254.169.254はIMDSへアクセスする際のリンクローカルIPアドレスです。

＊IMDSは、EC2インスタンスに関連するメタデータをAPIによって呼び出すことができるAWSサービスです。メタデータには、インスタンスに設定されているIDやIPアドレス、ホスト名などがあります。便利な一方で、IAMのクレデンシャル情報も容易に取得できてしまうことから、悪用される事例が多くありました。現在はトークンを必須とするIMDS v2がリリースされており、IMDS v1よりもセキュアに利用可能です。しかし、デフォルトではIMDS v1が有効化されたままのため、注意が必要です。本擬似攻撃は、IMDSv1が有効化されている前提で行っています。

② メタデータからIAMの認証情報を取得
一覧のメタデータのうち、IAMクレデンシャルに関するAPIを利用して、IAMロールのロール名を取得します。

取得したIAMロール名を利用して、インスタンスプロファイルを取得します。

③ 取得した認証情報に紐づくIAMの情報を探索
この時点では、攻撃者は取得したインスタンスプロファイルにどのような権限が付与されているのか、わかりません。そこで攻撃者は、インスタンスプロファイルに紐づく情報や権限を調べます。AWSのペンテストツール『Pacu』を使用します。
まずは、インスタンスプロファイルのアカウント情報を調査します。その結果、アカウント情報を見るための権限がないと表示されました。

次に、このアカウントに付与されている権限を調査します。しかし、上記と同様に、付与された権限を確認するための権限がないと表示されました。

最後に、ユーザやロール、ポリシー等の情報を調査します。しかし、上記と同様に、付与された権限を確認するための権限がないと表示されました。

 
以上のことから、取得したインスタンスプロファイルのアカウントにはIAMの閲覧権限がないことがわかりました。

そこで、Pacuのモジュールを使って、ブルートフォース攻撃でAWSの全てのサービスにアクセスし、アクセス可能なサービスを突き止めます。

その結果、EC2の他にS3へのアクセス権限があることがわかりました。

④ S3バケットへのアクセス
攻撃者は、インスタンスプロファイルの情報を利用してローカルでプロファイルを作成します。

* AWS CLIで利用する認証情報は、AWS プロファイルによって管理が可能です。そのため、攻撃者は入手した認証情報をプロファイルに登録し、CLIから利用できるようにします。

その後、セッショントークンを設定ファイルに追加します。これによって、攻撃者の手元にあるCLIから標的のS3へ自由にアクセスが可能になります。

最後に、アクセス可能なS3バケットをリストアップします。すると、「cardholder」という名前を持つS3バケットが見つかります。

⑤ 情報窃取
攻撃者は、④で見つけたバケット内の情報をローカルにダウンロードします。以上で、攻撃者の目的は達成されました。

窃取したファイルには、ダミーの個人情報が含まれています。

3. まとめ

内部情報を持たない攻撃者でも、AWSから提供されているサービスを正規の手順で利用し、クレデンシャルを簡単に入手することがお分かりいただけたでしょうか。入手したクレデンシャルにはIAM権限が付与されていなかったものの、直接S3へアクセスすることができました。
また今回はご紹介できませんでしたが、S3のクロスアカウント設定が有効化されている場合は、標的となったS3から攻撃者環境のS3へ直接ファイルが共有されたり、転送されたりすることもできてしまいます。オンプレミス環境では想定しにくい手法ですが、AWSならではのデータ流出方法があることを認識することが重要です。
AWSセキュリティの考え方や対策について関心をお持ちの方は、ぜひ当社ウェビナー『AWSのセキュリティ対策の勘所とは？』へご登録ください。ウェビナーでは、攻撃者の視点に基づいたAWSセキュリティ対策の課題と解決策をご紹介します。本記事でご紹介した擬似攻撃についても、より詳細に解説しています。また、弊社ではAWSセキュリティソリューションとして、Vectra AI 社「Detect for AWS」を取り扱っております。ご興味のある方は、下記よりお問い合わせくださいませ。