浅谈云上攻防之元数据服务带来的安全挑战

关注

发布于: 2021 年 06 月 09 日

原创作者：腾讯安全云鼎实验室 ruiqiang

前言

在针对云上业务的的攻击事件中，很多攻击者将攻击脆弱的元数据服务作为攻击流程中重要的一个环节并最终造成了严重的危害。

以 2019 年的美国第一资本投资国际集团（CapitalOne）信息泄露事件举例，根据《ACase Study of the Capital One Data Breach》报告指出，攻击者利用 CapitalOne 部署在 AWS 云上实例中的 SSRF 漏洞向元数据服务发送请求并获取角色的临时凭证，在获取角色临时凭据后将该角色权限下的 S3 存储桶中的数据复制到攻击者的本地机器上，最终导致这一严重数据泄露事件的产生，这一事件影响了北美超过 1 亿人。CapitalOne 的股价在宣布数据泄露后收盘下跌 5.9%，在接下来的两周内总共下跌了 15%。

Capital One 信息泄露事件攻击原理图，可参见图：

CapitalOne信息泄露事件攻击原理图

在介绍元数据服务带来的安全挑战之前，我们先来简单介绍一下元数据服务以及角色的概念。

01 元数据服务以及角色介绍

元数据服务

元数据即表示实例的相关数据，可以用来配置或管理正在运行的实例。用户可以通过元数据服务在运行中的实例内查看实例的元数据。

以 AWS 举例，可以在实例内部访问如下地址来查看所有类别的实例元数据：

http://169.254.169.254/latest/meta-data/

169.254.169.254 属于链路本地地址（Link-localaddress），链路本地地址又称连结本地位址，是计算机网络中一类特殊的地址，它仅供于在网段，或广播域中的主机相互通信使用。这类主机通常不需要外部互联网服务，仅有主机间相互通讯的需求。IPv4 链路本地地址定义在 169.254.0.0/16 地址块。

而在具体的技术实现上，云厂商将元数据服务运行在 Hypervisor（虚拟机管理程序）上。当实例向元数据服务发起请求时，该请求不会通过网络传输，也永远不会离开这一台计算机。基于这个原理，元数据服务只能从实例内部访问。

可以 PING 云厂商所提供的元数据服务域名，以查看其 IP 地址

从上图可见，元数据服务属于链路本地地址。

从设计上来看，元数据服务看起来很安全，那为什么说元数据服务脆弱呢？

由于元数据服务部署在链路本地地址上，云厂商并没有进一步设置安全措施来检测或阻止由实例内部发出的恶意的对元数据服务的未授权访问。攻击者可以通过实例上应用的 SSRF 漏洞对实例的元数据服务进行访问。

因此，如果实例中应用中存在 SSRF 漏洞，那么元数据服务将会完全暴露在攻击者面前。

在实例元数据服务提供的众多数据中，有一项数据特别受到攻击者的青睐，那就是角色的临时访问凭据。这将是攻击者由 SSRF 漏洞到获取实例控制权限的桥梁。

访问管理角色

既然攻击涉及到访问管理角色的临时凭据，我们首先看下访问管理角色是什么：

访问管理的角色是拥有一组权限的虚拟身份，用于对角色载体授予云中服务、操作和资源的访问权限。用户可以将角色关联到云服务器实例。为实例绑定角色后，将具备以下功能及优势：

可使用 STS 临时密钥访问云上其他服务
可为不同的实例赋予包含不同授权策略的角色，使实例对不同的云资源具有不同的访问权限，实现更精细粒度的权限控制
无需自行在实例中保存 SecretKey，通过修改角色的授权即可变更权限，快捷地维护实例所拥有的访问权限

具体的操作流程如下：

在将角色成功绑定实例后，用户可以在实例上访问元数据服务来查询此角色的临时凭据，并使用获得的临时凭据操作该角色权限下的云服务 API 接口。

02 针对元数据服务的攻击

接下来我们将介绍下针对元数据服务的一些常见的攻击模式。攻击者可以首先通过目标实例上的 SSRF 漏洞获取与实例绑定的角色名称（rolename）。攻击者可以构造访问元数据接口的 payload，并通过存在 SSRF 漏洞的参数传递：

http://x.x.x.x/?url=http://169.254.169.254/latest/meta-data/iam/info

在获取到角色名称后，攻击者可以继续通过 SSRF 漏洞获取角色的临时凭证：

http://x.x.x.x/url=http://169.254.169.254/latest/metadata/iam/security-credentials/<rolename>

获取角色临时凭据的案例可参见下图:

从上图可见，攻击者可以获取角色的 TmpSecretID 以及 TmpSecretKey。

