實戰篇丨聊一聊SSRF漏洞的挖掘思路與技巧

在剛結束的互聯網安全城市巡迴賽中，R師傅憑藉豐富的挖洞經驗，實現了8家SRC大滿貫，得到了第一名的好成績！R師傅結合自身經驗並期許新手小白要多瞭解各類安全漏洞，並應用到實際操做中，從而豐富本身的挖洞經驗，積累挖洞技巧。（文末有R師傅的我的專訪，挖洞祕籍盡在其中）

今天i春秋就針對衆多安全漏洞中的SSRF進行詳細介紹，理論內容結合實際案例進行深度分析，幫助你們快速get新技能！本文閱讀用時約7分鐘。

什麼是SSRF？

SSRF(Server-Side Request Forgery：服務器端請求僞造) 是一種由攻擊者構造造成由服務端發起請求的一個安全漏洞。通常狀況下，SSRF攻擊的目標是從外網沒法訪問的內部系統。SSRF造成的緣由大都是因爲服務端提供了從其餘服務器應用獲取數據的功能且沒有對目標地址作過濾與限制。好比從指定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。

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

答：固然會返回狀態碼，只是探測內網地址的話屬實不夠看的，因此若是一個點存在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請求都會被記錄。經過查看這些記錄信息，就能夠判斷漏洞詳情。

好比我在此輸入個人域名標識符，如圖：

 

而後我就能夠去ceye.io觀察是否有請求記錄，結果獲得記錄：

 

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

 

因此經過上述兩種方法，就能夠肯定這個地方確實是有SSRF漏洞的。不過僅僅到這是不夠的，除非有進一步的操做證實危害，因此接下來會演示探測端口。

簡單的SSRF繞過

上面說的漏洞點自己就是一個讓用戶輸入連接的地方，那天然就沒必要繞過，可是若是漏洞點是一個加載圖片的地方，想必你們都見過社區或者論壇有這樣一個模塊點，就是可讓用戶導入外部的圖片連接進行評論或者其餘，好比下圖：

 

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

 

有其餘限制的話都是一個道理，也能夠在burp裏截包改包達到此效果。

 

一個特殊的SSRF

有一次挖洞遇到一個站，就假設是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的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協議讀取本地文件等。

以上是今天的所有內容，你們看懂了嗎？

推薦閱讀

專訪丨互聯網安全城市巡迴賽冠軍肖策