Cloud RedTeam 视角下元数据服务攻防实践

文章首发于：火线 Zone-云安全社区​zone.huoxian.cn/

作者：高瑞强

高瑞强，腾讯安全云鼎实验室，目前从事云上攻防安全相关的研究工作。

今天分享的主题是《Cloud RedTeam 视角下元数据服务攻防实践》。

纵观云上的攻击事件，以及近期的一些热点事件，大家不难发现，元数据服务攻击事件频繁的发生。在云产业不断发展壮大的当今，元数据服务已经成为了攻击者攻击流程中的一个重要的环节。我们从攻击者的视角来分析攻击流程中元数据服务所面临的风险，也可以更好地迎战元数据服务带来的安全挑战。

今天分享的议题由四个部分组成。

1. 元数据服务概览

2. 安全事件回顾

3. 针对元数据服务攻击

4. ATT&CK 矩阵和元数据服务

给大家简单举一个例子，介绍一下什么叫做云服务器实例元数据。大家可以设想一下，在租用云厂商所提供的云服务器服务后，首先需要选购机型、选购地区、选购配置的时长或者是计费方式，当购买成功之后，就会为用户生成一个云服务器的实例。

这个实例有自己的属性，常见的可以举例，实例 ID 它自身绑定了一些角色信息，也会有一些安全组信息的绑定情况，包括大家日常可见的实例，自身有内网 IP、外网 IP、地域信息，这些就是我们所说的云服务器实例的元数据。

那元数据是怎么查询或者使用的呢？用户可以通过元数据服务接口，在运行的实例内查询实例的元数据。具体是在云服务器实例的接口上，通过元数据服务查询的请求来查询相应的元数据相关的数据。

在这些实例的属性中，从攻击者的角度来看，最关心的便是与实例绑定的角色。

角色是云厂商所提供访问管理中的一个功能模块，可以使用访问管理功能中可以新建一个角色，用这个角色来管理这些或者说进行授权、进行操纵这些云资源。

各个云厂商提供角色功能，可以细粒度化的控制配置。在为这个角色配置权限之后，可以将这个角色绑定在云服务器实例上，然后在云服务器实例中就可以用到这个角色，通过它的临时凭据，来操作这个云服务。

也就是图上的流程图，其实就是创建角色，配置权限以及绑定实例。同理，如果用户想使用这个元数据的角色信息，它可以简单的在自己的这台实例上，通过元数据服务接口查询即可。

那么一些市面上比较常见的云厂商，它的元数据服务接口地址到底是什么样子的？

aws 地址：

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

Google Cloud 地址： 

http://metadata/computeMetadata/v1/

Azure 地址： 

http://169.254.169.254/metadata/instance?api-version=2017-04-02

Oracle Cloud 地址： 

http://169.254.169.254/opc/v1/instance/

这个地址的学名叫做链路本地地址，链路本地地址又称连结本地位址，是计算机网络中一类特殊的地址，它仅供于在网段，或广播域中的主机相互通信使用；这类主机通常不需要外部互联网服务，仅有主机间相互通讯的需求。链路本地地址在 IPv4 链路本地地址定义在 169.254.0.0/16 这个地址块，因此大家看到所涉及的这些云厂商，地址都是链路本地地址。

为什么要选用这个链路本地地址作为元数据服务接口提供的地址？

它的特性有点如下，实例元数据服务使用链路本地地址提供服务；当实例向元数据服务发起请求时，该请求不会通过网络传输，也永远不会离开这一台计算机；基于这个原理，元数据服务理论上只能从实例内部访问。

但是从这个攻击事件上来看，其实数据是有可能被泄露出去的。具体怎么泄露的，一起来看一个历史上的经典案例。

大约在 2019 年的时候，美国的 Capital One 银行发生了一起相当严重的数据泄露事件，北美大约有 1 亿人受到了这次事件的影响，上亿条信用卡数据、十余万社保号码被泄露出来。

