古いサービス、新しい手法：UNC2903によるクラウドメタデータサービスの悪用

※この投稿は米国時間 2022 年 1 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

2021年7月以降、Mandiantは、UNC2903がAmazonのInstance Metadata Service（IMDS）を使用して認証情報を採取する公開用Webアプリケーションの悪用を確認しています。Mandiantは、UNC2903が盗んだ認証情報を使ってS3バケットやクラウドリソースにアクセスする試みを追跡しています。この記事では、UNC2903がどのようにIMDSの不正使用を行ったか、また、クラウドのハードニングに関するベストプラクティスについて説明します。

UNC2903はAmazon Web Services（AWS）環境を標的としていましたが、他の多くのクラウドプラットフォームも同様のメタデータサービスを提供しており、同様の危険にさらされる可能性があります。企業がクラウドへの移行を進める中で、攻撃グループの動機と行動が目立ってきています。この記事では、クラウドサービスを利用するセキュリティチームやITチームが考慮するべき、潜在的リスクと注意点についても説明します。

タイムライン

Mandiant のインシデントレスポンス、インテリジェンス、およびトランスフォーメーショナルサービスの各チームは、侵入を適切に検知、防止、対応するために情報を収集しました。以下のタイムラインは、UNC2903の最も早い時期に観測されたキャンペーンについてです。

• 2021年2月、Adminerというデータベース管理ソフトの脆弱性 CVE-2021-21311が公開されました
• 2021年2月、AWS上で稼働するこのアプリケーションの脆弱なバージョンを対象に、認証情報を取得する方法を示す概念実証コード（PoC）が公開されました
• 2021年6月、UNC2903はサーバーサイドリクエストフォージェリの脆弱性を悪用し、被害者のAmazon Web Servicesのシークレットアクセスキーを入手し、その後、データを盗み出しました

このブログでは、現在パッチが提供されているAdminerソフトウェアについて説明していますが、リクエストフォージェリやリモートコード実行の脆弱性があるWebアプリケーションは、同様のメタデータサービス攻撃を受ける可能性があります。

実際の利用と悪用された証拠

クラウドメタデータをめぐる脅威の状況

Mandiantのアナリストは、AWSや同様のクラウドプラットフォームでホストされているサービスの悪用が、最近増加していることを確認しました。UNC2903が行ったキャンペーンで確認された脅威は、インフラスキャン、偵察、そしてクラウドプラットフォームが提供する基礎的な抽象化レイヤーの悪用を含む、多段階の攻撃でした。このような悪用によって盗まれた認証情報は、侵害したテナント内の他のAWSサービスのデータを取得するために利用されます。

Mandiantのインシデント・レスポンス・チームは、UNC2903がデータを盗むまでの手順について、次のように特定しました。

1. Adminerソフトウェアをホストする外部向けAWS Webインフラを探すネットワークスキャンの試行
2. インフラを特定した後、追加のWebナビゲーションと偵察の実行
3. ホストされているWebサーバーに存在する可能性のある複数のWebアプリケーションを悪用する試み
4. 特定されたエクスプロイトを使用した、手動によるエクスプロイトとテストを行う更なる試み

IMDSは、Amazon Web Servicesのクラウド上でホストされているため、UNC2903のような攻撃グループにとって魅力的なターゲットとなります。IMDSv1は、リンク先のローカルIPアドレス（169.254.169.254）に対して、専用のURLへのWebリクエストを許可しており、ホスティングプラットフォーム全体における内部サービスのコミュニケーションとトラブルシューティングを支援するために設計されています。取得可能なメタデータには、構成、トポロジー、さらにはユーザーのロールやクレデンシャルを把握するための情報が含まれています。

Amazonは、GuardDutyのようなAWSのセキュリティサービスとともに、保護とアラートのレイヤーを追加するためにIMDSv2をリリースしました。IMDSv2がこのタイプの攻撃を緩和するために、 http://169.254.169[.]254/latest/api/token からPUT経由でトークンを取得し、そのトークンを使用して特別なヘッダー（x-aws-ec2-metadata-token）を介してIMDSへのリクエストするように変更しました。

