SSRF漏洞挖掘的思路與技巧

前幾天360冰刃實驗室的研究員洪禎皓髮現了一個Hyper-V的漏洞，因爲漏洞危險級別高，影響範圍廣，微軟在確認漏洞細節後第一時間確認獎金並致謝漏洞發現者。

獎金總額高達20萬美圓約合人民幣137萬，這也是微軟史上送出的最高一筆漏洞挖掘獎勵。、

挖漏洞還能拿這麼多錢，白帽子們已然坐不住，都想躍躍欲試了，那麼今天i春秋與你們分享一篇關於SSRF漏洞挖掘的思路與技巧，但願對你們有所幫助，年末賺些錢就當給本身發年終獎了，哈哈。
什麼是SSRF
SSRF(Server-Side Request Forgery：服務器端請求僞造) 是一種由攻擊者構造造成由服務端發起請求的一個安全漏洞。通常狀況下，SSRF攻擊的目標是從外網沒法訪問的內部系統。SSRF 造成的緣由大都是因爲服務端提供了從其餘服務器應用獲取數據的功能且沒有對目標地址作過濾與限制。好比從指定URL地址獲取網頁文本內容，加載指定地址的圖片，下載等等。

通俗的說，好比這樣一個url：，若是咱們將換爲與該服務器相連的內網服務器地址會產生什麼效果呢？好比127.0.0.一、10.0.0.一、192.168.1.1等等，若是存在該內網地址就會返回1xx 2xx 之類的狀態碼，不存在就會返回其餘的狀態碼，因此若是應用程序對用戶提供的URL和遠端服務器返回的信息沒有進行合適的驗證和過濾，就可能存在這種服務端請求僞造的缺陷。

說到這裏，先提兩個問題：

一、爲何要請求127.0.0.一、10.0.0.一、192.168.1.1呢？有什麼區別呢？

答：127.0.0.1只是表明你的本機地址，若是該網站只有一個服務器的狀況下，是能夠訪問127.0.0.1來判斷的，但要明確一點，127.0.0.1其實並非內網地址，內網地址是有嚴格的地址段的，這是ipv4地址協議中預留的，分別是

10.0.0.0--10.255.255.25五、

172.16.0.0--172.31.255.255 、

192.168.0.0--192.168.255.255。

二、若是請求地址會返回狀態碼，那請求地址+端口會不會返回狀態碼呢?

答：提出這個問題的同窗應該是至關clever的，答案是確定的，固然會返回狀態碼。只是探測內網地址的話屬實不夠看的，因此若是一個點存在SSRF，那勢必要嘗試一下能不能探測內網端口，好比，假設10.0.0.1這個地址存在，那咱們能夠嘗試請求10.0.0.1:2一、10.0.0.1:330六、10.0.0.1:6379等內網的經常使用端口，若是探測結果有收穫的話，那就能夠爲其餘工做節省不少力氣了。
基礎的SSRF漏洞利用
隨便找了個輸入點，假設這個圖中的點就是漏洞點吧，由於真正的漏洞點很差放出來，也很差打碼。

不過可能有人會問，那我怎麼知道這個點是不是漏洞點呢，其實這個東西很差回答，由於沒有成文的規定，經驗成分居多吧，若是看到讓用戶輸入url，導入外部連接的這些點，就能夠去嘗試一下。

言歸正傳，若是這是一個漏洞點，那咱們怎麼用呢，最簡單的方法，CEYE.IO。CEYE是一個用來檢測帶外流量的監控平臺，如DNS查詢和HTTP請求。一些漏洞類型沒有直接代表攻擊是成功的，就如同此處的SSRF，Payload觸發了卻不在前端頁面顯示。這時候使用CEYE平臺，經過使用諸如DNS和HTTP之類的帶外信道，即可以獲得回顯信息。

用法也很簡單，登陸 CEYE.IO，在用戶詳情頁能夠看到本身的域名標識符identifier，對於每一個用戶，都有惟一的域名標識符abcdef.ceye.io 。全部來自於abcdef.ceye.io 或*.abcdef.ceye.io/ 的DNS查詢和HTTP請求都會被記錄。經過查看這些記錄信息，就能夠判斷漏洞詳情。好比我在此輸入個人域名標識符，如圖：

固然咱們也能夠經過抓包，在包裏修改url的信息構造不一樣的請求，而後觀察返回的狀態碼來探測信息。

因此經過上述兩種方法，那我就能夠肯定這個地方確實是有SSRF漏洞的。不過僅僅到這是不夠的，這樣的操做提到補天或者盒子都是不收的，除非有進一步的操做證實危害，因此接下來會演示探測端口。
SSRF的簡單繞過
上面說的漏洞點自己就是一個讓用戶輸入連接的地方，那天然就沒必要繞過，可是若是漏洞點是一個加載圖片的地方呢，想必你們都見過社區或者論壇有這樣一個模塊點，就是可讓用戶導入外部的圖片連接進行評論或者其餘，好比下圖：

