记录一次平平无奇的云上攻防过程

点击蓝字

关注我们

由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，狼组安全团队以及文章作者不为此承担任何责任。

狼组安全团队有对此文章的修改和解释权。如欲转载或传播此文章，必须保证此文章的完整性，包括版权声明等全部内容。未经狼组安全团队允许，不得任意修改或者增减此文章内容，不得以任何方式将其用于商业目的。

• 文中数据的值都是虚构的内容，非真实场景里的数据。
• 文中使用的 CF 工具版本为 v0.4.0，如果读者有在使用 CF，为避免版本不同导致命令不一致的情况，请以 CF 使用手册里的命令为准，CF 使用手册地址：wiki.teamssix.com/cf

首先找到目标的微信小程序，反编译小程序找到了硬编码在源码里的 Access Key

将 Access Key 配置到 CF 云环境利用框架里，CF 项目地址：github.com/teamssix/cf

cf config

尝试列出一下当前访问凭证的资源，因为输出内容较多，这里仅展示了一部分，再次提醒一下，本文图片中数据的值都是虚构内容，非真实场景里的数据。

cf alibaba ls

最终通过 CF 列出这个 AK 里有 2 个存储桶以及 30 多台云服务主机，不过里面有一台是关机的。

先来看这两个存储桶，在第一个存储桶 teamssix-api-example 里有 500 多 M 的数据，在存储桶体积比较少的情况下，可以直接使用 cf alibaba oss obj get 命令下载存储桶里的所有对象，但这里存储桶体积比较大，还是用 OSS Browser 大概预览下吧。

用 OSS Browser 打开第一个存储桶，翻了一遍，没有发现太多敏感的信息，然后继续打开第二个存储桶，发现在第二个存储桶里存储了大量的身份证信息。

在 OSS Browser 里没办法看到这些文件的总数，好在 CF 的输出结果里可以看到存储桶的文件总数。

从 CF 的输出结果来看这个存储桶总共有 345 w 条数据，从 OSS Browser 列出的结果来看，估计这三百多万条的数据应该都是身份证照片之类的信息了。

刚才通过 CF 发现了 30 多台云服务主机，这里先看看 CF 能对云主机执行哪些操作。

cf alibaba ecs exec -h

在写报告的时候需要有服务器权限证明的截图，这里可以直接使用 CF 一键执行三要素，方便写报告。

cf alibaba ecs exec -b

接下来打算翻翻实例，看看能不能发现什么有用的信息，后来在一个实例的命令历史记录里发现了 MySQL 数据库的明文密码。

cf alibaba ecs exec -i i-abcdefghijklmn33 -c "cat ~/.bash_history | grep mysql"

连接到数据库后，开始翻数据库，翻着翻着，在一张表里发现好东西，这张表存储了目标一千多万条敏感数据。

再后来，在其他的实例中还发现了一些容器，包括 ES 、Redis 数据库的容器，不过里面数据量没有太多。

到这里，通过这个 AK 已经拿到了目标一千多万条数据库敏感信息、三百多万条身份证照片信息以及三十多台服务器 root 权限。

报告交上去后，给的分数也很可观，不过这里因为不通靶标，所以只能搞点数据分和权限分了。

总的来说，整个过程没有太大的波澜，这里主要是利用了两处目标的风险点：

1. 云服务的 Access Key 直接硬编码到了小程序里
2. Access Key 权限没有做好控制

解决起来也很简单：

1. 小程序里不要硬编码 Access Key，建议可以用临时密钥啥的
2. 这里的 Access Key 应该是只需要 OSS 的权限，ECS 的权限就不应该再赋予给这个 AK 了

最后，如果师傅感觉 CF 这个工具还不错，记得给个 Star 呀 ~，CF 项目地址：github.com/teamssix/cf

TeamsSix

扫描关注公众号回复加群

和师傅们一起讨论研究~

长

按

关

注

WgpSec狼组安全团队

微信号：wgpsec

Twitter：@wgpsec