一次漫长而艰苦的SSRF漏洞研究

我之所以写这篇文章，不是为了讲述一种新颖而独特的攻击技术，而是为了展示针对目标系统某个特殊功能我们该如何挖掘背后的工作原理，测试是否存在漏洞。这篇文章主要涉及一个SSRF漏洞，发现和研究利用它都非常有趣，我们花了很多时间才得到显著的成果。

这个目标端点实际上是另一个漏洞猎人Ibram（在意识到我们的目标一样后）发给我的，这也是我们第一次合作，最后一起发现了很多有趣的东西。我们都深入挖掘了目标应用的运行逻辑。我还注意到这个端点在Wayback Machine目标应用范围内出现了几次（在大约15个子域上），其中涉及的功能大概是每个漏洞猎人对SSRF的想象。这是一个代理端点，用户可向其提供一个URL，接着服务器将发出一个HTTP请求并将响应直接返回给用户。端点类似于https://company.com/proxy。我尝试的第一件事是使用我的Burp Collaborator，看看它是否会向我指定的网站发出请求。

但我很快发现这里使用了白名单，它只从“受信任”列表中获取主机名。我尝试了不同的company.com域名，发现它们都能正常工作，很明显*.company.com在这个白名单中。于是我们试图找到存在开放重定向或存在被接管可能的*.company.com子域，想借可信任的子域为我们的网站打掩护。

于是我使用Findomain开始挖掘子域，并用httprobe寻找活动主机，最后使用Waybackurls从Wayback Machine上拉回所有找到的URL。最后我得到了一个包含几十万个URL的列表。我从开放重定向开始，利用过滤函数从列表中寻找一些可能涉及开放重定向的URL：grep "=http" wayback.txt。很快，我们便发现了一些有效的输出！现在，回到测试刚开始的端点：

不幸的是，我现在发现，任何重定向操作都会导致302到一个默认错误页面。我尝试测试了一段时间，最终放弃了这方面的研究，因为服务器只是获取一个URL并返回响应。最后我发现，除了200之外的任何响应都会导致应用抛出302。我又开始寻找了一些子域接管的实例，但也没有成果。

很快我又想到，我可以选择那些没有解析或者响应超时的子域进行SSRF测试，因为它们可能只有内部才能访问的，我们或许可以获取服务器的隐藏内容。但很快这个希望也破灭了，我本以为这对某些域名是有效的，但不幸的是，没有什么有趣的东西跳出来。我还检查了*.company.com的DNS记录，看看是否存在类似localhost或127.0.0.1可被我利用的记录。但不幸的是，我找不到任何这样的域名。

现在，我只能尝试绕过URL的解析器逻辑。我使用了几乎所有绕过技术，但好运还是没出现，任何IP地址以及十进制编码版本都会出现错误。这个URL解析器似乎相当强大。好吧，我决定再看看这个白名单是否过于宽松。

我在Github上找到了1000个域名名单，我决定遍历这些域名。事实证明，它并没有最初想象的那么严格！amazonaws.com是一个在白名单的域名。值得一提的是，amazonaws.com是AWS的域名，与全球流行的众多网络服务绑定在一起，比如S3和EC2，其中每个用户有自己专属的端点和子域。是的！我可以在S3上托管一个XSS文件。

正如预期的那样，它成功了！即使我现在停手，也可以报告一个XSS漏洞了。我马上尝试了一些其他的利用，比如试图让服务器执行我的HTML或javascript，去加载系统的某些敏感信息，例如：

AWS元数据：<iframe src="http://169.254.169.254/latest/meta-data/"></iframe>

本地文件: <img src="file:///etc/passwd">

不幸的是，和前面一样，服务器并不会执行目标URL上的任何内容，只是单纯地获取和返回内容。接着我决定启动一个EC2实例，以便提供更动态的内容。我启动了一个快速服务器，并编写了几个简单的Flask端点来展示各种内容、执行重定向和其他一些操作。在尝试了几次后，我的目光再次转向重定向。我认为也许可以通过一个特定的响应代码来触发重定向。我编写了一个Flask端点，接受url和code查询参数，模拟每个HTTP状态代码。我注意到应用会缓存来自相同URL的响应，因此每个URL都需要不同，这通过添加唯一查询字符串就可以解决这个问题，比如：

https://my-ec2.amazonaws.com/redirect?1&url=...&code=302

https://my-ec2.amazonaws.com/redirect?2&url=...&code=302

再一次，运气不佳。现在我有点绝望了。我尝试寻找任何DNS记录指向本地主机或元数据服务169.254.169.254的*.amazonaws.com域名，但没有结果。经过多次尝试之后，我突然意识到，在测试URL解析器逻辑时，URL是否在白名单亦或目标URL是否给出200响应，应用程序的响应是不同的。我发现这个白名单实际上并不是*.company.com，而是*company.com。当时我并没有立刻意识到这一点，但后来我想起来了。所以我在回家的路上，用手机在neemacompany.com上购买了一个域名，然后为md.neemacompany.com设置指向169.254.169.254的DNS记录，为local.neemacompany.com设置指向127.0.0.1的DNS记录。

接着我拿出我的笔记本电脑，立即开始向AWS元数据服务进行攻击！

成功了！这个端点确实有漏洞！现在我可以使用AWS元数据服务获得临时AWS凭据，并访问公司的AWS环境。我还尝试了我的local.neemacompany.com，确认我可以访问一些内部服务。我现在成就感爆棚，立刻写报告并提交。我终于可以安心休息一夜了!

第二天早上我醒来，砰！漏洞重复！

我的漏洞和一年前的漏洞报告重复了！当我看到这一切时，我笑了。

我现在最高兴的是我能够弄清楚这个漏洞（即使这花费了我12美元）。如果我没解决它，它肯定会让我发疯，所以我觉得这整个过程是值得的，至少它非常有趣！而且我和一个漏洞猎人Ibram配合地也很好。

希望这篇关于我挖掘漏洞的文章能令人愉快且提供帮助!

本文由白帽汇整理并翻译，不代表白帽汇任何观点和立场
来源：https://medium.com/a-bugz-life/exploiting-an-ssrf-trials-and-tribulations-14c5d8dbd69a