共计 4502 个字符，预计需要花费 12 分钟才能阅读完成。
文章首发于：前线 Zone- 云平安社区
作者：高瑞强
高瑞强，腾讯平安云鼎实验室，目前从事云上攻防平安相干的钻研工作。
明天分享的主题是《Cloud RedTeam 视角下元数据服务攻防实际》。
纵观云上的攻打事件，以及近期的一些热点事件，大家不难发现，元数据服务攻打事件频繁的产生。在云产业一直发展壮大的当今，元数据服务曾经成为了攻击者攻打流程中的一个重要的环节。咱们从攻击者的视角来分析攻击流程中元数据服务所面临的危险，也能够更好地迎战元数据服务带来的平安挑战。
明天分享的议题由四个局部组成。
元数据服务概览
安全事件回顾
针对元数据服务攻打
ATT&CK 矩阵和元数据服务
给大家简略举一个例子，介绍一下什么叫做云服务器实例元数据。大家能够构想一下，在租用云厂商所提供的云服务器服务后，首先须要选购机型、选购地区、选购配置的时长或者是计费形式，当购买胜利之后，就会为用户生成一个云服务器的实例。
这个实例有本人的属性，常见的能够举例，实例 ID 它本身绑定了一些角色信息，也会有一些平安组信息的绑定状况，包含大家日常可见的实例，本身有内网 IP、外网 IP、地区信息，这些就是咱们所说的云服务器实例的元数据。
那元数据是怎么查问或者应用的呢？用户能够通过元数据服务接口，在运行的实例内查问实例的元数据。具体是在云服务器实例的接口上，通过元数据服务查问的申请来查问相应的元数据相干的数据。
在这些实例的属性中，从攻击者的角度来看，最关怀的便是与实例绑定的角色。
角色是云厂商所提供拜访治理中的一个功能模块，能够应用拜访治理性能中能够新建一个角色，用这个角色来治理这些或者说进行受权、进行操纵这些云资源。
各个云厂商提供角色性能，能够细粒度化的管制配置。在为这个角色配置权限之后，能够将这个角色绑定在云服务器实例上，而后在云服务器实例中就能够用到这个角色，通过它的长期凭据，来操作这个云服务。
也就是图上的流程图，其实就是创立角色，配置权限以及绑定实例。同理，如果用户想应用这个元数据的角色信息，它能够简略的在本人的这台实例上，通过元数据服务接口查问即可。
那么一些市面上比拟常见的云厂商，它的元数据服务接口地址到底是什么样子的？
aws 地址：
http://169.254.169.254/latest…
Google Cloud 地址：
http://metadata/computeMetada…
Azure 地址：
http://169.254.169.254/metada…
Oracle Cloud 地址：
http://169.254.169.254/opc/v1…
这个地址的学名叫做链路本地地址，链路本地地址又称连结本地位址，是计算机网络中一类非凡的地址，它仅供于在网段，或播送域中的主机互相通信应用；这类主机通常不须要内部互联网服务，仅有主机间互相通信的需要。链路本地地址在 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://16… 网站上它存在一个 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 下的平安危险，平台测他其实还有更危险的一个平安危险，如果这个平台测没有配置好，这个角色的权限将会导致一个什么问题？
比如说平台测的产品，它的性能特地弱小，它可能会应用云服务器、对象存储、容器服务等一系列的云上服务，那他的角色的权限将会领有如下的这些服务的权限，攻击者获取到这个角色之后，能够轻松的操作，或者说管制这些云资产，而且能够将攻击面间接扩散到其余产品中。
大家能够看到下面图片，这个是云鼎实验室推出的云平安攻防矩阵，在攻防矩阵的阶段中，可能会呈现到方才给大家介绍的实例元数据服务的利用状况，相当于一个技术攻打，纵观整个矩阵，能够发现云服务器的元数据服务，也是攻击者所罕用的攻打切入点。
云原生平安攻防全景图，这个攻防全景图从五个大部分来形容了一下云原生的平安攻防的一个场景。次要是从容器基础设施、云原生利用平安、云原生平安工具、云厂商产品安全危险、容器编排平台的攻防技术来形容的。
