凡事总有第一次，不是吗？好吧，让我来告诉你我第一次因为一个 SSRF 漏洞获得“卓越”评级的经历。那是一段疯狂的旅程，充满了兴奋、沮丧，以及一些顿悟的时刻。如果你是一个漏洞猎人，或者只是一个热爱冒险的人，那就继续看下去吧——我保证这绝对值得！

什么是 SSRF？

服务器端请求伪造 (SSRF) 是一种安全漏洞，允许攻击者利用服务器向通常无法访问的内部系统或外部服务发送请求。

通常，当 Web 应用程序允许用户输入 URL 来从外部源获取数据，而没有对输入进行适当的验证或过滤时，就会发生 SSRF。攻击者可以利用此漏洞来：

• 扫描内部网络并发现在开放端口上运行的服务。
• 访问内部 API 或管理系统。
• 利用在 localhost 上运行的服务，例如 Redis、Memcached 或云元数据服务（http://169.254.169.254）。
• 利用 SSRF 执行高级攻击，如远程代码执行 (RCE) 或泄露敏感信息。

以下是可能导致 SSRF 的简单请求示例：

GET /fetch?url=http://localhost:8080/admin HTTP/1.1host：vulnerable-website.com

如果服务器没有正确验证输入的 URL，攻击者可以修改 URL 来访问内部资源或执行其他类型的攻击。

旅程开始

大约两个月前，我认识了Tuan，他是Intigriti的顶级猎人。聊了一会儿后，我们决定在三月的最后一周组队。我告诉他，我以前从未发现过“卓越”漏洞。他只是简单地说：“相信自己，我们一起努力吧。”

我们也确实这么做了。

一起狩猎

我们分工合作：我负责漏洞利用，Tuan 则专注于识别可行的目标。一天晚上，我偶然发现了一个有趣的目标，它暴露了许多特征。这似乎是个完美的起点。我告诉了 Tuan，然后我们俩就立即投入了进去。

在短短 15 分钟内，我查看了 Burp Suite 中的日志，发现了一个奇怪的请求：

这个参数DocumentUrl立刻引起了我的注意——它就在那里，Url简直就像在挥舞着一面旗帜，上面写着“攻击我！”。我最初以为这是一个IDOR漏洞，但没想到。当我解码Base64字符串时，我发现了一个以 开头的URL http://172.x.x.x:xxxx。我的直觉告诉我，这是一个SSRF漏洞。

我迅速部署了 Collaborator 来测试回调，果然收到了 pingback。我知道我走对了路。

攻击开始

我立即打电话给 Tuan，让他加入我们的搜索。我们在尝试通过 HTTP 访问时遇到了一个小问题。我们最初的想法，比如 RFI 和 LFI，都失败了，因为标头的内容类型被设置为 PDF。

即使我们尝试访问一些常用的 API，它也会返回 500 错误，并导致 API 一度处于 DOS 状态。当时已近午夜，我们都筋疲力尽。但突然间，我突然想到——为什么只尝试 HTTP？那 HTTP 呢file://？

我测试了一下：

file：///

并且它成功了！

成功了！我开始列出文件和目录。为了实现自动化，我在人工智能的帮助下编写了一个脚本来暴力破解目录和文件：

没过多久，我几乎就克隆了服务器的目录。我发现当前用户是www-data，并且没有其他拥有 SSH 访问权限的用户。

更上一层楼

这是我第一次获得“异常”发现的机会，所以我想好好利用它。当时已经凌晨1点多了，但我还是坚持了下来。在Tuan的帮助下，我们绘制了服务器地图，找到了文件夹，并开始读取配置文件以提取凭证。我们下载了JAR文件，并逐一分析了其中的内容。

最后，我放弃了。但第二天早上，分类小组确认该漏洞属于“特殊”漏洞。DOS、SSRF 和凭证泄露——全部通过了。

结论

这是我的第一次合作，非常成功。之后，我和 Tuan 又发现了一些“关键”和“异常”漏洞。下次我可能会写一些相关的内容。

专家提示：在漏洞挖掘中，好友的价值远胜于黄金。并且，永远——永远——要遵循你的直觉。

为未来更多的发现欢呼！

原文始发于微信公众号（安全狗的自我修养）：我的异常 SSRF 发现