whoAMI attacks give hackers code execution on Amazon EC2 instances

セキュリティ研究者は、特定の名前でAmazon Machine Image（AMI）を公開した人にAmazon Web Servicesアカウントへのアクセスを可能にする名前混同攻撃を発見した。

whoAMI “と名付けられたこの攻撃は、2024年8月にDataDogの研究者によって作成され、ソフトウェアプロジェクトがAMI IDを取得する方法を悪用することで、攻撃者がAWSアカウント内でコードを実行できることを実証した。

アマゾンはこの脆弱性を確認し、9月に修正プログラムをリリースしたが、組織がコードの更新を怠っている環境では、この問題は顧客側で残っている。

whoAMI攻撃の実行

AMIは、AWSのエコシステムではEC2（Elastic Compute Cloud）インスタンスと呼ばれる仮想サーバーを作成するために必要なソフトウェア（オペレーティングシステム、アプリケーション）があらかじめ設定された仮想マシンである。

AMIにはパブリックとプライベートがあり、それぞれに固有の識別子がついている。パブリックAMIの場合、ユーザーはAWSカタログから必要なAMIの正しいIDを検索できる。

AMI が AWS マーケットプレイスの信頼できるソースからのものであることを確認するために、検索は ‘owners’ 属性を含む必要がある。

WhoAMI 攻撃は、AWS 環境における AMI の選択ミスが原因で発生する可能性がある：

  1. ec2:DescribeImages API を使用するソフトウェアが、所有者を指定せずに AMI を取得する。
  2. スクリプトが特定の AMI ID の代わりにワイルドカードを使用する。
  3. Terraformのようないくつかのinfrastructure-as-codeツールが “most_recent=true “を使用し、フィルタに一致する最新のAMIを自動的に選択する。

これらの条件により、攻撃者は信頼できるリソースと同様の名前を付けることで、悪意のあるAMIを選択プロセスに挿入することができる。所有者を指定しない場合、AWS は攻撃者のものを含め、一致するすべての AMI を返す。

most_recent “パラメータが “true “に設定されている場合、被害者のシステムはマーケットプレイスに追加された最新の AMI を提供する。

Demonstrating the retrieval of a malicious instead of a trusted AMI
信頼できる AMI ではなく悪意のある AMI を検索するデモ
ソースはこちら：DataDog

基本的に、攻撃者が行う必要があるのは、信頼できるオーナーが使用するパターンに一致する名前のAMIを公開し、ユーザーがそれを選択してEC2インスタンスを起動することを容易にすることだけである。

whoAMI攻撃は、ターゲットのAWSアカウントに侵入する必要はない。攻撃者はAWSアカウントさえあれば、バックドアされたAMIをパブリックなCommunity AMIカタログに公開し、ターゲットのAMIを模倣した名前を戦略的に選択することができる。

Datadogは、同社の遠隔測定に基づき、同社が監視する組織の約1％がwhoAMI攻撃に対して脆弱であるが、「この脆弱性は、おそらく数千の異なるAWSアカウントに影響を与える」と述べている。

アマゾンの対応と防御策

DataDogの研究者はこの欠陥についてAmazonに通知し、同社は社内の非生産システムがwhoAMI攻撃に対して脆弱であることを確認した。

この問題は昨年9月19日に修正され、12月1日にAWSは「Allowed AMIs（許可されたAMI）」という新しいセキュリティコントロールを導入し、顧客が信頼できるAMIプロバイダーの許可リストを作成できるようにした。

AWSは、この脆弱性はセキュリティ研究者のテスト以外では悪用されなかったため、whoAMI攻撃によって顧客データが漏洩することはなかったと述べている。

Amazonは顧客に対し、”ec2:DescribeImages “APIを使用する際には必ずAMIの所有者を指定し、さらなる保護のために “Allowed AMIs “機能を有効にするようアドバイスしている。

この新機能はAWS Console → EC2 → Account Attributes → Allowed AMIsから利用できる。

昨年11月から、Terraform 5.77では “most_recent = true “が所有者フィルタなしで使用された場合、ユーザーに警告を出すようになった。

システム管理者はAMIを安全に取得するために、AMIソース(Terraform, AWS CLI, Python Boto3, Go AWS SDK)の設定を監査し、コードを更新する必要があります。

信頼できないAMIが現在使用されているかどうかを確認するには、’Allowed AMIs’からAWS Audit Modeを有効にし、’Enforcement Mode’に切り替えてブロックする。

DataDogはまた、信頼されていないAMIから作成されたインスタンスのAWSアカウントをチェックするスキャナもリリースしており、このGitHubリポジトリで利用可能だ。