LLMjacking：针对云托管AI大模型服务的新型攻击

Sysdig威胁研究团队(TRT)观察到一种新型攻击，命名为LLMjacking。它利用窃取的云凭证，对托管在云上的十个大型语言模型(LLM)服务发起攻击。

这些凭证是从一个流行的目标获得，即运行着一个存在漏洞的Laravel版本（CVE-2021-3129）的系统。针对基于LLM的人工智能（AI）系统的攻击经常被讨论，但大多围绕提示滥用和改变训练数据。在这种情况下，攻击者打算将LLM访问权出售给其他网络犯罪分子，而云账户所有者支付费用。

一旦获得初步访问权限，攻击者会窃取云凭证并获得了对云环境的访问权限，在那里他们试图访问由云服务提供商托管的本地LLM模型。例如安全人员发现其中一个案例，攻击者针对的是Anthropic 一个本地的Claude（v2/v3）LLM模型。在被研究人员发现之前，这种类型的攻击会给受害者带来严重的财务成本，最高将超过46000美元的LLM使用费用。

Sysdig研究人员发现了一个反向代理LLM的证据，它被用来提供对受损账户的访问，这意味着上述的猜测可能是对的，但也有可能是在提取LLM训练数据。

目标范围

目前安全人员已经发现攻击者调用模型请求所使用的工具。这是一个更加广泛的攻击脚本，它能够检查十种不同AI服务的凭证，以确定哪些对他们的目的有用。这些服务包括：

AI21 Labs, Anthropic, AWS Bedrock, Azure, ElevenLabs, MakerSuite, Mistral, OpenAI, OpenRouter, and GCP Vertex AI

攻击者正在牟取大量的跨不同服务LLM模型的访问权限。为了避免被系统发现，攻击者在查询阶段往往不会运行LLM模型，更多的工作在于弄清楚这些账号凭证可以做什么，以及会有哪些额外的限制，在可能的情况下查询日志设置。

LLMjacking攻击背景

托管的大型语言模型

包括Azure Machine Learning, GCP’s Vertex AI, and 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反向代理，该开源项目是LLM服务的反向代理。它将允许攻击者在不暴露底层凭证的情况下，或者不暴露底层受损凭证的情况下，集中管理对多个LLM账户的访问。在攻击者使用受损云凭证进行攻击期间，安全人员观察到一个与OAI反向代理匹配的用户代理尝试使用LLM模型。

上面的图片是安全人员在互联网上发现的一个OAI反向代理的例子。没有证据表明这个实例与监测到的攻击有关联，但它确实展示了收集和显示的信息类型。特别值得注意的是它可能记录的令牌计数（“tookens”）、成本和密钥。

这个例子展示了一个设置为使用多种类型LLM的OAI反向代理实例，并没有证据表明这个实例参与了攻击。

如果攻击者正在收集有用的凭证清单，并希望出售对可用LLM模型的访问权限，像这样的反向代理可以让他们成功变现。

技术分析

在技术分析中，安全人员探讨了攻击者如何在云环境中实施攻击。通过在云环境内使用看似合法的API请求，他们巧妙地测试了访问权限的边界，而不会触发警报。下面的例子展示了InvokeModel API调用的策略性使用。

虽然攻击者发出了一个有效的请求，但他们故意将max_tokens_to_sample参数设置为-1。这个不寻常的参数，通常预期会触发错误，却同时起到了双重作用。它不仅确认了对LLM的访问权限的存在，而且还表明这些服务是活动的，如由结果中的ValidationException所示。如AccessDenied错误，将表明访问受限。这种微妙的探测揭示了他们计算出用偷来的凭证在云账户内可以进行哪些操作的方法。

InvokeModel

InvokeModel调用由CloudTrail记录，下面可以看到一个恶意事件的例子。他们发送了一个合法的请求，但指定“max_tokens_to_sample”为-1。这是一个无效的错误，会引起“ValidationException”错误，但这对攻击者来说是有用的信息，因为它告诉他们凭证有权访问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。

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

    }

}

