Serverless安全防线：令牌窃取的攻与防

Dubito 云原生安全指北
2025年06月18日 08:30

 

在Serverless架构席卷云计算的今天，其轻量化、高弹性的特性背后隐藏着严峻的安全挑战——身份令牌正成为攻击者突破云环境的新入口。本文将深入解析三大云平台Serverless认证机制的脆弱环节，还原攻击者从SSRF漏洞利用到令牌窃取的全链条攻击路径，并给出防护方案。无论您是云安全工程师还是架构师，都能从中获得可直接落地的安全实践，帮助企业在享受Serverless技术红利的同时，筑牢云端最后一道防线。

注：本文翻译自Unit 42的文章《Serverless Tokens in the Cloud: Exploitation and Detections》[1]，可点击文末“阅读原文”按钮查看英文原文。

全文如下：

摘要

本文概述了主流云平台Serverless认证机制的运行原理及安全影响。攻击者将Serverless函数作为目标，企图利用应用开发者部署不安全代码和错误配置云函数所产生的漏洞。成功利用这些弱点可使攻击者获取凭据并实施滥用。

Serverless计算函数通常与云身份相关联，这些身份通过认证令牌获取临时、限定范围的云服务和资源访问权限。窃取这些令牌可能导致云环境暴露于安全风险之中。

AWS Lambda[2]、Azure Functions[3]和Google Cloud Run Functions[4]等Serverless平台及函数均使用凭据体系，包括AWS中的身份与访问管理(IAM)[5]角色、Azure的托管身份[6]以及谷歌云平台(GCP)的服务账户令牌[7]。

理解这些服务的运行机制有助于制定有效策略，既可避免令牌暴露，也能检测可能导致云环境沦陷的令牌滥用行为。此类安全事件通常涉及权限提升、在环境中维持恶意持久化，以及窃取本应仅限合法身份访问的敏感信息。

一、引言

Serverless计算是一种云服务模型，AWS（Lambda）、Azure（Functions）和谷歌云（Functions）等提供商负责基础设施管理、弹性扩展和运维工作。该模型使企业及其开发者能专注于代码开发，而云服务商处理后端任务。

Serverless函数基于事件驱动机制运行，通过HTTP请求、数据库变更或定时事件等触发器执行。函数服务的自动扩缩容功能可根据需求调整资源，云服务商仅按实际执行时间和资源用量计费，确保成本效益。

尽管Serverless计算简化了开发和部署流程，但必须认清与此类服务相关的潜在风险。部分风险源于开发者可为Serverless函数分配身份，这些身份以凭证集形式呈现，可供函数内执行的代码访问。此类凭证用于云操作的身份验证和授权。

这些凭证附带的权限集合决定了其使用范围。根据函数绑定身份所关联的权限，相关凭证可能被用于访问云资源和敏感数据。

攻击者瞄准Serverless函数的原因包括：

  • • 由于不安全开发实践，Serverless函数常存在远程代码执行(RCE)或服务端请求伪造(SSRF)漏洞
  • • Serverless函数通常公开暴露（无论设计如此还是配置错误）或需要处理外部输入源
  • • 攻击者可利用Serverless令牌获取未授权的读写权限，进而危及关键基础设施和数据

在使用Serverless函数时，必须充分考虑应用开发者向云函数部署不安全代码所带来的风险，并深入理解针对这些函数的威胁态势。

二、主流云平台Serverless认证机制解析

Serverless架构通过按需执行函数来部署应用，其核心优势在于可根据需求启停应用或特定组件，无需持续维护运行环境。

各主流云服务商的Serverless函数具有以下共性特征：

  • • 支持多编程语言
  • • 全托管架构，不提供SSH访问
  • • 采用角色、服务账户或托管身份来安全地管控资源访问

2.1 AWS Lambda认证机制

AWS通过IAM服务管理用户、权限、群组和角色，控制对云账户/服务的访问权限。Lambda角色默认无权限，需通过IAM策略管理对其他AWS服务的访问授权。

为简化权限管理，AWS提供托管策略（如AWSLambdaBasicExecutionRol），开发者常直接绑定此类策略以快速启用基础功能。当Lambda函数关联IAM角色时，AWS安全令牌服务（STS）[8]会自动生成该角色的临时安全凭证[9]。

这种机制通过运行时动态获取凭证，避免了长期硬编码凭证的风险。凭证权限范围受角色关联策略约束，包含访问密钥ID、秘密访问密钥和会话令牌三要素。Lambda运行时服务将这些凭证加载至函数执行环境，存储为AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY 和 AWS_SESSION_TOKEN等环境变量供代码调用，确保函数安全交互AWS服务。

2.2 谷歌云函数认证机制