这个事件，不仅给这个银行的用户带来了沉重的打击，也给银行自身带来了相当严重的影响，银行的股价在收盘的时候下跌了 5.9%，在两周之内下跌了 15%。

攻击者发现，Capital One 银行的 web 应用部署于 AWS 云服务器上。此外，攻击者发现 Capital One 应用程序中存在了一个 SSRF 漏洞。

如果在传统的攻防中，如果一个应用存在 SSRF 漏洞，虽然漏洞比较严重，但是也并不会产生如此严重的影响。这个就是传统漏洞与云上结合所带来的更深远的影响。

攻击者通过 SSRF 漏洞发起了内网请求，然后成功地访问到了这台云服务器实例上的元数据服务接口，并且它通过这个接口成功地读到了一个角色，并且通过这个角色拿到了这个角色的临时凭据。

这个角色就是 Capital One 银行在云服务器上部署了他的代码，它很有可能也租用了亚马逊云的对象存储服务，就是所谓的 aws 存储桶，然后他把用户数据存在了亚马逊云的存储桶中。

这就导致一个问题，攻击者拿到的这个角色，恰恰是 Capital One 银行的应用程序，用来调用他在亚马逊云上的对象存储的角色。因此，攻击者把这个历史凭据保存到了本地，并且成功的把存储桶中所有的用户数据复制下载到本地，造成了一个相当严重的影响。

元数据服务风险，它存在于两个方面，一个是平台侧、一个是用户侧。

针对于用户侧的攻击，攻击者通过目标部署在云服务器实例上的应用程序的漏洞。比如说 SSRF、RCE、任意文件读取等漏洞。通过这些漏洞来访问服务器的元数据服务接口，并且获得相应的数据用以后续的攻击。

细化介绍一下常见的攻击者所采用的攻击流程。

步骤一：获取利用点。攻击者会使用一些常规的漏洞探测方式，比如漏洞扫描、手动测试这些方式，发现部署在云上应用中的脆弱点。

步骤二：攻击者发现了这个脆弱点之后，他将会尝试访问云上的元数据服务接口，如果一旦发现这个元数据服务接口是可以访问的，他将会尝试获取与实例绑定的角色名称。

我们这里以 SSRF 漏洞进行举例，看看攻击者是如何通过 SSRF 漏洞获取到与实例绑定的角色名称。

我们假设http://x.x.x.x/?url=http://169.254.169.254/latest/meta-data/iam/info 网站上它存在一个 SSRF 漏洞，并且有回显，它存在 url 参数，后面我们构造一个 payload 来访问这个元数据服务，并且通过这个地址获取角色名称。

步骤三：当获取角色名称之后，我们通过名称信息进一步的获取角色的临时凭据，攻击者可以继续通过 SSRF 漏洞来访问元数据服务接口，获取角色历史凭据，通过的 payload 跟上一个获得的角色名称很类似，但是这里是相当于我们把角色名称传入来获取此角色的历史凭据。如图所见，这个历史凭据，也可以成功的返回回来。

这里临时凭据，他有个特点，一般都会是 TmpSecretld 或者 TmpSecretKey，而且他一般都跟着一个 token，为什么大家的主凭据没有 token 而历史凭据有 token？

因为主凭据相当于是拥有这个账号的所有权，等同于你的账号权限，但是临时凭据，他需要标识这条凭据的存活时间、权限策略，所以说它有一个 token 用来标识凭据的这些信息。

步骤四：在获取到角色的名字、角色的临时凭据了，还需要猜测一下，或者说来确定一下这个角色，他的权限策略是什么？也通过这个权限策略制定后续的攻击行为，我们怎么获得角色的权限策略？有两个比较常见的方式。

方式 1：通过名称初步猜测角色用途。比如说一个业务，他应用到角色来访问存储桶，他很有可能为角色命名和存储桶相关的名字，比如说他用这个角色来操作云服务器，它可能会为这个角色命名一个跟云服务器比较关联的名字，方便后续的管理和使用。

方式 2：通过“访问管理”API 接口获取角色详情。但是有个前提，这个角色他的权限是可以操作访问管理的权限，才可以进行这一步的操作。

