本文の内容は、2023年2月28日にALBERTO PELLITTERIが投稿したブログ（https://sysdig.com/blog/cloud-breach-terraform-data-theft)を元に日本語に翻訳・再構成した内容となっております。 Sysdig 脅威リサーチチームは、最近、お客様環境において、「SCARLETEEL」と名付けられた、専有データを盗まれるような巧妙なクラウドオペレーションを発見しました。攻撃者は、コンテナ化されたワークロードを悪用し、それを利用してAWSアカウントへの権限昇格を行い、独自のソフトウェアと認証情報を盗み出しました。また、Terraformのステートファイルを使用して、接続されている他のAWSアカウントにピボットし、組織全体に範囲を広げようとしました。 この攻撃は、侵害されたKubernetesコンテナから始まり、被害者のAWSアカウントに広がったため、他の攻撃よりも高度なものでした。また、攻撃者はElastic Compute Cloud（EC2）のロール、Lambdaサーバーレス機能、Terraformなど、AWSのクラウド機構に関する知識も持っていました。最終的な結果は、単なる典型的なクリプトジャッキング攻撃ではありませんでした。攻撃者の動機は、より悪質なもので、独自なソフトウェアの窃取でした。 クラウドにおけるサイバー攻撃は、過去1年間で56%も増加しています。クラウド内のパーシステンスの取得、機密データの漏洩、クリプトマイニングに使用するEC2インスタンスなどの新規リソースの作成などが、最も一般的な動機です。このようなリソースは、組織のクラウド料金に深刻な影響を与える可能性があります。しかし、よりスパイに近い動機も健在です。現実には、攻撃者はクリプトマイニング以外にもクラウドのリソースを利用することができます。 今回目撃された巧妙な攻撃には、クラウドベースのインフラストラクチャーを保護することの複雑さの根底にある、さまざまな側面があります。脆弱性管理だけでは、すべてに対処することはできません。むしろ、仮想マシン、クラウドセキュリティポスチャー管理（CSPM）、クラウドインフラストラクチャーエンタイトルメント管理（CIEM）、ランタイム脅威検出、シークレット管理など、高度な脅威からのリスクを軽減できるツールが多数あります。
概要
このインフォグラフィックは、キルチェーンにおける主なステップを表しています。まず、攻撃を高いレベルで示し、その後、各ステップの詳細を説明します。
- ステップ1：攻撃者は、AWSクラウドアカウント内でホストされている自己管理Kubernetesクラスターのパブリック向けサービスを悪用して、初期アクセスを取得しました。
- ステップ2：攻撃者がPodへのアクセスを獲得すると、マルウェアは実行中に2つの初期アクションを実行することができました。
- 金銭を稼ぐため、または気晴らしを提供するためにクリプトマイナーを起動する。
- Instance Metadata Service (IMDS) v1のワーカーの一時的なクレデンシャルを通じてクレデンシャルアクセスを取得し、クラスターロールのパーミッションを使用してワーカーに代わって情報を列挙し収集します。過剰に付与されたパーミッションにより、攻撃者は以下のことを行うことができました。
- AWSリソースを列挙する
- Lambdaの環境変数として設定され、Amazon Simple Storage Service（S3）バケットに平文でプッシュされた他のIDおよびアクセス管理（IAM）ユーザーの資格情報を見つける
- ステップ3：攻撃者は、前のステップで見つかった認証情報を使って、横方向に移りました。彼らはAWS APIに直接コンタクトし、さらにアカウントを列挙し、情報収集とデータの持ち去りを進めました。このステップの間、彼らは以下のことを行うことができました。
- CloudTrailのログを無効化し、検知を回避する
- 独自なソフトウェアの窃取
- S3バケット内のTerraformステートファイルを発見することで、別のAWSアカウントに関連するIAMユーザーの資格情報を見つける
- ステップ4：攻撃者は新しい認証情報を使って再び横方向に移り、見つけた別のAWSアカウントから攻撃とそのキルチェーンを繰り返しました。幸いなことに、このケースでは、彼らが試みたAWS APIリクエストのすべてが権限不足のために失敗したため、リソースを列挙することはできませんでした。
技術的な分析
初期アクセス – コンテナの侵害
攻撃者は、Kubernetesクラスターにデプロイされたインターネットに公開されたサービスを発見し、悪用しました。彼らはコンテナにアクセスすると、攻撃を続行するためにさまざまなアクションを実行し始めました。 私たちが記録した最初のアクションは、いくつかのメモリサイクルを盗むためにマイナーをダウンロードして起動することでした。これは、”2022 Cloud-Native Threat Report “で報告したように、自動化されたコンテナの脅威でよく見られる行為です。ここに見られるように、攻撃者はXMRig実行ファイルを実行するためにスクリプトminer.shを起動し、マイナーの設定ファイルconfig_background.jsonと一緒に実行しています。
しかし、この攻撃の目的は、クリプトマイニングをはるかに超えるものでした。クリプトマイニングが攻撃者の最初の目標で、被害者の環境にアクセスした時点で目標が変更されたか、またはクリプトマイニングがデータ漏洩の検出を回避するためのおとりとして使用されたかのどちらかです。クリプトマイニングのインストール中、コンテナ上でbashスクリプトが同時に実行され、クレデンシャルなどの環境内の追加情報を列挙して抽出する様子が確認されました。
認証情報を見つけるために、攻撃者はIMDSに直接アクセスしていました。IMDS v1は、AWSで古いバージョンのセルフマネージドクラスターやEC2インスタンスを作成する際にデフォルトで使用されるバージョンです。マシンの設定や管理に使用されます。
IMDS v1からEC2インスタンスのロールにバインドされたAWS一時セキュリティ認証情報を取得することは、以前のブログ記事で取り上げたように、非常によく知られている行為です。攻撃者は、実行中のワーカーインスタンスにバインドされたIAMロールを発見する可能性があります。
role_name=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/)を実行し、後で AccessKeyId、SecretAccessKey、およびテンポラリ トークンを取得します：
metadata_content=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/$role_name)IMDS v1への悪意のあるリクエストを見ると、「internal use only」と記述され、AWSのドキュメントで説明されているあまり知られていない内部エンドポイントへのリクエストも発見されました。
metadata_content=$(curl http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance)以下のスクリーンショットは、攻撃者がインスタンスのメタデータエンドポイントの両方をターゲットにし、IAMロールキーをgrepして取得するために、悪意のあるスクリプトによってどのようなコマンドが実行されたかを示しています。
いったん収集されると、なりすましたIAMロールの代わりにAWS APIを直接呼び出して操作を実行するために、それらの認証情報を短期間使用することが可能です。CloudTrailログを使用すると、クラスターロールを使用した攻撃者からの最初のAPIコールを確認することができます。
攻撃者はAWSプラットフォーム上で永続性を得るためにいくつかのAWSアクションを実行し、新しいユーザ、グループを作成し、既存のIAMユーザに新しいアクセスキーをバインドしようとしました。幸いなことに、これらの実行はすべて、攻撃者が使用していたアカウントの権限不足のために拒否されました。
残念なことに、AWSのクラスターロールに過剰な読み取り権限が誤って設定されていました。本来の目的は、特定のS3バケットの読み取りを許可することでしたが、このパーミッションにより、ロールはアカウント内のすべてを読み取ることができ、攻撃者はLambdaを含むAWSアカウントに関するさらなる知識を獲得することができました。
ディスカバリー – AWSクラウド
攻撃者がクラウドアカウントへの初期アクセスを取得すると、AWSアカウントにデプロイされたリソースについての情報収集を開始しました。以下の表で報告されているアクティビティは、AWSアカウントで記録されたAPIリクエストの一部だけです。
これらのスクレイピング操作の間、攻撃者は最も使用されているAWSサービスに努力を集中させました。サーバーレスLambda function とS3バケットです。
Lambda functionの列挙 – 盗まれた独自コードとソフトウェア
この記事で指摘したように、Lambda functionをはじめとするサーバーレス functionは、下層のインフラストラクチャーを気にせずカスタムコードを実行するためによく使われ、エンドユーザーにとって多くの自由度が残されています。 影響を受けたAWSアカウントには、主にアカウントの自動化に関連するさまざまなLambda functionが存在しました。 攻撃者は、適切なAPIコールを使用して、AWSアカウントの特定のリージョンにあるすべてのLambda functionを列挙し、取得することを開始しました。例えば、以下のAWSコマンドを使用してfunctionを列挙することができます。裏側は単なるREST APIコールなので、このタスクを実現する方法はたくさんあります。aws lambda list-functionsfunctionのリストを取得した後、攻撃者はLambdaのコードをダウンロードすることでさらに深堀りを試みました。以下のAWS APIを呼び出して、Lambdaを構成するコードをダウンロードできるように、コードの場所を取得することができました。この場合、Lambda functionは独自のソフトウェアと、それを実行するために必要なキーを保持していました。
aws lambda get-function --function-name $function_name --query 'Code.Location'curlまたはwgetコマンドを使用して、攻撃者はLambdaのコードの流出に成功し、Lambda functionから独自のコードとソフトウェアを盗み出しました。また、攻撃者が盗んだソフトウェアを実行した証拠もありました。 彼らは時間をかけてLambda functionの環境変数を調べ、以下のようなコマンドを使用して、同じアカウントのIAMユーザーに関連する追加のAWS認証情報を見つけました。
aws lambda list-versions-by-function --function-name $function_name次の攻撃ステップでわかるように、敵対者はここで見つけた認証情報を使って、新しいユーザーで列挙を再試行し、新しい発見を得たり、アカウント内の特権昇格の可能性を評価したりすることを狙ったのです。
S3バケット列挙
Amazon S3は、ユーザーがデータを保存・取得できるストレージサービスとして広く普及しています。 攻撃者はしばしば、S3バケットに保存されたリソースやファイルを標的として、情報や認証情報を抜き取ります。過去には、設定ミスのあるS3バケットや、パスワードやセキュリティ対策なしに公開されたままのS3バケットを悪用した侵入が多数ありました。今回の攻撃では、お客様のスクリプト、トラブルシューティングツール、ログファイルなど、1TBを超える情報を取得し、読み取ることが可能でした。
CloudTrailは、その機能が明示的に要求されない限り、S3バケットに格納されたオブジェクトのデータイベントを記録しません。今回のケースでは、その機能がオンになっていなかったため、特定のオブジェクトのアクセスに関する情報を確認することができません。しかし、攻撃者は機密データを探してバケットを調べていたことは確かです。利用可能なストレージを消費せずに追求を加速するために、TruffleHogのようなツールを使って、すぐに新しいAWSユーザー認証情報を取得し、クラスター内での横移動を続けていたのかもしれません。
1TBのデータには、インフラストラクチャーの一部をデプロイするためにアカウントで使用されたTerraformに関連するログファイルも含まれていました。これらのTerraformファイルは、攻撃者が別のAWSアカウントにピボットしようとした後のステップで重要な役割を果たすことになります。
防御回避 – CloudTrailログの無効化
攻撃者がクラウドアカウントにアクセスすると、侵害されたアカウント内でCloudTrailのログを無効にしようとしました。以下のスクリーンショットからわかるように、攻撃者は、前のステップで侵害されたユーザーの1人に割り当てられた特別な権限のために、アカウントで構成されたログの一部を無効にすることに成功しました。
このアクションの結果、追加の攻撃証拠を取得することができませんでした。アカウントの権限を見直す場合、セキュリティログを無効化したり削除したりする権限を、できるだけ少数のユーザーに留めることが重要です。削除は、強固なバックアップソリューションがなければ、ほとんどの状況で可能でないはずです。
クレデンシャルアクセス – Terraform stateファイル
TerraformはオープンソースのIaC（Infrastructure as Code）ツールで、クラウド環境でインフラストラクチャーをデプロイ、変更、作成するために使用されます。 Terraformは、どのリソースが制御下にあり、いつ更新・破棄すべきかを知るために、デフォルトではterraform.tfstateという名前の状態ファイルを使用します。Terraformを継続的インテグレーション／継続的デリバリー（CI/CD）パイプラインに統合して自動化する場合、この状態ファイルに適切なパーミッションでアクセスできる必要があります。特に、パイプラインを実行するサービスプリンシパルは、ステートファイルを保持するストレージアカウントコンテナにアクセスできる必要があります。そのため、Amazon S3バケットのような共有ストレージは、状態ファイルを保持するための完璧な候補となります。 しかし、Terraform stateファイルにはすべてのデータがプレーンテキストで含まれており、その中にはシークレットが含まれている可能性があります。安全な場所以外にシークレットを保存するのは決して良い考えとは言えませんし、絶対にソース管理下に置くべきではありません! 攻撃者は、利用可能なバケットをリストアップし、すべてのデータを取得することができました。インシデント調査中にPacuやTruffleHogなどの異なるツールでデータを調べると、S3バケット内のterraform.tfstateファイルに平文のIAMユーザーのアクセスキーとシークレットキーの両方を見つけることが可能でした。以下はTruffleHogのスクリーンショットです。
これらのIAM認証情報は、2番目に接続されたAWSアカウントのものであり、攻撃者が組織全体に攻撃を広げるために横方向に移動する機会を与えています。
横方向への移動 – AWSアカウント
新しい認証情報を取得した攻撃者は、この追加で漏洩したアカウント内部から追加のリソースを獲得できるかどうかを判断するために、列挙と情報収集のプロセスを再開させました。さらに、CloudTrailは、上記の接続されたAWSアカウントで不審な活動を記録しました。 攻撃者は、接続されたクラウドアカウントの異なるAWSリソースに対して、列挙を実行しようとしました。幸いなことに、IAMユーザーは非常によくスコープされていたので、すべてのリクエストはパーミッション不足のために失敗し、デフォルトで許可されている無害なGetCallerIdentity APIだけが残りました。
推奨事項
今回報告された攻撃は、脅威者がクラウドを主な目標として到達しようとしていることを明確に示しています。攻撃者は有効な認証情報を取得するとすぐにクラウド内で横方向に移動し、独自コードのような貴重な情報を見つけようとしましたが、すべては侵害されたサービスから始まりました。また、他のクラウドアカウントにピボットして、さらに多くの情報を得ようとしました。 以下は、より注意深くなるための主なポイントです：- アプリケーションと公開用コンテナにパッチを当て、脆弱性管理サイクルを適用してください。自分が何を公開したかを認識し、パッチ適用作業の優先順位をつけることができます。
- IMDS v1 の代わりに IMDS v2 を使用する。この強化バージョンでは、セッション指向のリクエストを要求し、不正なメタデータアクセスに対する深層防御を追加しています。さらに、クラスター内で許可されたPodのみが特定のIAMロールを引き受けられるようにするために、最小特権の原則を採用し、可能な限りサービスアカウント用のIAMロール（IRSA）を使用します。IRSAは、リソースへのアクセスを制限し、不正アクセスのリスクを低減します。権限のないPodは、IMDSの設定に固執します。
- 読み取り専用アクセスの威力を過小評価しないでください。Lambda functionのような特定のAWSリソースの読み取り専用でさえ、データ漏洩や 資格情報の採取を意味します。必要なリソースだけに読み取り専用アクセスをスコープすることは、アカウントを安全に保つための基本です。
- クラウドアカウントの古くなったオブジェクトを監視する。未使用の権限は、たとえ古くて一度も使用されていないとしても、危険であり、侵害された場合に大きな損失を被る可能性があります。古くなったオブジェクトを意識し、定期的にクラウドオブジェクトを評価することは、必須であるべきです。
- Terraformは素晴らしいツールですが、取り扱いに注意が必要です。ベストプラクティスを採用し、ステートファイルを安全な場所に保存しましょう。AWS KMS、GCP KMS、Azure Key Vaultなどの鍵管理サービス（KMS）を使えば、シークレットを安全に保管し、必要なときに暗号化または復号化することが可能です。