那麼這種地方，也是可能存在SSRF的，不過當咱們輸入ceye.io卻發現並無回顯請求，這是由於這種地方通常會對後綴作一個檢測，若是不是jpg或者其餘圖片後綴的話並不會經過，不過好在ceye.io是很強大的，咱們能夠隨便構造，abcdef.ceye.io/ichunqiu.jpg, 對其進行輸入，再去觀察有無回顯，結果有了：

有其餘限制的話都是一個道理，也能夠在burp裏截包改包達到此效果。
挖洞案例
有一天筆者在挖洞的時候遇到一個站，就假設是www.xxx.com吧， 發現是一個開源的系統，因而就突發出不想黑盒的想法，想看看審計的能力學的怎麼樣了，就在網上下載這個開源的系統，一點一點的對其審計，在某個文件裏發現這麼一個連接：http://127.0.0.1/abc.php?url=...://www.baidu.com， 這可不是跳轉，結合上下代碼，發現此連接好像是服務器發起請求的操做，由於127.0.0.1是本機地址，因此筆者嘗試構造http://www.xxx.com/abc.php?ur...://www.baidu.com， 發現也能夠成功訪問，因此隱約以爲這是一個操做的地方，因爲那個開源系統找不到了，因此無法貼圖了，只能一點一點說了。
總之筆者經過分析上下的代碼，發現這個連接的構成是由賦予abc.php一個外部的url參數，在沒有任何過濾，任何防禦的狀況下讀取這個外部url併發起請求，就能夠嘗試是否能夠讀取內網地址呢？因而筆者構造http://www.xxx.com/abc.php?ur...://127.0.0.1:80， 爲何第一次就要訪問80端口呢，由於該站是能夠訪問的，因此80端口必開放，第一次探測80也是想看一看正確的返回與錯誤的返回的區別，訪問完http://www.xxx.com/abc.php?ur...://127.0.0.1:80後，獲得正確的返回結果，就能夠嘗試繼續訪問90端口，100端口，等等。
不過筆者繼續想到，這個地方既然存在SSRF，且url參數沒有任何防禦與過濾，那可不能夠嘗試讀取文件呢，說來就來，繼續構造http://www.xxx.com/abc.php?ur...:///C:/Windows/win.ini。 發現讀取成功，因此又成功探測到一枚文件讀取。
weblogic的SSRF漏洞
提起Weblogic，相信不少人都熟悉，因此關於Weblogic的其餘漏洞筆者就不獻醜了，就只在這個地方聊一下Weblogic的SSRF漏洞。

WebLogic的SSRF漏洞算是一個比較知名的SSRF漏洞，具體原理能夠自行谷歌。本篇主要是經過復現該漏洞來加深對SSRF漏洞的理解。Weblogic的SSRF漏洞的存在頁面筆者就不說了，百度均可以找到的，頁面的樣子是這個樣子的：

當初在學習這塊的時候，覺得只要存在這個頁面就必有SSRF，結果固然是否認的，在借鑑了大佬的PPT以後，發現一共有如圖四種回顯狀態：

那麼能夠經過構造

http://xxx.com/uddiexplorer/S...://(要探測的內網地址)&rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search對其進行探測，觀察其回顯狀態，判斷是否存在目標網段，這個地方最主要的就是operator這個參數，主要思路就是經過修改這個參數，來探測內網地址和內網端口，不過問題來了，上面剛纔說內網地址那麼多，咱們要怎麼才能知道呢，且慢，在Weblogicssrf的漏洞頁面點擊這裏：

就會來到這裏，有時候因爲配置不當的關係，這個地方會直接給出內網地址的網段：

有網段了，就能夠一點一點的探測了，探測內網的telnet，ssh，redis，以及各個數據庫，爲之後的內網漫遊作好信息收集。還有在Weblogic的SSRF中，有一個比較大的特色，就是雖然它是一個「GET」請求，可是咱們能夠經過傳入%0a%0d來注入換行符，而某些服務（如redis）是經過換行符來分隔每條命令，也就說咱們能夠經過該SSRF攻擊內網中的redis服務器。手動反彈shell，就是常規的發送redis命令，而後把彈shell腳本寫入crontab中，最後用get發送命令，不過別忘了，get發送命令的時候要進行url編碼，最後在服務器上進行監聽就OK了。

固然，做爲一名腳本小子，手動探測以及反彈shell太累了，好在網上的探測腳本不少，不過試了不少，感受仍是下面這個很順手，在此貼上一個大牛的腳本，能夠很方便的探測SSRF的網段以及每一個網段的端口，甚至還有反彈shell的功能，地址：https://github.com/NoneNotNul...
SSRF這個漏洞雖然在各大src上都被評爲低危，可是這是由於它自己的危害有限，不能否認，如果與其餘漏洞，其餘思路結合起來會對你的滲透過程方便不少，它的強大之處是在於探測到一些信息以後從而進一步的利用，好比獲取內網的開放端口信息，主機的信息收集和服務banner信息，攻擊內網和本地的應用程序及服務，還有就是利用file協議讀取本地文件，就好像上面的那個文件讀取漏洞。

好了，以上就是我要分享的內容，你們有什麼建議歡迎在文末留言，互相學習交流，共同進步。