在攻击者成功获取角色的临时凭据后，将会检查获取到的角色临时凭据的权限策略。

有的时候，可以通过获取到的角色名称，来猜测该角色的权限策略，例如角色名为：TKE_XXX，则这个角色很大可能是拥有操作 TKE 容器服务的权限。

此外，如果获取的临时密钥拥有查询访问管理接口的权限，攻击者可以通过访问“访问管理”API 来准确获取的角色权限策略。可以通过如下几种方式判断获取角色的权限策略：

1、通过使用临时 API 凭据访问“获取角色绑定的策略列表”API 接口，见下图：

从上图可见，攻击者获取到的与实例绑定的角色的临时凭据权限策略是“AdministratorAccess”,这个策略允许管理账户内所有用户及其权限、财务相关的信息、云服务资产。

2、通过使用临时 API 凭据访问“获取角色详情”API 接口，见下图：

通过查询的返回结果可以见，角色的权限策略为 AssumeRole。

在弄清楚窃取的凭据所拥有的权限后，攻击者便可以通过凭据的权限制定后续的攻击流程。

但在开始后续的攻击阶段之前，攻击者会先判断当前权限是否可以获取目标的数据资源。

在所有云资源中，攻击者们往往对目标的数据更加感兴趣。如果攻击者获取的密钥拥有云数据库服务或云存储服务等服务的操作权限，攻击者将会尝试窃取目标数据。

临时凭据同样也可以帮助攻击者们在目标实例中执行指令并控制实例权限。

与通过密钥构造请求这种方式发起攻击相比，攻击者们在实战中更倾向于使用云命令行工具来进行攻击。

云服务厂商为用户提供了相应的云命令行工具以管理云服务，例如腾讯云提供的 TCCLI 工具、AWS 的 AWSCLI 工具。攻击者可以通过在云命令行工具中配置窃取到的 API 密钥来对云资源进行调用。与构造请求访问云 API 接口这种方式相比，使用云命令行工具将会给攻击者带来更多便捷。

在使用云命令行工具之前，应先配置 API 密钥，以 AWSCLI 工具配置举例，可以将：

攻击者将窃取来的 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKEN 配置完成后，可以使用云命令行工具在目标实例上执行命令。

在配置好密钥后，攻击者可以尝试使用如下图命令通过 AWSCLI 在实例中运行 bash 脚本以获取实例控制权限。

借助通过元数据服务窃取到的凭据以及 AWSCLI 所提供的功能,攻击者可以在实例中执行反弹 shell 命令，由此进入实例。

除此之外，攻击者还可以选择修改 userdata，将反弹 shell 写入 userdata 中后将实例重启，从而控制实例。

Userdata 涉及到云厂商提供的一种功能，这项功能允许用户自定义配置在实例启动时执行的脚本的内容。

通过这一功能，攻击者可以尝试在实例的 userdata 中写入恶意代码，这些代码将会在实例每次启动时自动执行。

以 AWS 举例，攻击者可以将恶意代码写入 my_script.txt 文件中，然后执行如下指令将 my_script.txt 文件中内容导入 userdata 中。

随后，攻击者通过如下命令重启实例：

当实例重启时，userdata 中的恶意代码将会被执行。

攻击者除了可以使用临时凭据获取实例的控制权限，通过元数据服务窃取到的拥有一定权限的角色临时凭据在持久化阶段也发挥着作用。攻击者尝试使用通过元数据服务获取的临时凭据进行持久化操作，确保能够持续拥有访问权限，以防被发现后强行终止攻击行为。

使用临时凭据进行持久化的方式有很多，比如说在上文中所提及的在 userdata 中写入恶意代码这项攻击技术，也是可以运用在持久化阶段：通过在实例的 userdata 中写入恶意代码，这些代码将会在实例每次启动时自动执行。这将很好的完成持久化操作而不易被发现。

除此之外，攻击者还可以尝试在账户中创建一个新的用户以进行持久化，以 AWSCLI 举例，攻击者可以通过 awsiam create-user --user-name Bob 为账户新建一个名为 Bob 的用户

随后使用 awsiam create-access-key --user-name Bob 指令为 Bob 用户创建凭据

虽然这个方法操作简单且有效，但是账户里突然新增的用户及其容易被察觉，因此并不是一个特别有效的持久化方式。

此外，攻击者还会使用一种常见的持久化手法，那就是给现有的用户分配额外的密钥。以针对 AWS 的攻击来说，攻击者可以使用 aws_pwn 这款工具来完成这项攻击，aws_pwn 地址如下：

https://github.com/dagrz/aws_pwn

