本文へスキップ
ブログへ戻る

スレットリサーチ

攻撃者がインスタンスメタデータを使用してAWSのアプリケーションを侵害する可能性がある方法

2022年3月22日

By Thyaga Vasudevan - VP of Product Management、Skyhigh Security

エンタープライズ・アプリケーションをクラウドネイティブ・アーキテクチャに移行することで、スケールとアジリティを向上させながら、パッチ適用やサーバー・インフラのアップグレードといった面倒な作業を軽減し、多大なビジネス価値を提供することができます。

しかし、Amazon Web Services(AWS)、Azure、Google Cloudなど、あらゆるクラウド環境において、新しいカテゴリーのリスクが存在する。クラウドネイティブの脅威は、クラウド環境における新しいコンテキストと設定要件に起因しています。歴史的に、ストレージ・オブジェクトへのパブリック・アクセスなどのデフォルト設定では、機密データが公開されたままになっており、このような弱点を探している人がいれば、簡単に盗むことができます。

クラウド事業者による新機能の追加に伴い、新しい設定が次々と導入される新しい環境では、間違いを犯しがちです。クラウド環境の設定は、常にお客様の責任です。AWSなどは、お客様がどのようにサービスを使うかをコントロールすることはできません。AWSなどは、お客様が構築するためのテンプレートです。

クラウドネイティブなアプリケーションを構築する際に、設定の結果を理解していないと、致命的な結果を招くことがあります。そして、最も賢明なクラウドカスタマーでさえ、このような結果に見舞われる可能性があります。

その例として、Capital Oneが約3年前に起こした情報漏洩事件では、攻撃者が1億人の米国人の社会保障番号と600万人のカナダ人の社会保険番号にアクセスした。攻撃者はデータへのアクセスにいくつかの手法を用いましたが、この攻撃から得た重要な教訓は、仮想マシン(Elastic Compute CloudまたはECインスタンス)へのアクセスを保護するために設計されたセキュリティ機能が、攻撃者を追加したことでした。この機能は、インスタンス・メタデータ・サービス(IMDS)と呼ばれています。

インスタンス・メタデータの攻撃

IMDSのバージョン1(IMDSv1)は2012年にリリースされ、EC2インスタンスが他のAWSサービスとやり取りするための、より安全な方法を可能にしました。AWSキーをインスタンスに残す代わりに、EC2インスタンスがメタデータサービスに問い合わせて認証情報を取得し、他のAWSサービスに対してAWS APIコールを行うことができるようになった。例えば、EC2インスタンスが顧客データを取得した場合、IMDSv1を使ってそのデータをAmazon Simple Storage Service(S3)バケットに保存することができます。攻撃者がCapital Oneの顧客情報を保存するためのS3バケットから機密情報を引き出すために使用したのは、まさにこの機能だったのです。

私たちのテストでは、このデータの抽出がどのようなアプリケーションでどのように機能するかを再現することができました。この例では、疫学者のチームがAWSでクラウドネイティブなアプリケーションを構築し、ウイルスゲノムの解析の進捗を示すデータを視覚的に表現するための公開ダッシュボードを備えています。

 

このアプリケーションの開発段階で、チームはある難題にぶつかりました。仮想プライベートクラウド(VPC)内のリソースのほとんどは、インターネットから隠されているはずだったのです。VPCの中で唯一、一般公開を想定していたのがダッシュボードです。

データをホストするS3バケットは、プライベートに保つ必要がありました。S3から公開ダッシュボードにデータを引き出すために、彼らはリバースプロキシーを追加し、仲介役として機能させました。Googleで検索して、数行のコードを書くだけで、アプリケーションにこれを追加することができました。

 

疫学者のチームにとって、リバースプロキシは基本的でエレガントなソリューションであり、彼らのユースケースには完璧に機能するものでした。しかし、それが大規模な情報漏えいを引き起こすことになるとは思いもよりませんでした。

リバースプロキシが動作するコンピュートインスタンスには、プライベートS3バケットにアクセスする権限を持つIAMロールが割り当てられていました。リバースプロキシがS3にアクセスするための認証情報は、Instance Metadataから取得した。

このサイトを訪問し、データに興味を持った攻撃者は、チームがダッシュボードでリバースプロキシのIPアドレスを参照していることに気づきました。そして、攻撃者はそのIPアドレスに接続できるかどうかを確認しました。接続を確認した後、攻撃者はリバースプロキシを通じてインスタンスのメタデータにアクセスできるかどうかを確認しました。成功しました。