GetModelInvocationLoggingConfiguration响应示例

关于正在运行的提示及其结果的信息不会存储在Cloudtrail中。相反，需要进行额外的配置，将该信息发送到Cloudwatch和S3。进行这样的检查是为了隐藏他们的活动细节，避免被任何详细观察发现。OAI反向代理声明，为了“隐私”考虑，它不会使用任何启用了日志记录的AWS密钥。这使得如果他们使用AWS Bedrock通道，就无法检查提示和响应。

影响

在LLMjacking攻击中，对于攻击者最直接的危害是增加LLM模型运行成本。由于使用LLM并不便宜，因此可能会造成十分严重的财务损失。考虑到最坏的情况，即攻击者滥用Anthropic Claude 2.x，并在多个地区达到配额限制，受害者的成本可能超过每天46000美元。

具体计算方式可根据Claude 2的定价和初始配额：

• 1000个输入令牌的成本为0.008美元，1000个输出令牌的成本为0.024美元。
• 根据AWS Bedrock，最多可以每分钟处理500000个输入和输出令牌。安全人员可以考虑输入和输出令牌之间的平均成本，即1000令牌的成本为0.016美元。
• 总成本：（500K令牌/1000 * 0.016美元）* 60分钟 * 24小时 * 4个地区 = 每天46080美元。

通过最大化配额限制，攻击者还可以阻止受损组织合法使用模型，扰乱业务运营。

攻击检测参考

根据最近的反馈和行业最佳实践，以下安全措施可提高云服务商检测LLMjacking攻击的能力：

1. 云日志检测：像Falco、Sysdig Secure和CloudWatch Alerts这样的工具比较好用，组织可以通过监控运行时活动和分析云日志来主动识别可疑行为，包括在AWS Bedrock中使用的侦察策略等。
2. 详细日志记录：全面的日志记录，为了解云环境的内部运作提供了宝贵的可见性。关于模型调用和其他关键活动的详细信息，让组织对其云环境中的活动有了细致的理解。

云日志检测

监控云日志可以揭示可疑或未授权的活动。使用Falco或Sysdig Secure，可以检测到攻击过程中使用的侦察方法，并可以开始响应。

此外还可以配置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

    }

}

S3 日志示例

安全建议

这次攻击本可以通过多种方式预防，包括：

• 漏洞管理以防止初始访问。
• 秘密管理确保凭证不会明文存储，从而被盗取。
• CSPM/CIEM以确保被滥用的账户拥有其所需的最少权限。
• 正如最近研究所强调的，云供应商提供了一系列工具和最佳实践，旨在减轻云攻击的风险。这些工具帮助组织从一开始就构建并维护一个安全的云环境。

例如，AWS提供了几种强大的安全措施。AWS安全参考架构概述了安全构建云环境的最佳实践。此外，AWS建议使用服务控制策略（SCP）来集中管理权限，这有助于最小化与权限过多的账户相关的风险，这些账户可能会被滥用。这些指南和工具是AWS承诺增强安全性并为客户提供有效保护其云基础设施资源的一部分。其他云供应商提供了类似的框架和工具，确保用户无论在哪个平台上都能够访问至关重要的安全措施，以保护他们的数据和服务。

结论

盗用的云和SaaS凭证继续是一种常见的攻击途径。随着攻击者了解他们可以利用新获取的访问权限获得财务收益的所有方式，这种趋势只会越来越受欢迎。使用LLM服务的成本可能会很高，这取决于模型和被输入的令牌数量。通常，这会促使开发者尝试效率化，遗憾的是攻击者没有同样的动机，因此检测和响应对于快速处理任何问题至关重要。

IoCs

IP Addresses

83.7.139.184

83.7.157.76

73.105.135.228

83.7.135.97