本文の内容は、2024年12月12日に Alessandro Brucator が投稿したブログ(https://sysdig.com/blog/bedrock-slip-sysdig-trt-discovers-cloudtrail-logging-missteps/)を元に日本語に翻訳・再構成した内容となっております。
Amazon Bedrock APIの作業およびSysdig顧客向けの検知メカニズムの開発中に、Sysdig脅威リサーチチーム（TRT）は、これらのAPIの一部がCloudTrailに記録される方法において、異常な振る舞いを発見しました。具体的には、失敗したBedrock APIコールが成功したコールと同じ方法でログに記録され、特定のエラーコードが提供されていませんでした。このエラー情報の欠如は、CloudTrailログでの誤検知を引き起こし、検知作業を妨げる可能性があります。この詳細が欠けていると、セキュリティツールが通常のアクティビティを不審なものと誤解し、不必要なアラートや真の脅威の見落としにつながる可能性があります。この問題をSysdig TRTがAWSに報告した結果、迅速に解決されました。
開示タイムライン
以下は、問題が発見され報告されてから最終的な更新リリースまでの Sysdig TRT と AWS セキュリティチーム間のやり取りをまとめたものです。
- 7 月 16 日: Sysdig TRT で誤ったログが記録されます。
- 7 月 17 日: Sysdig TRT が AWS セキュリティ チームに通知します。
- 7 月 22 日: AWS が応答し、問題を確認し、Sysdig TRT に Amazon Bedrock CloudTrail ログへのコード変更をプッシュアウトする意向を通知しました。
- 8 月 9 日: AWS は Sysdig TRT に問題を解決したことを通知しました。
- 8 月 22 日: Sysdig TRT が応答し、修正を確認しました。チームはまた、CLI コマンドと Python SDK 間の Converse API のログ記録に矛盾がある可能性があることを AWS に通知しました。
- 8 月 23 日から 11 月 8 日: 最新の観察された動作のレビュー プロセス。
- 11 月 14 日: Sysdig TRT、AWS セキュリティ、Bedrock エンジニアリング チーム間の会議コール。後者は、観察されたログ記録の動作は実際には意図されたものだが、まだ文書化されていないと説明しました。
技術的な詳細
過去数か月間、Sysdig TRT は、攻撃者が不正アクセスを使用して Amazon Bedrock を悪用する方法を調査してきました。その間、チームは一部の Bedrock API が CloudTrail に記録される方法が変更されたことに気付きました。
ほとんどのBedrockランタイムAPIは、ValidationExceptionを含むいくつかのエラー（InvokeModel_Errors参照）をスローします。2024年7月8日まで、このエラーコードを伴うイベントは、errorCodeおよびerrorMessageフィールドが埋められた状態でCloudTrailに記録されていました。例えば、以下のような形式です：
"errorCode": "ValidationException",
"errorMessage": "Malformed input request, please reformat your input and try again."
このエラー メッセージは、攻撃者が特定の LLM にアクセスできるかどうかを判断するために使用する方法の 1 つであるため、偵察の試みを検知するのに役立ちます。この問題の影響は実際には偵察目的に限定されており、顧客データはどの時点でも公開されていません。
Sysdig TRT が、そのエラー コードを含む InvokeModel イベントについて保持している最後の CloudTrail ログは、2024 年 7 月 8 日のものでした。この日付以降、Sysdig TRT は API 応答で異なる振る舞いを経験し始めました。以前はエラーをスローしていた InvokeModel または Converse API の呼び出しに、ValidationExceptionエラー コードとメッセージ フィールドが含まれなくなりました。CloudTrail のログを見ると、API 呼び出しは実際には失敗していたのに、成功したように見えました。
たとえば、無効なmax_tokens_to_sampleパラメータを使用する InvokeModel API の場合:
aws bedrock-runtime invoke-model --model-id anthropic.claude-v2 --body '{"prompt": "\n\nHuman: tell me a random joke\n\nAssistant:", "max_tokens_to_sample" : -1}' --cli-binary-format raw-in-base64-out invoke-model-output.txt --region us-east-1
問題が発生する前と発生後の両方で、API は次のエラーを出力として報告します。
An error occurred (
ValidationException) when calling the InvokeModel operation:max_tokens_to_sample: range: 1..1,000,000
同様のエラーは、以下のようにネガティブのtop_kパラメータを使用したConverse APIでもスローされる可能性があります：
aws bedrock-runtime converse --model-id anthropic.claude-3-sonnet-20240229-v1:0 --messages '{"role": "user", "content": [{"text": "Create a list of 3 pop songs."}]}' --additional-model-request-fields '{"top_k": -1}'
An error occurred (
ValidationException) when calling the Converse operation:top_k: -1 is not greater or equal to 0, please reformat your input and try again.
この場合でも、API がこのように応答したにもかかわらず、CloudTrail ログにはエラーの兆候は含まれませんでした。
Converse API ボーナス ハック
Converse APIは推論パラメータを単一の形式にラップし、異なるBedrockモデルの呼び出し管理を簡素化します。このAPIでは、以下の例に示すように、inferenceConfigおよびadditionalModelRequestFieldsを介して推論パラメータを渡すことがサポートされています。デフォルトでは、無効な推論パラメータを含むConverseリクエストは、parameter_validation設定がデフォルト値としてTrueに設定されているため、CloudTrailには記録されません。これは、パラメータがクライアント側で検証されるためです。
Sysdig TRTは、additionalModelRequestFields内に無効なパラメータを渡すと、CloudTrailにイベントが記録されることを観測しました。Bedrockのエンジニアによると、additionalModelRequestFields内で渡されたパラメータは常にサーバー側でチェックされます。これは、これらのパラメータがモデルプロバイダーのチェックを通過するためです。一方、inferenceConfig内で渡されたパラメータはサーバーに到達する必要がなく、クライアント側で検証が行われます。そのため、この検証が失敗した場合、リクエストはCloudTrailに記録されません。
なお、これはセキュリティ上の問題を意味するものではありません。クライアント側の検証は認証チェックの前に行われるためです。このため、攻撃者がConverse APIの呼び出しを試みて、ログ記録を回避しつつ侵害されたAWSキーの権限を確認することはできません。クライアント側エラーは、Converse APIを呼び出す権限に関係なくスローされるためです。
インパクト
このロギング問題の主な影響は、CloudTrail内で成功したAPIコールと失敗したAPIコールを区別できない点にありました。CloudTrailは、何が起こったのかを理解するためのトラブルシューティングやセキュリティ調査に不可欠です。APIレスポンスで明確な区別ができない場合、問題の診断が迅速に行えず、困難で問題を引き起こします。
検出を改善するために、アラート数を減らし重要な問題に優先順位をつける手法として、エラーを返すAPIを除外することがよくあります。このアプローチは、すべてのAPI失敗に対する不必要なアラートを回避することを目的としていますが、多数の誤検知を引き起こす可能性があります。つまり、APIレスポンスにエラーコードが含まれていない場合、それらの呼び出しの真の性質が曖昧になる可能性があります。
Sysdig TRTは、複数の攻撃者がBedrockランタイムAPIを呼び出し、これらのクライアントエラーを発生させることで、LLM（大規模言語モデル）へのアクセスやモデルの可用性をテストしていることを観測しました。この手法は、即座に警報を引き起こすことなく偵察を行うことを可能にし、その結果、攻撃者のクエリと正当なLLMクエリを区別することが難しくなります。