aws_pwn 提供了多项技术以供攻击者可以完成针对 aw 的持久化攻击，关于 aws_pwn 所提供的持久化功能可见下图：

通过元数据服务窃取也可以被攻击者应用于横向移动操作。攻击者可以通过元数据服务窃取角色的临时凭据横向移动到角色对应权限的资源上。除此之外，攻击者会在所控制的实例上寻找配置文件，并通过配置文件中的配置项中获取其他资源的访问方式以及访问凭据。

攻击者在横向移动的过程中，获取到可以操作云数据库或存储服务必要权限的密钥或是登录凭据后，攻击者就可以访问这些服务并尝试将其中的用户数据复制到攻击者的本地机器上。

以 AWSCLI 为例，攻击者可以通过如下命令将 s3 存储桶中的内容同步到本地

仍然以上文提及的 CapitalOne 银行数据泄露事件举例，攻击者使用获取到的角色临时凭据，多次执行“awss3 ls”命令，获取 CapitalOne 账户的存储桶的完整列表；

接着攻击者使用 sync 命令将近 30 GB 的 Capital One 用户数据复制到了攻击者本地。

总的来说，元数据服务为云上安全带来了极大的安全挑战，攻击者在通过 SSRF 等漏洞获取到实例绑定的角色的临时凭据后，将会将其应用于云上攻击的各个阶段。通过破坏用户系统，滥用用户资源、加密用户资源并进行勒索等手段影响用户环境正常使用。

03 元数据安全性改进

以 AWS 为例，AWS 为了解决元数据服务在 SSRF 攻击面前暴露出的安全性问题，引入 IMDSv2 来改善其总体安全情况。

在 IMDSv2 中，如果用户想访问元数据服务，首先需要在实例内部向 IMDSv2 发送一个 HTTPPUT 请求来启动会话，示例如下：

X-aws-ec2-metadata-token-ttl-seconds 用于指定生存时间（TTL）值（以秒为单位），上文中生成的 token 有效期为 6 小时（21600 秒），在 IMDSv2 中 21600 秒是允许的最大 TTL 值。此请求将会返回一个 token，后续访问元数据服务，需要在 HTTPheader 中携带此 token，见如下请求：

完整流程如下：

TOKEN=`curl-X PUT "http://169.254.169.254/latest/api/token" -H"X-aws-ec2-metadata-token-ttl-seconds: 21600"

curlhttp://169.254.169.254/latest/meta-data/profile -H“X-aws-ec2-metadata-token: $TOKEN”

流程图如下:

pexels-pixabay-459654.jpg

可见，在采用 IMDSv2 时，即使实例中应用存在 SSRF 漏洞，攻击者也无法轻易的利用 SSRF 漏洞向元数据服务发出 PUT 请求来获取 token，在没有 token 的情况下，攻击者并不能访问元数据服务，也就无法获取角色的临时凭据进行后续的攻击行为。

除了使用 PUT 启动请求这项安全策略之外，IMDSv2 还引入了如下两个机制保证元数据服务的安全：

不允许 X-Forwarded-For 标头：如果攻击者通过反向代理的方式的确可以绕过 PUT 限制，但是，通过代理传递的请求将包含“ X-Forwarded-For”标头。这样的请求被 IMDSv2 拒绝，并且不发行令牌。
IP 数据包 TTL 设置为“ 1”：TTL 指定数据包被路由器丢弃之前允许通过的最大网段数量，是 IP 数据包在网络中可以转发的最大跳数(跃点数),将其值设置为 1 可确保包含机密令牌的 HTTP 响应不会在实例外部传播。即使攻击者能够绕过所有其他保护措施，这也将确保令牌不会在实例外部传播，并且一旦数据包离开实例，数据包将被丢弃。

值得注意的是，AWS 认为现有的实例元数据服务（IMDSv1）是完全安全的，因此将继续支持它。如果不执行任何操作，则 IMDSv1 和 IMDSv2 都可用于 EC2 实例。这就是说，在不主动禁用 IMDSv1 的情况下，实例仍存在着安全隐患。

04 元数据服务更多安全隐患

IMDSv2 方案的确可以有效的保护存在 SSRF 漏洞的实例，使其元数据不被攻击者访问。但是这项技术可以完美的保护元数据、保护租户的云业务安全吗？答案是不能。

设想一下：当攻击者通过其他漏洞（例如 RCE 漏洞）获取实例的控制权之后，IMDSv2 的安全机制将变得形同虚设。攻击者可以在实例上发送 PUT 请求获取 token，随后利用获得的 token 获取角色临时凭据，最后利用角色临时凭据访问角色绑定的一切云业务，具体流程见下图：