AmazonはGuardDutyの機能拡張を伴いIMDSv2の利用を推奨しています。IMDSv2を使用していないEC2インスタンスは、パッチが未適用などで脆弱なサードパーティソフトウェアがある場合、危険にさらされる可能性があります。クラウド利用が拡大するにつれて、脆弱なWebインフラストラクチャの脅威の表面やターゲットも拡大し、セキュリティ機能が制限された時代遅れのサービスや非推奨のメタデータサービスが基礎となっています。Web アプリケーションの脆弱性に関連するリスクレベルを評価し、クラウド環境の基盤となるメタデータサービスが高度な脅威や継続的な脅威を高める可能性があることを理解した上で、組み合わせることが必要です。

巧みなテクニック、SSRF、容易なアクセス

Mandiantは、UNC2903がキャンペーンにおいて専用の運用型リレーボックス(ORB)を利用して、Webスキャンを行い、IMDSv1を悪用していることを確認しています。この攻撃グループは一連のWebスキャンを行い、特定されたアプリケーションを手動で偵察するのと同じ活動を実施します。この攻撃は、サーバーサイドリクエストフォージェリ（SSRF）の脆弱性を利用し、AWS S3バケットへのアクセスに使用する一時アクセスキーを得るものでした。

観測されたUNC2903の攻撃の流れを図１に示します。

観測されたキャンペーンでは、UNC2903はCVE-2021-21311を利用して、次のような攻撃を行っていました。

• 攻撃グループは、運用型リレーボックス(ORB) でWebサーバーをホストし、http://169.254.169[.]254/latest/meta-data/iam/security-credentials/に301リダイレクトするように設定されたスクリプトを使用します。

• 次に、攻撃グループは、バージョン 4.0.0 から 4.7.9 までの Adminer の管理画面に移動し、SSRF 脆弱性を実行しようとします。

• 悪意のあるリダイレクトスクリプトをホストする運用型リレーボックス(ORB)のIPアドレスとポートを被害者のAdminerのダイアログボックスに入力し、ログインボタンを押します。

• Adminerが稼働する被害サーバーを騙して運用型リレーボックスにWebリクエストを行い、被害サーバーはSSRFを完成させる301リダイレクトのリクエストを実行します。

• 攻撃対象のサーバーはエラーを返しますが、IMDSサービスからの結果を返すため、メタデータの認証情報はエラーメッセージとして表示されます。

これらの手順は、攻撃で使われるコマンドを正確に反映しているわけではありませんが、UNC2903が使用した方法を強調していることに注意してください。この攻撃には、CVE-2021-21311 の悪用と SSRF の悪用が含まれるため、クラウドベースのシステムおよびテナントのデフォルト構成に基づき、限られたアーティファクトを利用できます。

成果物と注目すべき観察事項

Mandiantのインシデントレスポンスは、UNC2903によって実行された関連する悪用および IMDS 悪用の成果物を特定し、収集しました。最初のスキャンと悪用から記録された活動、および AWS メタデータサービスとクレデンシャルの悪用は、ホストされたインフラの設定とテナントで利用できるクラウドログも対象となる可能性があります。セキュリティ運用者がイベントログに鋭い目を向けなければ、たとえログのレベルを上げたとしても、UNC2903や他の脅威グループが行った同様の攻撃は検出されない可能性があります。

この攻撃は、Adminer のPHP アプリケーションページを悪用するため、悪意のあるナビゲーションやインタラクションは、調査者が見落としてしまう可能性があります。確認された活動は、画面または記録されたイベントログに標準的な成功したWebレスポンスを返すいくつかの悪用と比較して、特徴的にユニークです。

悪用を示す限られた情報源は以下の通りです。

• Web アクセスログと エラーログ
• GuardDuty イベント
• VPC Flow Logs
• S3 Data and Access Events

図 7 は、Adminer Web ページに対して確認された初期アクセスおよび Web アプリケーションのスキャン動作の例です。攻撃は成功したものの、ログにはWebレスポンスとして302リダイレクトなどの403エラーが表示されています。

図 8 は、SSRF 実行時の Webサーバーの VPC Flowの例です。アウトバウンドリクエストを行った攻撃対象のサーバーは、外部IPアドレスが疑わしいことに注意してください。しかし、このポートは、攻撃用に選択された任意の、またはより個別なポートに構成される可能性があります。

