作者：ruiqiang

前言

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

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

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

(Capital One信息泄露事件攻击原理图)

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

元数据服务以及角色介绍

元数据服务

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

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

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

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

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

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

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

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

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

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

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

访问管理角色

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

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

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

具体的操作流程如下：

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

针对元数据服务的攻击

接下来我们将介绍下针对元数据服务的一些常见的攻击模式。攻击者可以首先通过目标实例上的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的AWS CLI工具。攻击者可以通过在云命令行工具中配置窃取到的API密钥来对云资源进行调用。与构造请求访问云API接口这种方式相比，使用云命令行工具将会给攻击者带来更多便捷。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://github.com/dagrz/aws_pwn

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

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

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

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

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

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

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

元数据安全性改进

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

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

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

完整流程如下：

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

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

流程图如下:

可见，在采用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的情况下，实例仍存在着安全隐患。

元数据服务更多安全隐患

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

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

总之，当攻击者通过RCE漏洞获取实例控制权后，可以通过元数据服务获取到的临时凭据进行横向移动。鉴于云厂商产品API功能的强大性，在获取角色临时凭据后，可能造成及其严重的影响

值得注意的是，如果在云平台控制台中执行一些高危行为，平台默认都会需要进行手机验证。但通过使用临时凭据调用发送请求调用API接口，并不需要手机验证码，可以绕过这项安全检测。

参考文献

1. https://aws.amazon.com/cn/blogs/china/talking-about-the-metadata-protection-on-the-instance-from-the-data-leakage-of-capital-one/
2. https://medium.com/@shurmajee/aws-enhances-metadata-service-security-with-imdsv2-b5d4b238454b
3. https://web.mit.edu/smadnick/www/wp/2020-07.pdf
4. https://github.com/dagrz/aws_pwn
5. https://docs.aws.amazon.com/zh_cn/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-sync
6. https://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/id_users_create.html
7. https://rhinosecuritylabs.com/cloud-security/aws-security-vulnerabilities-perspective/