リバースプロキシとインスタンスメタデータから、攻撃者はチームのプライベートS3ストレージバケットへの認証情報を発見しました。

 

S3バケットにアクセスすることで、攻撃者はチームがアプリケーションのために保存していた非常に機密性の高いデータを盗むことができるようになりました。攻撃者は、ターゲットのS3バケットを別のAWSアカウントにある自分のS3バケットに同期させるだけで、データは自分のものになりました。

 

この種の攻撃は、MITREがクラウド環境向けのATT&CKフレームワーク(https://attack.mitre.org/matrices/enterprise/cloud/)で説明している43のテクニックの1つに過ぎない。

AWSのインスタンス・メタデータ攻撃の軽減方法について

このサービスのセキュリティを向上させるために、AWSはいくつかの新しい保護層を追加したIMDSv2をリリースしました。

IMDSv2では、外部ユーザーによるクレデンシャルの受信がブロックされ、アプリケーションリソースのみがクレデンシャル を受信できるようになる。この保護レイヤーとIMDSv2の詳細については、https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/

しかし、IMDSv1がまだ生きているという課題は残っています。AWSには顧客がIMDSv1を使用することを妨げるものはなく、すべてのEC2インスタンスでデフォルトで使用することができます。先に述べたように、お客様がクラウドを安全に使用していることを確認するのはAWSの責任ではありません。その責任は、あくまでお客様にあります。

先ほど説明した攻撃では、リバースプロキシが誤って設定され、外部からのリクエストが内部リソースに到達することを許していました。もし、このチームがIMDSv2を使用するようにコンピュートインスタンスを構成していれば、外部の脅威行為者による不正なアクセスはブロックされていたはずです。

スカイハイのクラウドネイティブアプリケーションプロテクションはどのように役立つのでしょうか。

Skyhigh Security では、このような攻撃を検知・防止するのに役立つアプローチをいくつか用意しています。Skyhigh Cloud Native Application Protection Platform (CNAPP)は、AWS、Azure、GCPのコンフィギュレーションを監視・更新できる当社のクラウドネイティブなセキュリティプラットフォームです。

スカイハイCNAPPは、AWSとの直接のAPI連携により、アプリケーションやインフラの監視サービスであるAmazon CloudWatchを継続的に監視し、各EC2インスタンスで使用しているIMDSのバージョンを表示します。

IMDSv1をアクティブに使用しているインスタンスがCloudWatchに記録されると、Skyhigh CNAPPはセキュリティインシデントを生成し、IMDSv2への設定更新を通知します。これにより、外部ユーザーによる認証情報への不正なアクセスを防止できます。

IMDSバージョン設定におけるスカイハイCNAPPポリシーインシデント

すべてのローカルコードとユーザーに対して、EC2インスタンス上でIMDSv2を強制することがベストプラクティスです。IMDSv2を使用するよう指定すると、IMDSv1は機能しなくなります。AWSは、IMDSv2を使用するためにインスタンスを構成する方法について、ステップバイステップで説明しています。

この攻撃例以外にも、Skyhigh CNAPPでは、クラウドネイティブなアプリケーションを保護するための一連のベストプラクティスを実装することができます:

  • 設定の継続的な監査Skyhigh CNAPPを使用すると、本番環境に入る前にAWS CloudFormationテンプレートをスキャンし、時間の経過に伴う構成の「ドリフト」を検出できます。これにより、設定ミスを検出し、リソースの権限に最小特権モデルを適用できます。
  • ゼロトラストを実施する。ゼロ・トラストを方法論として使用し、特定のリソースにのみ実行と相互通信を許可する。それ以外はすべてブロックする。
  • コードの脆弱性をスキャンする。特にDockerのようなオープンソフトウェアの配布モデルでは、アプリケーションリソースの脆弱性を継続的に監視することが重要です。
  • 異常と脅威を検出ユーザーとエンティティの行動分析(UEBA)により、何百万ものクラウドイベントを評価し、クレデンシャルの盗難のような異常なアクティビティや実際の脅威を発見することができます。
  • ストレージオブジェクトに対してDLPを実行する。他のクラウドサービスやネットワーク、エンドポイントと同様に、AWSでもS3内のデータを分類し、data loss prevention 。

あなたの組織でこれらの対策を実施することについて、私たちにご相談ください。

ブログへ戻る