図9は、認証情報が盗まれ悪用された時のGuardDutyのイベントの例です。これは一例ですが、S3バケットからデータが漏えいした際に GuardDutyがアラートをあげています。

ミッションの完了と今後の課題

UNC2903や類似の攻撃グループが行った攻撃の最終段階では、データの流出やAWSテナントとの相互作用が含まれています。アプリケーションやメタデータサービスの悪用によって盗み出された情報は、攻撃グループが組織のクラウド環境からデータを操作したり盗み出したりすることができる可能性があります。同様のクラウド向けメタデータサービスの悪用は、脅威グループが、本来のアプリケーションのターゲット以外の環境を悪用する方法を示しています。クラウドサービスやソリューションを構築する際には、予防と対応のための構成を技術チームが評価・検討する必要があります。ここからは、不正なメタデータサービスの利用を緩和、制限、検出するための戦略について説明します。

Mandiantインテリジェンスの調査結果

アトリビューション

UNC2903は、2021年7月からMandiantが追跡している動機が不明なグループです。UNC2903は日和見主義で、インターネット上の脆弱なシステムを対象にし、少なくとも1人の被害者からデータを盗んだことが観察されていますが、Mandiantは、恐喝や販売など、盗んだデータの現金化を観察していません。ログの分析により、攻撃グループは特にadminer.phpをスキャンし、GitHubから直接WSO webshellをインストールするApache Root Privilege EscalationであるCVE-2019-0211のテストを行っていたことがわかりました。

CVE-2021-21311の脆弱性を持つadminer.phpが自動スキャンによって攻撃グループに発見された18分後、MandiantはTelegram botによるadminer.phpのインデックス作成を観測し、adminer.phpへのリンクがTelegramチャットグループで共有されたことを示しています。その数分後、無料VPNサービスからの自動セッションでもadminer.phpがスキャンされました。数時間後、別のIPから同じ自動化プロセスが実行され、最初のアクセスから3時間15分後にインタラクティブな活動が行われ、IMDSサービスにアクセスすることに成功しました。

偵察活動

Mandiantは、2021年6月下旬にUNC2903のインフラが2,100以上のIPアドレスに対してスキャンを行ったことを示す観測結果を得ました。スキャンはポート80や443などのWebサービスに焦点を当て、特定のサービスプロバイダーには焦点を当てなかったことから、攻撃グループは事前の調査でHTTPポートが開いているターゲットのリストを操作し、特定のサービスプロバイダーをターゲットにしていない可能性が示唆されます。

ユーザーエージェント文字列

Mandiantが観測したUNC2903が使用したユーザーエージェント文字列は下記の通りです。

• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.101 Safari/537.36 Edg/91.0.864.48
• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.106 Safari/537.36
• Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0

セキュリティを向上し、同様の脅威を緩和する

Mandiantは、IMDSv1が有効になっているEC2インスタンスを検出し、修復し、防止することを推奨しています。IMDSv2を使用するようにEC2インスタンスを修復および変換する前に、組織はすべてのインスタンス/アプリケーションをテストして、そのような修復手段によって運用が影響を受けないことを確認する必要があります。

脆弱性のあるAdminer Webアプリケーションを実行しているEC2インスタンスでIMDSv2を有効にすると、攻撃グループはシークレット/クレデンシャルを取得できなくなります（図10）。

次に、企業が自社の環境からIMDSv1を検出し、修復し、防止するための方法について説明します。

検出、修復、予防

MDSv1を利用するEC2インスタンスの検出

現在デプロイされているEC2インスタンスを監査し、IMDSv1またはIMDSv2が使用されているかどうかを確認する。

• AWSのネイティブサービス
  • AWS Security Hub – [EC2.8] EC2 instances should use IMDS v2 による確認
  • CloudWatch – MetadataNoToken (インスタンスメタデータサービスがトークンなしで正常にアクセスできた回数(IMDSv1など)をカウント)
  • AWS Config –組織の EC2 インスタンスが HTTP Tokens を必要とするように設定されているかどうかを確認する Config Rule (以下を参照)

