本文の内容は、2024年5月6日に ALESSANDRO BRUCATO が投稿したブログ（https://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/)を元に日本語に翻訳・再構成した内容となっております。
Sysdig 脅威リサーチチーム (TRT) は、最近クラウドでホストされている 10 個の大規模言語モデル (LLM) サービスを標的とするために、盗まれたクラウド認証情報を悪用した、LLM ジャッキングとして知られる新たな攻撃を観察しました。認証情報は、一般的なターゲットである、脆弱なバージョンの Laravel ( CVE-2021-3129 )を実行しているシステムから取得されました。 LLM ベースの人工知能 (AI) システムに対する攻撃は頻繁に議論されていますが、そのほとんどは即時の悪用とトレーニング データの改ざんに関するものです。この場合、攻撃者は、クラウド アカウント所有者が料金を支払う間に、LLM アクセスを他のサイバー犯罪者に販売することを目的としています。
初期アクセスを取得すると、クラウド認証情報を抽出してクラウド環境へのアクセスを取得し、クラウドプロバイダーがホストするローカル LLM モデルにアクセスしようとしました。この例では、Anthropic のローカル Claude (v2/v3) LLM モデルが標的になりました。この種の攻撃が発見されない場合、被害者は 1 日あたり 46,000 ドル以上の LLM 消費コストを支払うことになる可能性があります。
Sysdig のリサーチャーは、侵害されたアカウントへのアクセスを提供するために LLM のリバースプロキシが使用されている証拠を発見し、金銭的動機が示唆されました。ただし、別の動機として考えられるのは、LLM トレーニングデータを抽出することです。
広範なターゲット
私たちは、攻撃中にモデルを呼び出すために使用されたリクエストを生成するツールを発見することができました。その結果、10種類のAIサービスの認証情報をチェックし、どれが目的に役立つかを判断するための、より広範なスクリプトが明らかになりました。これらのサービスには以下が含まれます：
- AI21 Labs、Anthropic、AWS Bedrock、Azure、イレブンラボ、MakerSuite、Mistral、OpenAI、OpenRouter、GCP Vertex AI
攻撃者は、さまざまなサービスにわたって大量の LLM モデルにアクセスしようとしています。検証段階では、正当な LLM クエリは実際には実行されませんでした。代わりに、認証情報の機能と割り当てを把握するのに十分な作業が行われました。さらに、可能な場合はログ設定も照会されます。これは、侵害された認証情報を使用してプロンプトを実行する場合の検出を回避するために行われます。
背景
ホストされた LLM モデル
Azure Machine Learning、GCP の Vertex AI、AWS Bedrock を含むすべての主要なクラウド プロバイダーは現在、大規模言語モデル (LLM) サービスをホストしています。これらのプラットフォームを使用すると、開発者は LLM ベースの AI で使用されるさまざまな人気モデルに簡単にアクセスできます。以下のスクリーンショットに示されているように、ユーザー インターフェイスはシンプルになるように設計されており、開発者はアプリケーションの構築をすぐに開始できます。
しかし、これらのモデルはデフォルトでは有効になっていません。その代わり、実行するにはクラウドベンダーにリクエストを提出する必要があります。モデルによっては自動的に承認されるものもありますが、サードパーティーモデルのように小さなフォームに記入しなければならないものもあります。一度リクエストがなされれば、クラウドベンダーは通常すぐにアクセスを可能にします。リクエストを行うという要件は、多くの場合、ブロッカーというよりむしろ攻撃者にとってのスピードバンプであり、セキュリティメカニズムと考えるべきではありません。
クラウドベンダーは、簡単な CLI コマンドを使用して、ホストされたクラウドベースの言語モデルと対話するプロセスを簡素化しました。必要な構成と権限を設定したら、次のようなコマンドを使用してモデルを簡単に操作できます。
aws bedrock-runtime invoke-model –model-id anthropic.claude-v2 –body ‘{“prompt”: “\n\nHuman: story of two dogs\n\nAssistant:”, “max_tokens_to_sample” : 300}’ –cli-binary-format raw-in-base64-out invoke-model-output.txt
LLM リバースプロキシ
資格情報が対象の LLM を使用できるかどうかを検証するキー チェックコードも、別のプロジェクトであるOAI Reverse Proxyを参照します。このオープンソース プロジェクトは、LLM サービスのリバースプロキシとして機能します。このようなソフトウェアを使用すると、攻撃者は、基礎となる認証情報 (この場合は侵害された認証情報の基礎となるプール) を公開せずに、複数の LLM アカウントへのアクセスを集中管理することができます。侵害されたクラウド認証情報を使用した攻撃中に、OAI リバース プロキシと一致するユーザー エージェントが LLM モデルを使用しようとしていることが確認されました。
上の画像は、インターネット上で実行されている OAI リバースプロキシの例です。このインスタンスがこの攻撃に何らかの形で結び付けられているという証拠はありませんが、このインスタンスが収集および表示する情報の種類は示されています。特に注目すべきは、ログに記録される可能性があるトークン数 (“tookens”)、コスト、およびキーです。
この例は、複数のタイプの LLM を使用するように設定された OAI リバースプロキシ インスタンスを示しています。このインスタンスが攻撃に関与しているという証拠はありません。
攻撃者が有用な認証情報のインベントリを収集し、利用可能な LLM モデルへのアクセスを販売したい場合、このようなリバース プロキシを使用すると、攻撃者がその取り組みを収益化できる可能性があります。
テクニカル分析
この技術的な詳細では、攻撃者がどのようにクラウド環境をナビゲートして侵入を実行したかを調査します。クラウド環境内で一見正当な API リクエストを使用することで、即座にアラームをトリガーすることなく、アクセスの境界を巧みにテストしました。以下の例は、CloudTrail によって記録された InvokeModel API 呼び出しの戦略的な使用法を示しています。攻撃者は有効なリクエストを発行しましたが、max_tokens_to_sample パラメーターを意図的に -1 に設定しました。この珍しいパラメータは、通常はエラーを引き起こすと予想されますが、代わりに 2 つの目的を果たしました。これにより、LLM へのアクセスが存在することだけでなく、結果として生じる ValidationException によって示されるように、これらのサービスがアクティブであることも確認されました。 AccessDenied エラーなどの別の結果では、アクセスが制限されていることが示唆されます。この微妙な調査により、盗まれた認証情報によってクラウド アカウント内でどのような操作が許可されているかを明らかにするための、計算されたアプローチが明らかになります。
モデルの呼び出し
InvokeModel の呼び出しは CloudTrail によって記録され、悪意のあるイベントの例を以下に示します。彼らは正当なリクエストを送信しましたが、“max_tokens_to_sample” を -1 に指定しました。これは “ValidationException”エラーを引き起こす無効なエラーですが、認証情報が LLM にアクセスでき、LLM が有効になっていることがわかるため、攻撃者にとっては有益な情報です。そうしないと、“AccessDenied” エラーが発生することになります。
{
"eventVersion": "1.09",
"userIdentity": {
"type": "IAMUser",
"principalId": "[REDACTED]",
"arn": "[REDACTED]",
"accountId": "[REDACTED]",
"accessKeyId": "[REDACTED]",
"userName": "[REDACTED]"
},
"eventTime": "[REDACTED]",
"eventSource": "bedrock.amazonaws.com",
"eventName": "InvokeModel",
"awsRegion": "us-east-1",
"sourceIPAddress": "83.7.139.184",
"userAgent": "Boto3/1.29.7 md/Botocore#1.32.7 ua/2.0 os/windows#10 md/arch#amd64 lang/python#3.12.1 md/pyimpl#CPython cfg/retry-mode#legacy Botocore/1.32.7",
"errorCode": "ValidationException",
"errorMessage": "max_tokens_to_sample: range: 1..1,000,000",
"requestParameters": {
"modelId": "anthropic.claude-v2"
},
"responseElements": null,
"requestID": "d4dced7e-25c8-4e8e-a893-38c61e888d91",
"eventID": "419e15ca-2097-4190-a233-678415ed9a4f",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "[REDACTED]",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "bedrock-runtime.us-east-1.amazonaws.com"
}
}
Cloudtrail ログの例
AWS Bedrockはすべてのリージョンでサポートされているわけではないので、攻撃者はサポートされているリージョンでのみ “InvokeModel “を呼び出しました。現時点でBedrockがサポートされているのは、このようにus-east-1、us-west-2、ap-southeast-1、ap-northeast-1、eu-central-1、eu-west-3、us-gov-west-1です。リージョンによって異なるモデルが利用可能です。以下はAWSリージョン毎にサポートされるモデルのリストです。
GetModelInvocationLoggingConfiguration
興味深いことに、攻撃者はサービスがどのように設定されているかに興味を示しました。これは、”GetModelInvocationLoggingConfiguration “を呼び出すことで可能です。”GetModelInvocationLoggingConfiguration “は、有効になっていればS3とCloudwatchのロギング設定を返します。私たちのセットアップでは、S3とCloudwatchの両方を使用して、攻撃に関するできるだけ多くのデータを収集しました。
{
"loggingConfig": {
"cloudWatchConfig": {
"logGroupName": "[REDACTED]",
"roleArn": "[REDACTED]",
"largeDataDeliveryS3Config": {
"bucketName": "[REDACTED]",
"keyPrefix": "[REDACTED]"
}
},
"s3Config": {
"bucketName": "[REDACTED]",
"keyPrefix": ""
},
"textDataDeliveryEnabled": true,
"imageDataDeliveryEnabled": true,
"embeddingDataDeliveryEnabled": true
}
}Code language: JSON / JSON with Comments (json)GetModelInvocationLoggingConfiguration response の例
実行中のプロンプトとその結果に関する情報は Cloudtrail には保存されません。代わりに、その情報を Cloudwatch と S3 に送信するには追加の設定を行う必要があります。このチェックは、詳細な観察から彼らの活動の詳細を隠すために行われます。 OAI リバース プロキシは、「プライバシー」のためにログ記録が有効になっている AWS キーは使用しないと述べています。これにより、AWS Bedrock ベクターを使用している場合、プロンプトと応答を検査することができなくなります。
インパクト
LLM ジャッキング攻撃では、被害者へのコストの増加という形で損害が発生します。 LLM の使用は決して安くはなく、そのコストがすぐに膨らむ可能性があることを知っても驚くべきことではありません。攻撃者が Anthropic Claude 2.x を悪用し、複数のリージョンでクォータ制限に達するという最悪のシナリオを考慮すると、被害者のコストは 1 日あたり 46,000 ドルを超える可能性があります。
Claude 2 の価格設定と初期割り当て制限によると、次のようになります。
- 1000 個の入力トークンのコストは 0.008 ドル、1000 個の出力トークンのコストは 0.024 ドルです。
- AWS Bedrock によれば、1 分あたり最大 500,000 の入出力トークンを処理できます。入力トークンと出力トークン間の平均コストを考慮できます。これは、1000 トークンで 0.016 ドルです。
合計コストは次のようになります: (500K トークン/1000 * 0.016 ドル) * 60 分 * 24 時間 * 4 リージョン = 46,080 ドル/日
クォータ制限を最大化することで、攻撃者は侵害された組織がモデルを合法的に使用することをブロックし、ビジネス運営を混乱させることもできます。
検出
潜在的な脅威を迅速に検出して対応できる能力は、堅牢な防御を維持する上で大きな違いを生みます。最近のフィードバックと業界のベスト プラクティスから洞察を引き出し、検出機能を向上させるための重要な戦略を抽出しました。
- クラウドログ検出: Falco、Sysdig Secure、CloudWatch Alerts などのツールは欠かせない味方です。組織は、実行時のアクティビティを監視し、AWS Bedrock 内で採用されているような偵察戦術を含むクラウドログを分析することで、不審な動作を積極的に特定できます。
- 詳細なログ: 詳細なログを含む包括的なログにより、クラウド環境の内部動作に対する貴重な可視性が得られます。モデルの呼び出しやその他の重要なアクティビティに関する詳細な情報により、組織はクラウド環境でのアクティビティについて微妙な理解を得ることができます。
クラウドログ検出
クラウド ログを監視すると、不審なアクティビティや不正なアクティビティが明らかになる可能性があります。 Falco または Sysdig Secure を使用すると、攻撃中に使用された偵察方法を検出し、対応を開始できます。Sysdig Secure のお客様の場合、このルールは Sysdig AWS Notable Events ポリシーにあります。
Falcoルール:
- rule: Bedrock Model Recon Activity
desc: Detect reconaissance attempts to check if Amazon Bedrock is enabled, based on the error code. Attackers can leverage this to discover the status of Bedrock, and then abuse it if enabled.
condition: jevt.value[/eventSource]="bedrock.amazonaws.com" and jevt.value[/eventName]="InvokeModel" and jevt.value[/errorCode]="ValidationException"
output: A reconaissance attempt on Amazon Bedrock has been made (requesting user=%aws.user, requesting IP=%aws.sourceIP, AWS region=%aws.region, arn=%jevt.value[/userIdentity/arn], userAgent=%jevt.value[/userAgent], modelId=%jevt.value[/requestParameters/modelId])
priority: WARNINGCode language: PHP (php)さらに、CloudWatch アラートは、不審な動作を処理するように構成できます。 Bedrock のいくつかのランタイム メトリクスを監視して、アラートをトリガーできます。
詳細なログ
組織による言語モデル (LLM) サービスの使用状況を監視することは非常に重要であり、さまざまなクラウドベンダーがこのプロセスを合理化する機能を提供しています。これには通常、モデルの呼び出しに関するデータをログに記録して保存するメカニズムのセットアップが含まれます。
特に AWS Bedrock の場合、ユーザーは CloudWatch と S3 を活用して監視機能を強化できます。 CloudWatch は、ログ グループを作成し、必要な権限を持つロールを割り当てることで設定できます。同様に、S3 にログインするには、宛先として指定されたバケットが必要です。 InvokeModel コマンドの CloudTrail ログには、プロンプトの入力と出力に関する詳細がキャプチャされないことに注意することが重要です。ただし、Bedrock 設定を使用すると、モデル呼び出しのログを簡単にアクティブ化できます。さらに、100kb を超えるモデルの入力または出力データ、またはバイナリ形式の場合、大規模なデータ配信を処理するには、ユーザーが S3 宛先を明示的に指定する必要があります。これには、Base64 文字列としてログに保存される入力イメージと出力イメージが含まれます。このような包括的なログメカニズムにより、モデルの使用状況のあらゆる側面が確実に監視され、さらなる分析とコンプライアンスのためにアーカイブされます。
次の例に示すように、ログには、処理されたトークンに関する追加情報が含まれています。
{
"schemaType": "ModelInvocationLog",
"schemaVersion": "1.0",
"timestamp": "[REDACTED]",
"accountId": "[REDACTED]",
"identity": {
"arn": "[REDACTED]"
},
"region": "us-east-1",
"requestId": "bea9d003-f7df-4558-8823-367349de75f2",
"operation": "InvokeModel",
"modelId": "anthropic.claude-v2",
"input": {
"inputContentType": "application/json",
"inputBodyJson": {
"prompt": "\n\nHuman: Write a story of a young wizard\n\nAssistant:",
"max_tokens_to_sample": 300
},
"inputTokenCount": 16
},
"output": {
"outputContentType": "application/json",
"outputBodyJson": {
"completion": " Here is a story about a young wizard:\n\nMartin was an ordinary boy living in a small village. He helped his parents around their modest farm, tending to the animals and working in the fields. [...] Martin's favorite subject was transfiguration, the art of transforming objects from one thing to another. He mastered the subject quickly, amazing his professors by turning mice into goblets and stones into fluttering birds.\n\nMartin",
"stop_reason": "max_tokens",
"stop": null
},
"outputTokenCount": 300
}
}Code language: JSON / JSON with Comments (json)S3 ログの例
推奨事項
この攻撃は、次のようなさまざまな方法で防ぐことができたはずです。
- 初期アクセスを防止するための脆弱性管理
- 認証情報が盗まれる可能性のある場所に平文で保存されないようにするためのシークレット管理
- CSPM/CIEM を使用して、悪用されたアカウントに必要な最小限の権限が付与されていることを確認
最近の調査で明らかになっているように、クラウド ベンダーは、クラウド攻撃のリスクを軽減するために設計されたさまざまなツールとベストプラクティスを提供しています。これらのツールは、組織が最初から安全なクラウド環境を構築および維持するのに役立ちます。
たとえば、AWS はいくつかの堅牢なセキュリティ対策を提供しています。 AWS セキュリティリファレンスアーキテクチャーでは、クラウド環境を安全に構築するためのベストプラクティスの概要が説明されています。さらに、AWS では、サービス コントロール ポリシー (SCP) を使用してアクセス許可を一元管理することを推奨しています。これにより、悪用される可能性がある過剰なアクセス許可のアカウントに関連するリスクを最小限に抑えることができます。これらのガイドラインとツールは、セキュリティを強化し、クラウドインフラストラクチャーを効果的に保護するためのリソースをお客様に提供するという AWS の取り組みの一環です。他のクラウド ベンダーも同様のフレームワークとツールを提供しており、プラットフォームに関係なく、ユーザーがデータとサービスを保護するための重要なセキュリティ対策に確実にアクセスできるようにしています。
まとめ
盗まれたクラウドやSaaSの認証情報は、依然として一般的な攻撃経路となっています。この傾向は、攻撃者が金銭的な利益を得るために新しいアクセスを活用するあらゆる方法を学ぶにつれて、人気が高まる一方です。LLM サービスの利用は、モデルや投入されるトークンの量にもよりますが、高額になる可能性があります。通常、これによって開発者は効率的であろうとするはずですが、悲しいことに、攻撃者には同じ動機はありません。どんな問題にも迅速に対処するためには、検知と対応が重要です。
IoC
IP Addresses
83.7.139.184
83.7.157.76
73.105.135.228
83.7.135.97