谷歌云函数使用服务账户令牌进行身份验证。服务账户是关联于项目的特殊账号，代表非人类实体身份。部署时可选择绑定自定义服务账户或默认服务账户[10]：

  • • 使用自定义服务帐户时：开发者可以分配特定的 IAM 角色，以定义函数执行任务所需的确切权限。
  • • 默认服务帐号是用户管理的帐号[11]，当用户启用特定服务时，Google Cloud 会自动创建这些帐号。默认情况下，Google Cloud Functions 会根据版本[12]使用不同的服务帐号：
    • • 第一代Cloud Run函数使用App Engine默认服务账户（<project_id>@appspot.gserviceaccount[.]com）
    • • 第二代Cloud Run函数使用默认计算服务账户（<project_number>[email protected][.]com）

无组织架构的GCP项目中，默认服务账户具有编辑者Editor权限，允许在项目中创建、修改和删除资源；组织内项目则需显式分配角色权限，否则无任何权限。与传统VM实例类似，函数运行时通过位于 hxxp://metadata.google[.]internal/ 的实例元数据服务器（Instance Metadata Server，IMDS）[13]获取短期有效的服务账户令牌用于GCP服务认证。

2.3 Azure函数认证机制

Azure托管身份为资源提供免硬编码凭证的安全认证方案，分为：

  • • 系统分配托管身份：与单一资源绑定，随资源删除自动销毁
  • • 用户分配托管身份：可关联多个服务的独立资源

认证流程分五步：

  1. 1. 函数从环境变量获取IDENTITY_ENDPOINT（本地托管身份端点地址，用于请求令牌）和IDENTITY_HEADER（防SSRF攻击的必需头）
  2. 2. 向端点发起含IDENTITY_HEADER的HTTP GET请求 (有关请求结构的详细信息，请参阅 Azure 关于获取应用服务令牌的文档[14] )
  3. 3. Microsoft Entra ID[15]（原Azure AD）验证身份后签发针对目标资源的OAuth 2.0临时令牌
  4. 4. 函数在请求Azure资源（如 Azure Key Vault[16]、存储帐户[17]）时携带该令牌
  5. 5. 资源端通过基于角色的访问控制（role-based access control，RBAC）[18]或资源特定策略[19]验证权限

该机制既保障了认证安全性，又避免了代码中存储敏感凭证的风险。

译者补充：

目标资源Microsoft Entra ID(原Azure AD)Azure托管身份服务函数/应用目标资源Microsoft Entra ID(原Azure AD)Azure托管身份服务函数/应用前置条件：已启用托管身份alt[权限有效][权限无效]1. 读取环境变量IDENTITY_ENDPOINT、DENTITY_HEADER2. HTTP GET 请求(携带IDENTITY_HEADER)3. 身份验证请求签发OAuth 2.0令牌返回访问令牌4. 携带令牌访问资源5. 验证令牌有效性验证结果返回请求数据返回403错误

三、令牌窃取攻击向量分析

本节探讨Serverless函数使用中涉及的风险与威胁。开发者在开发和配置函数时，必须防范SSRF（服务端请求伪造）和RCE（远程代码执行）等攻击。若防护不足，攻击者可能操纵存在漏洞的函数向内部服务发起未授权请求，导致访问令牌、数据库内容或服务配置等敏感信息泄露。需特别强调的是，此类风险主要存在于公开暴露或处理外部输入的函数中。

3.1 攻击原理剖析

SSRF攻击：攻击者诱使服务器（如Serverless函数）向本无权限访问的内外部资源发起HTTP请求。由于请求由服务器本身发出，可访问未暴露于互联网的内部服务。例如在GCP中，利用SSRF访问元数据服务器（IMDS）hxxp://metadata.google[.]internal/可获取短期有效的服务账户令牌，进而以函数身份执行越权操作。

RCE攻击：允许攻击者在函数执行环境中运行任意代码。例如在AWS Lambda中，可通过RCE窃取环境变量中的AWS_ACCESS_KEY_ID、AWS_SESSION_TOKEN 等临时凭证。

需明确，这些攻击向量并非云平台固有缺陷，而是源于开发者编写的存在SSRF/RCE漏洞的不安全代码。通过实施输入验证等安全编码实践可有效降低风险。

3.2 攻击模拟实验

以下模拟演示攻击者如何在不同云平台窃取Serverless令牌并实施恶意操作，所有场景均基于开发者部署的不安全函数代码。

3.2.1 模拟实验1：从GCP函数直接访问IMDS元数据

