嗨,大家好!这是我最近发现的一系列安全漏洞当中的一个,该漏洞与印度最赚钱的电子商务公司的一个数据库有关。下面让我们回顾下这个完整的故事。

注:这是在有关公司的授权许可下完成的!任何未经授权的行为,都属于违法行为!

这应该是一次有针对性的渗透,本人专注于LFI(本地文件包含)漏洞搜寻,所以我很热衷与文件交互相关的功能和端点。一个常见的用于下载App的“Android Google Play”和“iPhone App store”选项功能引起了我的注意。

从SSRF到最终获取AWS S3 Bucket访问权限的实际案例

当我点击它时,它将我重定向到了另一个页面,其链接地址如下 - 

从SSRF到最终获取AWS S3 Bucket访问权限的实际案例

接着又立即重定向到之前引用的页面,当我在隐身窗口中打开它查看没有引用页面时的响应是什么时,它被重定向到了一个404页面,因此很明显它正在寻找某些条件和参数,然后进行简单的if/else逻辑判断。为了查看是否有任何缺失的参数,我偶然发现了页面的以下HTML代码 - 

从SSRF到最终获取AWS S3 Bucket访问权限的实际案例

逻辑非常清晰,正如你在红色框中看到的,有一个php文件“download_handler.php”在URL中缺少,需要参数“path”作为finaldownloadlink以及“name”的URL名称,这就是没有下载任何内容的原因。所以最终的URL应该是 -

downloadcallback/download_handler.php?path=

我尝试了目录遍历攻击(../../../../etc/passwd),非常幸运文件几乎都给了最大权限(一个常见错误:/),我能够读取/etc/passwd文件以及各种其它文件中的内容 -

从SSRF到最终获取AWS S3 Bucket访问权限的实际案例

从SSRF到最终获取AWS S3 Bucket访问权限的实际案例

我能够读取各种Linux系统文件,配置,访问日志,并获取get参数中的用户访问令牌以及其它更为敏感的信息。导致这个漏洞的罪魁祸首是“download_handler.php” -

从SSRF到最终获取AWS S3 Bucket访问权限的实际案例

PHP文件只是将该文件作为输入并将其读取回客户端。很容易可以看出它应该也非常容易受到SSRF的攻击 -

从SSRF到最终获取AWS S3 Bucket访问权限的实际案例

尝试使用不同的URL schemas(file:/// , dict:// , ftp:// and gopher://)读取 /etc/password,你也可以使用file:/// scheme执行相同操作 -

从SSRF到最终获取AWS S3 Bucket访问权限的实际案例

早些时候,当我通过LFI攻击抓取敏感文件时,我碰巧读取了/etc/motd文件,该文件表明该应用程序是通过AWS ElasticBeanstalk部署的。

从SSRF到最终获取AWS S3 Bucket访问权限的实际案例

这也让我决定继续通过SSRF搜索AWS实例元数据和用户数据 -

从SSRF到最终获取AWS S3 Bucket访问权限的实际案例

从SSRF到最终获取AWS S3 Bucket访问权限的实际案例

我还能够从以下API中检索AWS账户ID和Region -

http://169.254.169.254/latest/dynamic/instance-identity/document

从SSRF到最终获取AWS S3 Bucket访问权限的实际案例

当我读取AWS Elastic Beanstalk时,我遇到了一个API调用,它可以获取AWS Access Key,Secret Access Key和Token。

http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanstalk-ec2-role

我很快通过SSRF 进行了调用,我能够获取他们的AWS Access key,ID,token,在此之前我也获得了他们的帐户ID,这表明相比之前漏洞变得更加严重了 -

从SSRF到最终获取AWS S3 Bucket访问权限的实际案例

现在是时候对AWS账户进行身份验证了。为了确保凭证没有过期,我配置了aws-cli试图列出并将S3 bucket数据下载到我的本地机器上 -

从SSRF到最终获取AWS S3 Bucket访问权限的实际案例

将s3 bucket内容复制到本地机器 -

从SSRF到最终获取AWS S3 Bucket访问权限的实际案例

在查看每个单独的S3 bucket时,在一些bucket中我发现了一些关键文件,例如database.js,config.js,app.js,payment.config。这些文件很快引起了我的注意。正如我所料,其中包含了支付hash key和salt(可用于篡改订单的支付),多个数据库凭据,一些内部工具用户名和密码等信息。还有一个正在运行的MongoDB实例,其凭据可在配置文件的纯文本中找到,当我尝试连接到它时,我发现他们的客户数据也存储在其中 - 

从SSRF到最终获取AWS S3 Bucket访问权限的实际案例

虽然它没有包含所有用户的详细信息,但其中已包含的数据量超过了10000条。随后我立即向他们报告了这个漏洞,他们积极并迅速的进行了修复。感谢阅读!

*参考来源:medium,FB小编secist编译,转自FreeBuf