AWSTemplateFormatVersion: "2010-09-09"
Description: ""
Resources:
  ConfigRule:
    Type: "AWS::Config::ConfigRule"
    Properties:
      ConfigRuleName: "ec2-imdsv2-check"
      Scope:
        ComplianceResourceTypes:
          - "AWS::EC2::Instance"
      Description: "A Config rule that checks whether your Amazon Elastic Compute Cloud (Amazon EC2) instance metadata version is configured with Instance Metadata Service Version 2 (IMDSv2). The rule is COMPLIANT if the HttpTokens is set to required and is NON_COMPLIANT ..."
      Source:
        Owner: "AWS"
        SourceIdentifier: "EC2_IMDSV2_CHECK"
Parameters: {}
Metadata: {}
Conditions: {}

• オープンソースのツール
  • Prowler - Check 7.86 – EC2 Instance Metadata Service Version 2 (IMDSv2) が有効かつ必須であるかどうかを確認する
    

    ./prowler -c check786

  • Metabadger
    

    ./metabadger discover-metadata
    

  • CloudMapper – EC2_IMDSV2_NOT_ENFORCED

• AWS CLI:

aws ec2 describe-instances --filters Name=metadata-options.http-tokens,Values=optional --
query "Reservations[*].Instances[*].{Instance:InstanceId}"  --region [EnterRegionHere]

aws ec2 modify-instance-metadata-options –instance-id <instance-id> –http-endpoint disabled

aws ec2 modify-instance-metadata-options –instance-id <INSTANCE-ID> –http-endpoint enabled –http-token required

python remediate-imdsv1.py --profile <AWS_PROFILE> --remediate –debug

IMDSv1の利用を制限する

• 組織はサービスコントロールポリシー（SCP）を作成し、EC2のロールクレデンシャルがある場合、IMDSv2の利用をAPIコールに要求することができます。下記はSCPの例です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RequireAllEc2RolesToUseV2",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "NumericLessThan": {
                    "ec2:RoleDelivery": "2.0"
                }
            }
        }
    ]
}

• 組織はInfrastructure-as-Code（IaC）を利用してIMDSv1の使用を許可、制限することが可能です。 IMDSv2を強制する方法はいくつかありますが、ここではCloudFormationを利用する方法をいくつか紹介します。
• EC2 AutoScaling Launch Configuration:

{
  "HttpTokens" : required
}

•        EC2 Launch Template:

{
  "HttpTokens" : required
}

• IMDSv2が設定されていないEC2インスタンスをユーザーが起動できないようにする、CloudFormationまたはTerraformのカスタムテンプレートを作成する
  • CloudFormation

AWSTemplateFormatVersion: "2010-09-09"
Description: ""
Resources:
  IamPolicy:
    Type: "AWS::IAM::ManagedPolicy"
    Properties:
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Action:
              - "ec2:RunInstances"
            Resource:
              - "arn:aws:ec2:*:*:instance/*"
            Effect: "Deny"
            Condition:
              StringNotEquals:
                ec2:MetadataHttpTokens: "required"
      Description: "An IAM policy that prevents users from launching new EC2 Instances if they are not configured to use the new Instance Metadata Service (IMDSv2)"
Parameters: {}
Metadata: {}
Conditions: {}

Terraform

provider "aws" {
}
resource "aws_iam_policy" "IamPolicy" {
  name = "Require_IMDSv2"
  description = "IAM Policy that requires IMDSv2"
  policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:RunInstances"
      ],
      "Resource": [
        "arn:aws:ec2:*:*:instance/*"
      ],
      "Effect": "Deny",
      "Condition": {
        "StringNotEquals": {
          "ec2:MetadataHttpTokens": "required"
        }
      }
    }
  ]
}
POLICY
}

IMDSv2が設定されていないEC2インスタンスをユーザーが起動できないようにするIAMポリシーを作成する

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:RunInstances"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:instance/*"
            ],
            "Effect": "Deny",
            "Condition": {
                "StringNotEquals": {
                    "ec2:MetadataHttpTokens": "required"
                }
            }
        }
    ]
}

