Amazon EC2 インスタンスでの不正なコード実行：名前混乱による whoAMI 攻撃に御用心

whoAMI attacks give hackers code execution on Amazon EC2 instances

2025/02/13 BleepingComputer — 特定の名前を用いて、Amazon Machine Image (AMI) を公開する誰もが、Amazon Web Services アカウントにアクセスできてしまうという名前混乱の攻撃方法を、セキュリティ研究者たちが発見した。この “whoAMI” と呼ばれる攻撃の手法は、2024年8月に DataDog の研究者たちにより考案／作成されたものであり、ソフトウェア・プロジェクトによる AMI ID 取得の方式を悪用する攻撃者が、AWS アカウント内でコード実行を可能することを実証している。

この脆弱性を認めた Amazon は、2024年9月に修正をリリースしたが、コードを更新していないユーザー組織の環境では、問題が残ってしまうという。

whoAMI 攻撃の実行

AWS エコシステムの EC2 (Elastic Compute Cloud) インスタンスと呼ばれる、仮想サーバを作成するために使用される AMI は、必要とされるソフトウェアである OS やアプリケーションをプレコンフィグした仮想マシンのことである。

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

その AMI が、AWS マーケットプレイスの信頼できるソースから得られたことを確認するためには、検索において “owners” 属性を取り込む必要がある。それが欠落すると、whoAMI 名混同攻撃のリスクが高まる。

AWS 環境での AMI 選択におけるミスコンフィグ原因となり、whoAMI 攻撃が発生する可能性がある：

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

これらの条件を悪用する攻撃者は、対象となるリソースに信頼できるものに似た名前を付けることで、選択プロセスに悪意の AMI を挿入できる。さらに、 “owners” を指定しないことで、AWS は攻撃者の AMI を含めて、すべての一致する AMI を返してしまう。

パラメータ “most_recent” に “true”が設定されている場合には、マーケットプレイスに追加された最新の AMI を、被害者のシステムは提供してしまう。そこには、正当なエントリに似た名前を持つ、悪意の AMI が含まれる可能性がある。

Demonstrating the retrieval of a malicious instead of a trusted AMI
Demonstrating the retrieval of a malicious instead of a trusted AMI
Source: DataDog

攻撃者にとって基本的に必要なことは、信頼できる所有者が使用するパターンに適合する名前で AMI を公開し、ユーザーに簡単に選択させ、EC2 インスタンスを起動できるようにすることだ。

つまり whoAMI 攻撃では、ターゲットの AWS アカウントに侵入する必要はない。公開コミュニティ AMI カタログに、バックドアを仕掛けた AMI を公開する攻撃者が必要とするのは、ターゲットの AMI を模倣した名前を戦略的に選択する AWS アカウントだけである。

Datadog はテレメトリに基づき、現時点で監視している組織の約 1% が、whoAMI 攻撃に対して脆弱であると述べている。ただし、「この脆弱性は、数千の AWS アカウントに影響を与える可能性がある」とも指摘している。

Amazon の対応と防御策

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

この問題は、2024年9月19日に修正された。そして、12月1日に AWS は、”Allowed AMIs” という新しいセキュリティ制御を導入し、信頼できる AMI プロバイダーの許可リストを、ユーザーが作成できるようにした。

DataDog のセキュリティ研究者たちのテスト以外で、この脆弱性は悪用されず、また、whoAMI 攻撃により顧客データが侵害されたこともないと、AWS は述べている。

ユーザーに対して Amazon が推奨するのは、”ec2:DescribeImages” API を使用する際には、必ず AMI owners を指定し、追加の保護として “Allowed AMIs” 機能を有効化することだ。この新しい機能は、AWS Console → EC2 → Account Attributes → Allowed AMIs で利用できる。

2024年11月から Terraform 5.77 では、所有者フィルターなしで “most_recent = true” が使用されている場合に、ユーザーに対して警告が表示されるようになった。今後のリリースである 6.0 では、より厳格な適用が予定されているという。

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

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

DataDog は、信頼できない AMI から作成されたインスタンスの有無を、AWS アカウント内でチェックするためのスキャナも、GitHub リポジトリでリリースしている。

クラウド環境のセキュリティは、日々進化する脅威にさらされています。この脆弱性は、2024年9月に修正され、同年の 12月には新しいセキュリティ制御が導入されているとのことです。ご利用のチームは、ご確認ください。よろしければ、_Cloud で検索も、ご参照下さい。