前幾天360冰刃實驗室的研究員洪禎皓發現了一個Hyper-V的漏洞，由於漏洞危險級別高，影響范圍廣，微軟在確認漏洞細節后第一時間確認獎金並致謝漏洞發現者。
獎金總額高達20萬美元約合人民幣137萬，這也是微軟史上送出的最高一筆漏洞挖掘獎勵。
挖漏洞還能拿這么多錢，白帽子們已然坐不住，都想躍躍欲試了，那么今天i春秋與大家分享一篇關於SSRF漏洞挖掘的思路與技巧，希望對大家有所幫助，年底賺些錢就當給自己發年終獎了，哈哈。
什么是SSRF
SSRF(Server-Side Request Forgery：服務器端請求偽造) 是一種由攻擊者構造形成由服務端發起請求的一個安全漏洞。一般情況下，SSRF攻擊的目標是從外網無法訪問的內部系統。SSRF 形成的原因大都是由於服務端提供了從其他服務器應用獲取數據的功能且沒有對目標地址做過濾與限制。比如從指定URL地址獲取網頁文本內容，加載指定地址的圖片，下載等等。
通俗的說，比如這樣一個url：，如果我們將換為與該服務器相連的內網服務器地址會產生什么效果呢？比如127.0.0.1、10.0.0.1、192.168.1.1等等，如果存在該內網地址就會返回1xx 2xx 之類的狀態碼，不存在就會返回其他的狀態碼，所以如果應用程序對用戶提供的URL和遠端服務器返回的信息沒有進行合適的驗證和過濾，就可能存在這種服務端請求偽造的缺陷。
說到這里，先提兩個問題：
1、為什么要請求127.0.0.1、10.0.0.1、192.168.1.1呢？有什么區別呢？
答：127.0.0.1只是代表你的本機地址，如果該網站只有一個服務器的情況下，是可以訪問127.0.0.1來判斷的，但要明確一點，127.0.0.1其實並不是內網地址，內網地址是有嚴格的地址段的，這是ipv4地址協議中預留的，分別是
10.0.0.0--10.255.255.255、
172.16.0.0--172.31.255.255 、
192.168.0.0--192.168.255.255。
2、如果請求地址會返回狀態碼，那請求地址+端口會不會返回狀態碼呢?
答：提出這個問題的同學應該是相當clever的，答案是肯定的，當然會返回狀態碼。只是探測內網地址的話屬實不夠看的，所以如果一個點存在SSRF，那勢必要嘗試一下能不能探測內網端口，比如，假設10.0.0.1這個地址存在，那我們可以嘗試請求10.0.0.1:21、10.0.0.1:3306、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=http://www.baidu.com， 這可不是跳轉，結合上下代碼，發現此鏈接好像是服務器發起請求的操作，因為127.0.0.1是本機地址，所以筆者嘗試構造http://www.xxx.com/abc.php?url=http://www.baidu.com， 發現也可以成功訪問，所以隱約覺得這是一個操作的地方，由於那個開源系統找不到了，所以沒法貼圖了，只能一點一點說了。
總之筆者通過分析上下的代碼，發現這個鏈接的構成是由賦予abc.php一個外部的url參數，在沒有任何過濾，任何防護的情況下讀取這個外部url並發起請求，就可以嘗試是否可以讀取內網地址呢？於是筆者構造http://www.xxx.com/abc.php?url=http://127.0.0.1:80， 為什么第一次就要訪問80端口呢，因為該站是可以訪問的，所以80端口必開放，第一次探測80也是想看一看正確的返回與錯誤的返回的區別，訪問完http://www.xxx.com/abc.php?url=http://127.0.0.1:80后，得到正確的返回結果，就可以嘗試繼續訪問90端口，100端口，等等。
不過筆者繼續想到，這個地方既然存在SSRF，且url參數沒有任何防護與過濾，那可不可以嘗試讀取文件呢，說來就來，繼續構造http://www.xxx.com/abc.php?url=file:///C:/Windows/win.ini。 發現讀取成功，所以又成功探測到一枚文件讀取。
weblogic的SSRF漏洞
提起Weblogic，相信很多人都熟悉，所以關於Weblogic的其他漏洞筆者就不獻丑了，就只在這個地方聊一下Weblogic的SSRF漏洞。
WebLogic的SSRF漏洞算是一個比較知名的SSRF漏洞，具體原理可以自行谷歌。本篇主要是通過復現該漏洞來加深對SSRF漏洞的理解。Weblogic的SSRF漏洞的存在頁面筆者就不說了，百度都可以找到的，頁面的樣子是這個樣子的：
當初在學習這塊的時候，以為只要存在這個頁面就必有SSRF，結果當然是否定的，在借鑒了大佬的PPT之后，發現一共有如圖四種回顯狀態：
那么可以通過構造http://xxx.com/uddiexplorer/SearchPublicRegistries.jsp?operator=http://(要探測的內網地址)&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/NoneNotNull/SSRFX
SSRF這個漏洞雖然在各大src上都被評為低危，但是這是因為它本身的危害有限，不可否認，若是與其他漏洞，其他思路結合起來會對你的滲透過程方便很多，它的強大之處是在於探測到一些信息之后從而進一步的利用，比如獲取內網的開放端口信息，主機的信息收集和服務banner信息，攻擊內網和本地的應用程序及服務，還有就是利用file協議讀取本地文件，就好像上面的那個文件讀取漏洞。
好了，以上就是我要分享的內容，大家有什么建議歡迎在文末留言，互相學習交流，共同進步。