攻撃者がインスタンスメタデータを使用してAWSでアプリを侵害する方法

チャガ・ヴァスデヴァン（製品管理担当VP、Skyhigh Security）

2022年3月22日 5 分で読めます

エンタープライズアプリケーションをクラウドネイティブアーキテクチャに移行することで、サーバーインフラストラクチャのパッチ適用やアップグレードといった面倒なタスクを軽減しつつ、スケールと俊敏性を高め、計り知れないビジネス価値をもたらすことができます。

しかし、Amazon Web Services (AWS)、Azure、Google Cloudのいずれのクラウド環境においても、新たなリスクカテゴリが存在します。クラウドネイティブな脅威は、クラウド環境における新たなコンテキストと構成要件から生じます。歴史的に、ストレージオブジェクトへのパブリックアクセスなどのデフォルト設定は、機密データを公開状態のままにしてきたため、これらの脆弱性を探す者によって簡単に盗まれてきました。

クラウドプロバイダーによって新しい機能が追加されるにつれて、新しい設定が継続的に導入されるため、新しい環境では間違いを犯しやすいものです。クラウド環境の構成は常にユーザーの責任です。AWSなどは、ユーザーがサービスをどのように使用するかを制御することはできません。それらはユーザーが構築するためのテンプレートにすぎません。

構成の結果やクラウドネイティブアプリケーションの構築方法を理解していないと、壊滅的な結果を招く可能性があります。そして、最も精通したクラウド顧客でさえ、これらの結果に苦しむことがあります。

具体的な例として、約3年前にCapital Oneが被った侵害があります。この侵害では、攻撃者が米国人1億人分の社会保障番号とカナダ人600万人分の社会保険番号にアクセスしました。攻撃者はデータにアクセスするためにいくつかの手法を使用しましたが、この攻撃から得られた重要な教訓は、仮想マシン（Elastic Compute CloudまたはECインスタンス）へのアクセスを保護するために設計されたセキュリティ機能が、攻撃者を追加したという点でした。この機能はInstance Metadataサービス、略してIMDSと呼ばれています。

Instance Metadata攻撃

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

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

 

このアプリケーションの開発段階で、チームは課題に直面しました。彼らのVirtual Private Cloud (VPC) 内のほとんどのリソースは、インターネットから隠されるべきでした。彼らのVPC内で一般公開を意図していた唯一のリソースはダッシュボードでした。

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

 

疫学者チームにとって、リバースプロキシは彼らのユースケースに完璧に機能する基本的で洗練されたソリューションでした。彼らが気づかなかったのは、それが大規模な侵害の準備を整えてしまったということでした。

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

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

リバースプロキシを介して、そしてInstance Metadataから、攻撃者はチームのプライベートS3ストレージバケットへの認証情報を発見しました。

 

今やS3バケットへのアクセス権を得た攻撃者は、チームがアプリケーション用に保存していた非常に機密性の高いデータを盗むことができました。攻撃者は単にターゲットのS3バケットを別のAWSアカウントにある自身のS3バケットに同期させ、データは彼らのものとなりました。

 

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

AWSがInstance Metadata攻撃を軽減する方法

このサービスのセキュリティを向上させるため、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 Cloud Native Application Protectionがどのように役立つか

Skyhigh Securityでは、このような攻撃を検知し、防止するのに役立ついくつかのアプローチを提供しています。Skyhigh Cloud Native Application Protection Platform (CNAPP)は、AWS、Azure、GCPの構成を監視および更新できる当社のクラウドネイティブセキュリティプラットフォームであり、ここで詳細をご覧いただける幅広い追加のセキュリティ対策も備えています。

AWSとの直接API統合を使用し、Skyhigh CNAPPは、アプリケーションおよびインフラストラクチャ監視サービスであるAmazon CloudWatchを継続的に監視し、各EC2インスタンスでどのバージョンのIMDSを使用しているかを示します。

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

Skyhigh CNAPPのIMDSバージョン構成に関するポリシーインシデント

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

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

• 設定を継続的に監査する。Skyhigh CNAPPを使用すると、AWS CloudFormationテンプレートが本番環境に導入される前にスキャンし、時間の経過とともに設定に発生する「ドリフト」を検出できます。これにより、設定ミスを検出し、リソース権限に最小特権モデルを適用できます。
• ゼロトラストを適用する。ゼロトラストを手法として使用し、特定のリソースのみが実行および相互通信を許可され、それ以外はすべてブロックされます。
• コードの脆弱性をスキャンする。特にDockerのようなオープンソフトウェア配布モデルでは、アプリケーションリソースの脆弱性を継続的に監視することが重要です。
• 異常と脅威を検出する。ユーザーおよびエンティティ行動分析（UEBA）により、数百万のクラウドイベントを評価し、異常なアクティビティや認証情報の盗難などの実際の脅威を明らかにすることができます。
• ストレージオブジェクトでDLPを実行。承認する他のクラウドサービス、ネットワーク、またはエンドポイントと同様に、AWS内ではS3内のデータを分類し、Data Loss Preventionを実行してデータ持ち出しの試みを阻止できますし、そうすべきです。

お問い合わせください。これらの対策を貴社で実施することについてご相談いただけます。

ブログへ戻る