“
2024年4月28日是Eastmount的安全星球 —— 『网络攻防和AI安全之家』正式创建和运营的日子，该星球目前主营业务为 安全零基础答疑、安全技术分享、AI安全技术分享、AI安全论文交流、威胁情报每日推送、网络攻防技术总结、系统安全技术实战、面试求职、安全考研考博、简历修改及润色、学术交流及答疑、人脉触达、认知提升等。下面是星球的新人券，欢迎新老博友和朋友加入，一起分享更多安全知识，比较良心的星球，非常适合初学者和换安全专业的读者学习。
”
这是作者新开的一个专栏，主要翻译国外知名安全厂商的技术报告和安全技术，了解它们的前沿技术，学习它们威胁溯源和恶意代码分析的方法，希望对您有所帮助。当然，由于作者英语有限，会借助LLM进行校验和润色，最终结合自己的安全经验完成，还请包涵！
上一篇文章讲解黑客如何利用聊天机器人的功能来恢复OpenAI ChatGPT、Microsoft Copilot和大多数AI聊天机器人的加密聊天记录。这篇文章将Sysdig威胁研究团队最近观察到一种新型攻击——LLMjacking，该攻击利用被盗取的云凭据来破坏十个云托管的大语言模型（LLM）服务。该文章翻译自sysdig研究团队，基础性技术文章，希望您喜欢！
文章目录：
一.摘要
二.广泛的攻击目标
三.背景
1.托管LLM模型
2.LLM反向代理（Reverse Proxy）
四.技术分析
1.InvokeModel
2.GetModelInvocationLoggingConfiguration
五.Impact
六.检测
1.云日志检测
2.详细的日志记录
七.建议
八.结论
原文标题：《LLMjacking: Stolen Cloud Credentials Used in New AI Attack》
原文链接：https://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/
文章作者：ALESSANDRO BRUCATO
发布时间：2024年5月6日
文章来源：https://sysdig.com
研究主题：CLOUD SECURITY, THREAT RESEARCH
Sysdig威胁研究团队（TRT，Threat Research Team）最近观察到一种新型攻击——LLMjacking，该攻击利用被盗取的云凭据来破坏十个云托管的大语言模型（LLM）服务。这些被盗凭据是从一个流行的目标系统中获取的，该系统运行着Laravel的易受攻击版本（CVE-2021-3129）。
虽然基于LLM的人工智能（AI）系统攻击经常被讨论，但这些讨论主要集中在滥用提示和篡改训练数据上。在这种情况下，攻击者打算将这些LLM的访问权限出售给其他网络犯罪分子来获利，而实际的云账户所有者则需要支付账单。
prompt abuse
altering training data
一旦获得初始访问权限，他们便提取云凭据并获得对云环境的访问权限，从而访问云提供商托管的本地LLM模型。在此案例中，他们针对的是Anthropic的本地Claude（v2/v3）LLM模型。如果未被发现，此类攻击可能会导致受害者每天承担超过46,000美元的LLM消费成本。
Sysdig研究人员发现了用于为受损账户提供访问权限的LLM反向代理的证据，这表明存在经济动机。然而，另一种可能的动机是提取LLM训练数据。整个攻击流程如下图所示：
我们成功发现了在攻击过程中用于调用模型的请求生成工具。这揭示了一个更广泛的脚本，该脚本能够检查十个不同AI服务的凭据，以确定哪些服务对攻击者的目的有用。这些服务包括：
AI21 Labs
Anthropic
AWS Bedrock
Azure
ElevenLabs
MakerSuite
Mistral
OpenAI
OpenRouter
GCP Vertex AI
攻击者试图获取跨不同服务的各类大模型（LLM）的访问权限。在验证阶段，实际上并没有运行任何合法的LLM查询。相反，他们只是进行了足够多的操作来确定凭据的权限和相关配额限制。此外，在可能的情况下，还会查询日志设置。这样做是为了在使用被泄露的凭据运行其提示时避免被检测到。
所有主要的云提供商，包括Azure Machine Learning、GCP的Vertex AI 和 AWS Bedrock，现在都提供大型语言模型（LLM）服务。这些平台为开发人员提供了轻松访问基于LLM的人工智能中所使用的各种常见模型的途径。如下图所示，用户界面设计得非常简单，使开发人员能够快速地构建应用程序。
然而，这些模型在默认情况下是不启用的。相反，需要向云提供商提交请求才能运行它们。对于某些模型，请求是自动批准的；而对于其他模型（如第三方模型），则需要填写一个小表单。一旦发出请求，云供应商通常会很快启用访问权限。对于攻击者来说，提交请求的要求通常更像一个减速带而非真正的阻碍，因此不应将其视为一种安全机制。
云提供商通过使用简单的命令行界面（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
验证凭据是否能够使用目标大模型（LLMs）的密钥检查代码还引用了另一个项目——OAI Reverse Proxy。这一开源项目充当了LLM服务的反向代理。使用此类软件将允许攻击者集中管理对多个LLM账户的访问，同时不暴露底层凭据，或在此情况下，不泄露底层凭据池。在利用被泄露的云凭据进行攻击中，可以观察到与OAI Reverse Proxy相匹配的用户代理试图使用LLM模型。
上图展示了我们在互联网上发现的一个OAI反向代理的示例。没有证据表明这个实例与这次攻击有任何关联，但它确实展示了所收集和显示的信息类型。特别要注意的是，它可能正在记录令牌数量(“tookens”)、成本和密钥等信息。
这个例子展示了一个OAI反向代理的实例，它被设置为使用多种类型的LLMs。目前没有证据表明这个实例与本次攻击事件有关联。
如果攻击者正在收集有用的凭据清单，并希望出售对可用LLM模型的访问权，那么像这样的反向代理可以使他们的努力成为现实（变现）。
在这次技术分析中，我们将探讨攻击者如何在云环境中执行入侵。通过在云环境中使用看似合法的API请求，他们巧妙地测试了访问权限的边界，同时避免立即触发警报。
以下示例展示了CloudTrail记录的InvokeModel API调用的使用策略。尽管攻击者发出了一个有效的请求，但他们故意将max_tokens_to_sample参数设置为-1。这个不寻常的参数通常被认为会引发错误，但实际上起到了双重作用。它不仅确认了存在对LLMs的访问权限，还通过产生的ValidationException表明这些服务是活动的。如果结果不同，比如出现AccessDenied错误，则表明访问受限。这种微妙的探测揭示了一种精心计算的方法，攻击者可以通过其发现被盗取的凭据在云账户中允许哪些操作。
InvokeModel调用会被CloudTrail记录，下面可以看到一个恶意事件示例。攻击者发送了一个看似合法的请求，但故意将“max_token_to_sample”参数设置为-1。这是一个无效的值，会导致“ValidationException”错误，但对于攻击者来说，这是一个有用的信息，因为它告诉了攻击者所持有的凭据具有访问LLMs的权限，并且这些服务已经启用。否则，他们将收到一个“AccessDenied”错误。
Cloudtrail日志示例如下所示：
`{`` ` `"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"`` ` `}` `}`
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”来完成，如果启用，它将返回S3和Cloudwatch的日志配置。在我们的设置中，同时使用S3和Cloudwatch来收集尽可能多的攻击数据。
下面展示了GetModelInvocationLoggingConfiguration的响应：
`{`` ` `"loggingConfig": {`` ` `"cloudWatchConfig": {`` ` `"logGroupName": "[REDACTED]",`` ` `"roleArn": "[REDACTED]",`` ` `"largeDataDeliveryS3Config": {`` ` `"bucketName": "[REDACTED]",`` ` `"keyPrefix": "[REDACTED]"`` ` `}`` ` `},`` ` `"s3Config": {`` ` `"bucketName": "[REDACTED]",`` ` `"keyPrefix": ""`` ` `},`` ` `"textDataDeliveryEnabled": true,`` ` `"imageDataDeliveryEnabled": true,`` ` `"embeddingDataDeliveryEnabled": true`` ` `}`` ``}`
在AWS Bedrock中，关于正在运行的提示（prompts）及其结果的信息不会存储在CloudTrail中。相反，需要进行额外的配置才能将这些信息发送到CloudWatch和S3。这种检查是为了隐藏其活动的细节，避免任何详细的观察。OAI反向代理声称，它不会使用任何启用了日志记录的AWS密钥，以保护“隐私”。如果攻击者使用AWS Bedrock作为攻击向量，就无法检查提示和响应。
在LLMjacking攻击中，受害者的损失主要表现为成本增加。考虑到使用大语言模型（LLM）并不便宜，并且成本可能迅速累积，这一点不足为奇。在最坏的情况下，如果攻击者滥用Anthropic Claude 2.x并在多个区域达到配额限制，受害者每天的成本可能超过4.6万美元。
根据定价和Claude 2的初始配额限制:
1000个输入tokens的费用为0.008美元，1000个输出tokens的费用为0.024美元。
根据AWS Bedrock，每分钟最多可以处理500,000个输入和输出tokens。我们可以考虑输入和输出tokens之间的平均成本，1000个tokens的平均成本为0.016美元。
最终总成本的计算如下：
通过最大化配额限制，攻击者还可以阻止受损组织合法地使用模型，从而破坏业务操作。
检测和迅速响应潜在威胁的能力对于维护坚固的防御至关重要。根据最近的反馈和行业最佳实践，我们提炼出了提升检测能力的关键策略：
云日志检测（Cloud Logs Detections）：Falco、Sysdig Secure和CloudWatch Alerts等工具是不可或缺的辅助。组织可以通过监控运行时活动和分析云日志来主动识别可疑行为，譬如这些日志中可能包含在AWS Bedrock中使用的侦察战术等关键信息。这些工具帮助组织及时发现潜在威胁，并采取相应的安全措施。
详细的日志记录（Detailed Logging）：全面的日志记录，包括详细的日志记录，为云环境的内部运作提供了宝贵的透明性。关于模型调用和其他关键活动的详尽信息，使组织能够对其云环境中的活动有深入的了解。这些详细日志有助于及时发现异常行为，并为安全审计和故障排查提供重要依据。
监控云日志可以发现可疑或未经授权的活动。通过使用Falco或Sysdig Secure，可以检测到攻击期间所使用的侦察方法，并启动相应的响应。对于Sysdig Secure客户，此规则可以在Sysdig AWS Notable Events策略中找到。
监视云日志可以发现可疑或未经授权的活动。使用Falco或Sysdig Secure，可以检测攻击期间使用的侦察方法，并可以启动响应。对于Sysdig Secure客户，可以在Sysdig AWS值得注意事件策略中找到此规则。
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: WARNING`
此外，CloudWatch警报可以配置来处理可疑行为，可以监控Bedrock的几个运行时指标来触发警报。
监控组织对大模型（LLM）服务的使用至关重要，各种云供应商提供了用于简化此过程的工具。这通常涉及设置机制来记录和存储关于模型调用的数据。
特别是对于AWS Bedrock来说，用户可以利用CloudWatch和S3来增强监控能力。首先，可以通过创建一个日志组并分配具有必要权限的角色来设置CloudWatch。类似地，为了将日志记录到S3，需要一个指定的桶作为目标。需要注意的是，InvokeModel命令的CloudTrail日志不会捕获有关提示输入和输出的详细信息。然而，Bedrock设置允许轻松激活模型调用日志记录。此外，对于大于100kb或二进制格式的模型输入或输出数据，用户必须明确指定一个S3目标来处理大数据传输。这包括作为Base64字符串存储在日志中的输入和输出图像。这种全面的日志记录机制确保了模型使用的各方面都被监视和存档，以便进行进一步的分析和合规性检查。
日志中包含有关所处理令牌的附加信息，S3 log的示例如下：
`{`` ` `"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`` ` `}`` ``}`
我们可以通过以下几种方式阻止这种攻击（LLMjacking），包括:
确实，随着云计算的广泛应用，云供应商提供了一系列的工具和最佳实践，旨在降低云攻击的风险，并帮助组织从一开始就构建和维护一个安全的云环境。
AWS确实提供了多种强大的安全措施来帮助用户构建安全的云环境。AWS安全参考架构概述了安全构建云环境的最佳实践。此外，AWS建议使用服务控制策略(SCP)来集中管理权限，这有助于最大限度地降低与可能被滥用的过度授权帐户相关的风险。这些指导方针和工具是AWS致力于增强安全性并为客户提供有效保护其云基础设施的资源的一部分。
除了AWS外，其他云计算供应商也提供了类似的框架和工具，以帮助用户保护他们的数据和服务。无论选择哪个平台，用户都应该认真考虑和实施安全措施，以确保云环境的安全性和可靠性。
被盗取的云服务和SaaS凭据俨然已成为常见的攻击途径。随着攻击者掌握利用新获得的访问权限以获取经济利益的各类方式增加，这一趋势将变得日益流行。使用LLM（大型语言模型）服务的成本可能很高，这取决于模型类型和输入令牌的数量。通常，这会促使开发者努力提高效率——遗憾的是，攻击者并没有同样的动力。因此，检测和响应机制对于快速处理任何安全问题至关重要。
IoCs：IP Addresses
83.7.139.184
83.7.157.76
73.105.135.228
83.7.135.97
『网络攻防和AI安全之家』目前收到了很多博友、朋友和老师的支持和点赞，尤其是一些看了我文章多年的老粉，购买来感谢，真的很感动，类目。未来，我将分享更多高质量文章，更多安全干货，真心帮助到大家。虽然起步晚，但贵在坚持，像十多年如一日的博客分享那样，脚踏实地，只争朝夕。继续加油，再次感谢！
(By:Eastmount 2024-05-20 夜于贵阳)