对印度某电子商务公司从LFI到数据库获取的渗透测试过程

本文分享的是作者在渗透测试过程中，通过不同漏洞的组合利用，最终拿下印度某大型电子商务公司数据库权限。（文章已经相关公司许可发布）

从LFI漏洞入手

本次渗透测试的目标比较确定，最初我偏向去发现其中的本地文件包含漏洞（LFI），所以我着重对其中的文件交互功能和特性进行了深入的测试分析，很巧的是，我发现了该公司一个针对不同移动设备显示 “Android Google play” 和 “iPhone App store” 的自身APP下载页面，如下：

当我点击页面中 “Android Google play” 和 “iPhone App store”任意一个按钮，之后就会跳到如下的页面： http://www.xxxx.com/downloadcallback/null ：

接着，就会马上重定向到相应的APP下载引用页面（Referrer Page）。当我在浏览器隐身模式下把引用页面去掉，想看看有什么反应时，请求服务端后返回了一个“404 Page not found” 的响应，很明显，它查询了某些条件或请求参数，可能遵循了某种简单的if/else逻辑。为了详细查看是否有其它参数遗漏，我看到了页面中的以下HTML源码：

以上代码中的逻辑已经很明显了，有意思的是，在红框标注内可以发现有一个名为“download_handler.php”的 PHP 文件，在点击首次跳转时出现的URL中 – http://www.xxxx.com/downloadcallback/null ，这个PHP文件是不存在的，然而这个PHP文件请求的是一个“path”的路径参数，其路径URL如代码中描述的finaldownloadlink，其“name” 名称为nameURL。所以，去掉引用页面后，最终也就返回了“404 Page not found”没东西下载的响应了。如果按照上述HTML代码的规定，那么其final URL应该是这种样子的：

downloadcallback/download_handler.php?path=

于是，在该处我偶然地尝试了一下目录遍历攻击，path=../../../../etc/passwd，哇，竟然有读写权限，除了/etc/passwd，还能读取到其它服务端敏感文件：

而且，我还可以读取到各种 Linux 系统文件、配置文件和访问日志信息，这样一来，还能深入获取到用户的access token、参数和其它更敏感的信息，这一切的罪魁祸首就是“download_handler.php”这个文件：

转化为SSRF攻击

可知，这个PHP文件只是简单地执行用户请求输入，然后把输入请求的响应返回，这种模式也很容易存在SSRF漏洞，比如：

这里，读取/etc/password的方式，还能用file:/// 方式（打开对应的本地系统文件）：

发现AWS ElasticBeanstalk实例

另外，当我用这种LFI和SSRF方式测试时，在读取服务器端/etc/motd文件（系统布告信息栏）时，我发现这个Linux系统部署了AWS ElasticBeanstalk：

这个线索让我有了深入渗透的决心，我们可以用上述SSRF方式来具体找找一些AWS实例，如MetaData或User Data：

利用上述SSRF方式，从“ http://169.254.169.254/latest/dynamic/instance-identity/document ”的系统服务API中，还可获取到一些AWS账号ID和云服务区域信息，如下：

在我检查系统的AWS Elastic Beanstalk部署环境时，还发现了一个API调用，用它可以获取到AWS Access Key、Secret Access Key和Token等重要的验证信息，这个API是：

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

直接用上述的SSRF方式，加上这个API调用，在响应信息中就能返回AWS Access Key、Secret Access Key和Token，结合之前发现的账户ID，现在的情况是越来越严重了：

接下来，我们可以来验证一下这些AWS账户了，只要密码不过期，就可以在aws-cli命令行界面中来进行操作了，如下：

也可以列出相关信息或下载S3 bucket数据到本地系统中，如下：

获取数据库

当细细查看S3 bucket数据时，我发现了一些很敏感的文件，如database.js、config.js、app.js、payment.config，果不其然，这些文件中包含了支付相关的哈希键值、加盐值、数据库存密码凭据、内部使用 工具 名称和密码信息等等。而且，我还发现了一个正在运行的 MongoDB 实例，其密码就存在于明文的配置文件中，我连接上之后，在其中发现了一些客户数据，如下图所示：

尽管它没有包含所有的用户详细信息，但这些信息涉及10000多名客户。之后，我向该公司上报了该漏洞，他们非常重视，给予了及时的漏洞修复，并轮换了所有受影响的密钥和凭据。最终，这次从LFI到SSRF，再到Elastic Beanstalk实例，最后再到S3 bucket数据库权限获取的操作，导致了上万名目标公司客户的敏感密钥凭据信息泄露。