• 新規に作成したEC2インスタンスがIMDSv2を使用するように設定するIAMポリシーを作成する　（注：既存のEC2インスタンスはこのIAMポリシーの影響を受けません）

{
    "Version": "2012-10-17",
    "Statement": {
        "Sid": "RequireImdsV2",
        "Effect": "Deny",
        "Action": "ec2:RunInstances",
        "Resource": "arn:aws:ec2:*:*:instance/*",
        "Condition": {
            "StringNotEquals": {
                "ec2:MetadataHttpTokens": "required"
            }
        }
    }
}

追加対策としてのハードニング

• すべてのEC2インスタンスをレビューし、EC2用のユーザーデータスクリプトに平文の認証情報や機密情報が含まれていないことを確認する
  • ユーザーデータスクリプトは、EC2の起動時に提供するコマンド群です。ユーザーデータスクリプトはルート権限で実行され、IMDS経由で閲覧することができ、攻撃者は単純なcurlコマンドで実行中のスクリプトを読むことができます。
    

    {
        "Version": "2012-10-17",
        "Statement": {
            "Sid": "MaxImdsHopLimit",
            "Effect": "Deny",
            "Action": "ec2:RunInstances",
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "NumericLessThanEquals":
               {"ec2:MetadataHttpPutResponseHopLimit": "1"}
            }
        }
    }

• IMDSv2を使用してIAMポリシー経由でAmazon EC2ロールの資格情報を配信するAPIコールを制限する

{
    "Version": "2012-10-17",
    "Statement": {
        "Sid": "RequireAllEc2RolesToUseV2",
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*",
        "Condition": {
            "NumericLessThan":
            {"ec2:RoleDelivery": "2.0"}
        }
    }
}

• EC2インスタンスのメタデータを変更できるアクセスを制限する

{
    "Version": "2012-10-17",
    "Statement": {
        "Sid": "LimitModifyInstanceMetadataService",
        "Effect": "Deny",
        "Action": "ec2:ModifyInstanceMetadataOptions",
        "Resource": "*",
        "Condition": {
            "StringNotLike":
            {"aws:PrincipalARN”: “arn:aws:iam:*:role/ec2-imds-admin"}
        }
    }
}

• S3バケットへのIAMロール/クレデンシャルのアクセス範囲を制限する
• インターネットからのIAMロール/クレデンシャルの利用をブロックまたは制限する
• サーバーのインターネット通信を制限して、サーバーのアウトバウンドトラフィックを防止する
• S3バケットへのアクセスをさらに制限するために、S3バケットポリシーを実装する
• VPC FlowとS3バケット/オブジェクトレベルのアクセスデータイベントを有効化する
• 悪用される可能性のあるWebリクエストをプロキシまたは監視する
• サーバーへのインバウンドまたはアウトバウンドを許可するサービスポートを制限する
• Web サーバーへの不要なHTTPヘッダーを無害化、または制限する
• すべてのログを記録し、クレデンシャル不正利用の可能性がある場合は優先的に警告を出す
• Amazon Web Services のソリューションに関するベストプラクティスに従い、セキュリティ統制を定期的にテストする

まとめ

クラウド環境への移行が進むにつれ、デフォルト設定がさらに複雑になり、攻撃者があるシステムへのアクセスを利用して、他の多くのシステムへ侵入する機会が生まれる可能性があります。クラウドシステムに保存されたデータは、他の環境と同様に、盗まれたり、改ざんされたり、削除されたりする可能性があります。Mandiant の侵入対応に関する専門知識は、諜報活動や金銭的な動機のあるグループの両方から狙われ続けているクラウド環境にも及んでいます。

謝 辞

技術的なレビューをいただいたNick Richard氏、MITRE D3FENDマッピングをいただいたJustin Moore氏に感謝します。

セキュリティ指標

• 141.94.43.37
• 37.59.152.171
• 191.96.108.227
• 191.96.108.8
• hxxps://raw.githubusercontent[.]com/wso3/wso3/master/wso.php
• 35b03c6bc21d140201670005923333de

MITRE D3FEND UNC2903

-Mandiant, 作成者: Brandan Schondorfer, Nader Zaveri, Tyler McLellan, Jennifer Brito