从文件读取到彻底挖掘后端海量敏感数据

嗨，大家好！

这是我最近发现的一个漏洞利用链条，最终可导致印度最赚钱的电子商务公司的一个数据库中的数据被我完全掌握。现在，就让我们开始吧！

在渗透测试中，我比较关注LFI漏洞（本地文件包含）。因此我会特别注意目标网站上那些和文件交互有关的功能和页面。而在这次目标的产品页面上，我找到了一个常见的软件下载功能，提供“Android Google paly”和“iPhone App store”两种下载方式。

当我点击它的时候，它把我重定向到下面的网页。

接着，又立即重定向到先前的引用页面，但当我直接在无痕浏览器中打开上述的下载链接时，会被重定向到“404 page not found”。很明显，在打开下载页面时，它会寻找一些条件和参数，然后遵循代码中的if/else逻辑。为了查看这其中涉及哪些参数，我检查了页面源码。

很明显，源码中的“download-handler.php”文件需要代入两个参数，一个是参数“path”，表示最终的下载路径；一个是参数“name”，表示路径名称。当缺少这两个参数时，就会重定向到404。按照上面的代码，最终的下载URL是

downloadcallback/download_handler.php?path=

于是我开始尝试目录遍历攻击../../../../etc/passwd，幸运的是，我拥有很大的权限，能够读取/etc/passwd文件的内容和其他敏感文件。

最终，我能够读取各种Linux系统文件、配置文件、访问日志等，这些文件使我获得了用户的访问令牌，以及更为敏感的信息。而个漏洞的罪魁祸首就是“download-handler.php”，如下所示它的源码：

以上代码的逻辑很简单，就是将指定的文件名作为输入，将内容读取回客户端。注意，这里也很容易遭受SSRF攻击

我尝试过SSRF攻击中可以使用的协议（file://、dict://、ftp://和gopher://），并发现可以通过file:///scheme读取文件。

在我一开始发现这个文件读取漏洞时，我碰巧遍历读取了/etc/motd文件，这表明该应用是部署在AWS ElasticBeanstack上。

于是我决定通过SSRF漏洞搜索AWS实例的元数据和用户数据。并最终：

我甚至可以从接口“http://169.254.169.254/latest/dynamic/instance-identity/document”中检索到处AWS帐户的ID和区域。

说明一下，我从AWS Elastic Beanstalk中了解到了一个接口，可以用来获取AWS访问密钥、Secret和令牌。

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

我很快通过SSRF进行了各种尝试，获取他们AWS的访问密钥、ID、令牌。这个时候，这个漏洞好像已经有点严重了。

是时候验证找到的AWS帐户了。为了确保登录凭证不会过期，我配置了aws-cli命令行，并尝试将S3 bucket数据列出并下载到本地。

在查看这些S3 bucket时，我发现了一些关键文件，比如databa se.js、config.js、app.js、payment.config文件，如如我所料，它们包含了诸如Payment hash key和salt（可以用来伪造订单的），多个数据库登录凭证、一些内部工具的用户名和密码等等。另外我还发现了一个MongoDB实例，它的登录凭证也放在配置文件中，当我连接上它时，我发现了大量客户数据。

虽然这个MongoDB没有包含所有的用户详细信息，已经超过了10万个。我在很快报告了这个漏洞，公司也很快修复了它，并修改了所有受影响的登录凭证和密钥。因此，从文件读取开始，我找到了SSRF漏洞，再了解到Elastic Beanstalk，从那里获取一个AWS帐户登录凭证，又从AWS S3中发现了一个MongoDB数据库凭证。最后从MongoDB中，我发现大量客户的详细信息，以及各种敏感的凭证/密钥。

感谢你的阅读！

本文由白帽汇整理并翻译，不代表白帽汇任何观点和立场
来源：https://medium.com/@logicbomb_1/chain-of-hacks-leading-to-databa se-compromise-b2bc2b883915