Amazon Web Services ブログ
Amazon GuardDuty で EC2 インスタンス認証情報漏洩の検出を強化
Amazon GuardDuty は、悪意のあるアクティビティや不正な動作を継続的にモニタリングし、Amazon Simple Storage Service (Amazon S3) に保存されている AWS アカウント、ワークロード、データを保護する脅威検出サービスです。GuardDuty は、機械学習を活用した多数のパブリックデータフィードや AWS 生成データフィードから情報を得て、何かがおかしいという認識可能な兆候である傾向、パターン、異常を追跡し、何十億ものイベントを分析します。ワンクリックで有効にすると、数分で最初の結果を確認できます。
2022 年 1 月 21 日（米国時間）、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの認証情報が別の AWS アカウントから使用されていることを検出する機能を GuardDuty に追加しました。EC2 インスタンス認証情報は一時的な認証情報で、AWS Identity and Access Management (IAM) ロールがインスタンスに添付されたときに、EC2 メタデータサービスを通じてインスタンスで実行されているすべてのアプリケーションに対して提供されます。
リスクは何ですか。
EC2 インスタンスにデプロイされたワークロードが AWS のサービスにアクセスする場合、アクセスキー、シークレットアクセスキー、セッショントークンが使用されます。アクセスキー認証情報をワークロードに渡す安全なメカニズムは、ワークロードに必要なアクセス許可を定義し、そのアクセス許可を持つ 1 つまたは複数の IAM ポリシーを作成し、そのポリシーを IAM ロールに添付し、最後にロールをインスタンスに添付します。
ロールが添付された EC2 インスタンスで実行されているプロセスは、EC2 メタデータサービスを呼び出すことでセキュリティ認証情報を取得できます。
curl 169.254.169.254/latest/meta-data/iam/security-credentials/role_name
{
"Code" : "Success",
"LastUpdated" : "2021-09-05T18:24:45Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "AS...J5",
"SecretAccessKey" : "r1...9m",
"Token" : "IQ...z5Q==",
"Expiration" : "2021-09-06T00:44:06Z"
}これらの認証情報は、時間と範囲が限られています。有効期間は最長 6 時間です。EC2 インスタンスに関連付けられた IAM ロールに添付されたアクセス許可の範囲に制限されます。
すべての AWS SDK は、このような認証情報を自動的に取得して更新できます。アプリケーションに追加のコードは必要ありません。
ここで、EC2 インスタンスで実行されているアプリケーションが侵害され、悪意のあるアクターがインスタンスのメタデータサービスにアクセスできたとします。悪意のあるアクターは認証情報を抽出します。これらの認証情報には、インスタンスに添付された IAM ロールで定義したアクセス許可が付与されます。アプリケーションによっては、攻撃者が S3 または DynamoDB からデータを盗み出したり、EC2 インスタンスをスタートまたは終了したり、新しい IAM ユーザーやロールを作成する可能性があります。
GuardDuty の発売以来、そのような認証情報が AWS 外の IP アドレスから使用されていることが検出されました。そのため、賢い攻撃者は、アクティビティを別の AWS アカウントから隠し、GuardDuty には見えないところで操作する可能性があります。本日より、GuardDuty は認証情報が AWS ネットワーク内の他の AWS アカウントから使用されたときも検出します。
どのようなアラートが生成されますか。
AWS のサービス API と通信するソース IP アドレスが EC2 インスタンスの IP アドレスと異なる可能性があるのには、理に適った理由があります。AWS Transit Gateway や AWS Direct Connect など、1 つまたは複数の VPC にトラフィックを送信する複雑なネットワークトポロジーについて考えてみてください。さらに、マルチリージョン設定や AWS Organizations を使用しないとき、認証情報を使用する AWS アカウントが自分のものであるかどうかを検出することは重要なことです。大企業は、このようなセキュリティ侵害を検出するために独自のソリューションを導入していますが、この種のソリューションを構築し保守することは容易ではありません。この課題に取り組むために必要なリソースを持っている組織は、ほんの一握りです。組織がそこに力を注いでいたら、エンジニアリングへの取り組みがコアビジネスから逸脱してしまいます。そのため、私たちがこれに取り組むことにしました。
本日より、GuardDuty は EC2 インスタンスの認証情報の誤用を検出するとアラートを生成します。関連アカウントの認証情報が使用される場合、アラートには重要度が「中」というラベルが付けられます。それ以外の場合は、重要度の高いアラートが生成されます。関連アカウントとは、同じ GuardDuty 管理者アカウントによってモニタリングされるアカウントで、GuardDuty メンバーアカウントとも呼ばれています。これらのアカウントは、組織の一部かもしれないし、そうでないかもしれません。
実際に
その仕組みを知るために、EC2 インスタンスの 1 つから一連の EC2 認証情報をキャプチャして、取得してみましょう。前述のように、SSH を使用してインスタンスの 1 つに接続し、curl を使用して認証情報を取得します。
curl 169.254.169.254/latest/meta-data/iam/security-credentials/role_name
{
"Code" : "Success",
"LastUpdated" : "2021-09-05T18:24:45Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "AS...J5",
"SecretAccessKey" : "r1...9m",
"Token" : "IQ...z5Q==",
"Expiration" : "2021-09-06T00:44:06Z"
}インスタンスには、この AWS アカウントの S3 バケットの読み取りを許可された IAM ロールがあります。認証情報をコピーして貼り付けます。次に、同じ GuardDuty 管理者アカウントに関連付けられていない、別の AWS アカウントで実行されている別の EC2 インスタンスに接続します。SSH を使用して他のインスタンスに接続し、漏洩させた認証情報を使用して AWS CLI を設定します。プライベート S3 バケットへのアクセスを試みます。
# まず、アクセス権限がないことを確認する
[ec2-user@ip-1-1-0-79 ~]$ aws s3 ls s3://my-private-bucket
ListObjectsV2 オペレーションの呼び出し中にエラーが発生しました (AccessDenied): アクセスが拒否されました
# 次に、漏洩させた認証情報を使用して CLI を設定します
[ec2-user@ip-1-1-0-79 ~]$ aws configure
AWS アクセスキー ID [None]: AS... J5
AWS シークレットアクセスキー [None]: r1... 9m
デフォルトのリージョン名 [None]: us-east-1
デフォルトの出力形式 [None]:
[ec2-user@ip-1-1-0-79 ~]$ aws configure set aws_session_token IQ...z5Q==
# 最後に、もう一度 S3 にアクセスしてみます
[ec2-user@ip-1-1-0-79 ~]$ aws s3 ls s3://my-private-bucket
PRE folder1/
PRE folder2/
PRE folder3/
2021-01-22 16:37:48 6148 .DS_Store
その直後に、AWS マネジメントコンソールを使用して、認証情報を盗んだ AWS アカウントの GuardDuty にアクセスします。重要度の高いアラートが生成されたことを確認できます。
それでどうするのか。
攻撃者が、リモートコード実行 (RCE) を持っている、またはインスタンスに現地拠点を所有している場合、もしくは Server Side Request Forgery (SSRF) や XML External Entity (XXE) インジェクションなどのアプリケーションレベルの脆弱性を悪用すれば、認証情報を抽出する可能性があります。RCE またはローカルアクセスを緩和するには、セキュリティで保護され、パッチが適用された AMI からインスタンスを再構築して、リモートアクセスを排除したり、アクセス認証情報をローテーションしたりするなど、複数の方法があります。脆弱性がアプリケーションレベルの場合、ユーザーまたはアプリケーションベンダーは、脆弱性を排除するためにアプリケーションコードにパッチを適用する必要があります。
認証情報が漏洩するリスクがあることを示すアラートを受け取ったら、まずアカウント ID を確認します。それはあなたの会社のアカウントですか。 分析中にビジネスケースが許せば、漏洩したインスタンスを終了したり、アプリケーションをシャットダウンしたりすることができます。これにより、攻撃者は有効期限切れの時に更新されたインスタンス認証情報を抽出することができなくなります。疑わしい場合は、Amazon AWS 不正使用の報告フォームを使用するか、abuse@amazonaws.com に連絡して AWS 信頼 & 安全チームに連絡してください。リクエストをする時は、疑わしい AWS アカウント ID、プレーンテキストのログイン情報など、必要な情報をすべて送信します。
ご利用状況
この新しい機能は、すべての AWS リージョンで、追加コストがかからずに利用できます。AWS アカウントで GuardDuty が既に有効になっている場合、デフォルトで有効となっています。
それ以外の場合は、GuardDuty を今すぐ有効にして、30 日間の試用期間をスタートしてください。
原文はこちらです。