步骤五：在搞清楚角色用途后，可以进行凭据后的后利用，根据角色的权限不同，可以攻击对象存储服务、攻击云服务器实例、攻击访问管理等等。

接下来，举几个案例具体看一下。

第一个案例：窃取存储桶中的用户数据。在所有的云资源中，攻击者往往对目标的数据更加感兴趣，如果攻击者获取的临时凭据拥有云数据库服务或云存储服务等服务的操作权限，攻击者将会尝试窃取目标数据 。

具体可以怎么做？还是以亚马逊云举例子，AWS 其实提供了相应的一些命令行工具，或者说一些可视化工具用来简化操作，攻击者就可以借用这些工具配置临时凭据，并且利用存储桶工具将存储桶的内容下载到本地。

Capital One 银行的数据泄露案例，后续官方调查取证的时候，发现攻击者用的就是这个思路。

第二个案例：在云服务器实例中运行命令。借助通过元数据服务接口窃取到的凭据，借助 AWS CLI 所提供的命令行工具，攻击者可以在实例中执行反弹 shell 命令，由此进入实例。

参考上图，比如说在这个参数中配置好凭据，或者在参数中直接执行命令。

第三个案例：在云服务器实例中写入后门。这个步骤其实是在攻击阶段中的持久化阶段很有效果。云服务商一般会提供一个叫 userdate 的字段，或者说一个功能，其实这个功能是为了方便使用者在 Windows 实例也好，Linux 实例也好，在它开机启动的时候加载用户的脚本，然后攻击者可以通过将 userdata 中写入后门，然后当实例下次重启的时候，你到后门就可以生效，或者说就进行持久化操作。

第四个案例：利用访问管理创建新用户。还是通过这个凭据，我们可以通过访问管理的功能，创建一个用户，命名为 Bob，并且为 Bob 创建一个权限策略，比如说他拥有管理员权限，并且复制 Bob 上，但是这个攻击他会有一个前提，就是你获取的临时凭据，获取的角色，他必须有相应的访问管理的权限才可以操作。

介绍完这个用户侧的一些风险，我们接下来看产品测的一些风险，云产品中也会应用到元数据服务。因此，元数据安全挑战也会被带入到云产品中。

举一个比较有代表性的案例，Web 应用托管服务，Web 应用托管服务是一种常见的平台即服务产品，可以用来运行并管理 web 类、移动类和 API 类的应用程序。

还是以亚马逊云举例，Web 应用托管服务可以让用户将 Web 应用直接上传到托管服务中，当代码上传到托管服务中，Web 托管服务将用户代码存储到对象存储服务中。

所以说与之前的攻击流程相似，攻击者也是可以利用 SSRF 漏洞，访问到云服务器，通过云服务器获取到相应的元数据，并且通过拿到的对象存储的角色，以及对象存储的权限来访问存储桶。

我们再看平台测更多的安全风险，除了给大家介绍的 aws 下的安全风险，平台测他其实还有更危险的一个安全风险，如果这个平台测没有配置好，这个角色的权限将会导致一个什么问题？

比如说平台测的产品，它的功能特别强大，它可能会使用云服务器、对象存储、容器服务等一系列的云上服务，那他的角色的权限将会拥有如下的这些服务的权限，攻击者获取到这个角色之后，可以轻松的操作，或者说控制这些云资产，而且可以将攻击面直接扩散到其他产品中。

云鼎实验室推出的云安全攻防矩阵，在攻防矩阵的阶段中，可能会出现到刚才给大家介绍的实例元数据服务的利用情况，相当于一个技术攻击，纵观整个矩阵，可以发现云服务器的元数据服务，也是攻击者所常用的攻击切入点。

云原生安全攻防全景图，这个攻防全景图从五个大部分来描述了一下云原生的安全攻防的一个场景。主要是从容器基础设施、云原生应用安全、云原生安全工具、云厂商产品安全风险、容器编排平台的攻防技术来描述的。