部署两个Google Cloud Run函数，从以下路径分别提取默认服务账户和自定义服务账户的令牌：
hxxp[://]metadata.google[.]internal/computeMetadata/v1/instance/service-accounts/default/token

示例1：提取默认服务账户令牌

  • • 如图1所示，函数绑定的默认服务账户
  • • 如 图2所示，通过cURL命令成功提取访问令牌（令牌所属账户与图1一致）
图1. 有关该功能的基础信息，包括附加的服务帐户名称（默认服务帐户）
图1. 有关该功能的基础信息，包括附加的服务帐户名称（默认服务帐户）
图2. 用于提取服务帐户访问令牌的命令的代码片段及输出
图2. 用于提取服务帐户访问令牌的命令的代码片段及输出

示例2：提取GCP自定义服务账户令牌

  • • 如图3所示，函数绑定的自定义服务账户
  • • 如图4所示，获取访问令牌
图3. 有关该功能的基础信息，包括附加的服务帐户名称（自定义服务帐户）
图3. 有关该功能的基础信息，包括附加的服务帐户名称（自定义服务帐户）
图 4. 用于提取服务帐户访问令牌的命令的代码片段及输出
图 4. 用于提取服务帐户访问令牌的命令的代码片段及输出

攻击影响：

  • • 可使用窃取令牌列取存储桶（如图5所示）；若攻击者能够列出并读取 GCP 中的存储桶内容，即可访问敏感文件，例如凭证、备份或内部配置。这使得他们能够窃取数据、入侵系统或在环境内横向移动。
  • • 若攻击者获取具有Editor权限的令牌（如默认Compute Engine服务账户），可对项目内绝大多数资源进行增删改操作，包括访问敏感数据、部署恶意负载、权限提升或服务中断等
图 5.使用返回的令牌列出服务帐户中的存储桶
图 5.使用返回的令牌列出服务帐户中的存储桶

3.2.2 模拟实验2：利用RCE窃取AWS Lambda环境变量凭证

在此模拟中，我们访问了 Lambda 函数的环境变量并从中提取了 AWS_ACCESS_KEY_ID 、 AWS_SECRET_ACCESS_KEY 和 AWS_SESSION_TOKEN 。

  • • 从Lambda环境变量中提取AWS_ACCESS_KEY_ID等临时凭证（如图6所示）
  • • 使用窃取凭证通过命令aws s3 ls列举S3存储桶（如图7所示）
图 6. 返回的环境变量的值
图 6. 返回的环境变量的值
图 7. 用于列出 S3 存储桶的命令代码片段
图 7. 用于列出 S3 存储桶的命令代码片段

3.2.3 模拟实验3：利用RCE从 Azure 函数的本地身份端点检索令牌

  • • 通过远程命令提取Azure函数环境变量中的IDENTITY_ENDPOINT和IDENTITY_HEADER
  • • 向本地身份端点发起请求获取访问令牌的脚本输出（如图8所示），需提供以下参数：
    • • Resource
    • • api-version
    • • X-IDENTITY-HEADER
图 8. 包含访问令牌的脚本输出
图 8. 包含访问令牌的脚本输出

译者补充：所有模拟攻击均证明，一旦攻击者获取函数身份令牌，即可在对应权限范围内实施数据窃取、横向移动或资源破坏。这凸显了实施最小权限原则和严格输入验证的重要性。

四、令牌窃取检测与防护

4.1 检测Serverless环境中的令牌泄漏

有效的检测机制对识别Serverless环境中的令牌窃取行为至关重要。这些机制主要通过行为异常分析来标记未授权活动，包含两个关键检测阶段：

  1. 1. 验证身份是否绑定Serverless函数
  2. 2. 识别身份异常行为，包括：
    • • 与函数执行上下文不符的源IP地址（如非云服务提供商的ASNs（Autonomous System Numbers，自治系统编号）地址）
    • • 使用可疑User-Agent发起请求的Serverless身份

详细步骤如下：

4.1.1 识别Serverless身份

GCP环境中，可通过分析日志中的serviceAccountDelegationInfo字段识别绑定Serverless函数的服务账户。该字段揭示了服务账户的委托链特征——当服务账户绑定函数时，会将其权限委托给默认Serverless服务账户：

  • • Google Cloud Run服务代理（service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com）
  • • GCF管理机器人账户（service-<PROJECT_NUMBER>@gcf-admin-robot.iam.gserviceaccount[.]com）
图 9. 显示自定义服务帐户的日志条目
图 9. 显示自定义服务帐户的日志条目

如图9日志示例所示，自定义服务账户sa-test@<project-id>.iam.gserviceaccount[.]com将其权限委托给Cloud Run服务代理。其中：

  • • authenticationInfo.principalEmail字段指明实际使用的服务账户sa-test[@]xdr-analytics.iam.gserviceaccount[.]com
  • • serviceAccountDelegationInfo字段显示第一方主体（即默认Serverless服务账户，本例中为 service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com），证明该身份运行在Cloud Functions或Cloud Run等Serverless环境中

一个有效的检测策略是对曾委托权限给默认Serverless服务账户的所有服务账户进行画像分析，确保能识别绑定函数的非默认服务账户。

AWS环境检测特征：
Lambda函数通过IAM角色获取临时凭证，可通过角色名称识别Lambda身份。

Azure环境检测特征：
Azure Function Apps使用绑定的托管身份进行认证，需监控相关身份的使用模式。

4.1.2 识别Serverless身份的异常行为

在安全的云环境中，Serverless函数通常用于执行自动化、限定范围的任务（如响应API请求或处理事件），而非交互式操作。若攻击者获取函数环境或其身份权限，可能滥用其身份直接通过命令行工具（如gcloud CLI或curl）与云资源直接交互。

检测方法一：user agent分析

  • • 监控API调用的user agent特征，若匹配已知CLI工具（如gcloud CLI）或渗透测试框架，则标记为可疑行为
  • • 注：该方法不适用于Azure环境，因其日志不包含user agent信息

检测方法二：网络源地址分析

  • • 通过ASN（自治系统号）范围关联分析，若请求源自云服务商IP范围之外，则触发告警
  • • 建立云服务商IP数据库（如AWS的IP地址范围），实时比对请求来源

4.2 防护策略

保障Serverless令牌安全需结合主动防御措施、安全状态管理和运行时监控，以降低攻击风险。首要原则是实施最小权限机制，为Serverless功能分配仅需的最低权限角色，从而限制令牌滥用可能造成的危害。

对于GCP和Azure的Serverless运行环境，应配置网络层控制策略并实施请求验证机制，严格限制对实例元数据服务(IMDS)的访问。同时强化输入验证与净化处理，防范攻击者利用SSRF等技术获取敏感元数据、令牌及API、数据库等云资源。

五、总结

Serverless计算凭借其卓越的扩展性、成本效益和简化的基础设施管理，已成为现代应用开发的首选方案。然而，这些功能与云服务交互所使用的凭证既是关键安全要素，也是攻击者的主要目标。一旦凭证泄露，将导致未授权访问云资源和数据外泄等严重后果。

实施主动的安全状态管理和运行时监控防护，是保障云环境安全的核心策略。企业可通过以下方式加强Serverless环境防护：

  • • 深入理解AWS[20]、Azure[21]和GCP[22]平台的Serverless凭证机制及管理最佳实践
  • • 识别常见攻击向量，如通过IMDS漏洞或环境变量窃取令牌等

引用链接

[1] 《Serverless Tokens in the Cloud: Exploitation and Detections》:https://unit42.paloaltonetworks.com/serverless-authentication-cloud/
[2]AWS Lambda:https://aws.amazon.com/lambda/
[3]Azure Functions:https://learn.microsoft.com/en-us/azure/azure-functions/functions-overview?pivots=programming-language-csharp
[4]Google Cloud Run Functions:https://cloud.google.com/functions?hl=en
[5]身份与访问管理(IAM):https://docs.aws.amazon.com/whitepapers/latest/introduction-aws-security/identity-and-access-control.html
[6]托管身份:https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview
[7]服务账户令牌:https://cloud.google.com/iam/docs/service-account-creds
[8]安全令牌服务（STS）:https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html
[9]临时安全凭证:https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html
[10]默认服务账户:https://cloud.google.com/iam/docs/service-account-types#default
[11]用户管理的帐号:https://cloud.google.com/compute/docs/access/service-accounts#user-managed
[12]根据版本:https://cloud.google.com/run/docs/functions/comparison
[13]实例元数据服务器（Instance Metadata Server，IMDS）:https://cloud.google.com/run/docs/container-contract#metadata-server
[14]Azure 关于获取应用服务令牌的文档:https://learn.microsoft.com/en-us/azure/app-service/overview-managed-identity?tabs=portal%2Cdotnet#using-the-rest-protocol
[15]Microsoft Entra ID:https://learn.microsoft.com/en-us/entra/fundamentals/whatis
[16]Azure Key Vault:https://learn.microsoft.com/en-us/azure/key-vault/general/overview
[17]存储帐户:https://learn.microsoft.com/en-us/azure/storage/common/storage-account-overview
[18]基于角色的访问控制（role-based access control，RBAC）:https://learn.microsoft.com/en-us/azure/role-based-access-control/overview
[19]资源特定策略:https://learn.microsoft.com/en-us/azure/key-vault/general/secure-your-key-vault#access-policies-vs-azure-rbac
[20]AWS:https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda
[21]Azure:https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda
[22]GCP:https://cloud.google.com/iam/docs/best-practices-service-accounts#limit-service-account-privileges

 


阅读原文