起因

滲透能力的體現不只是儲備0day的多少，許多站點能否被突破，對本身基礎漏洞的熟練的配合利用也是一場考驗，故事正是因機緣巧合拿到shell的一次記錄總結。

從資訊蒐集到進入後臺

客戶給定的地址開啟之後就只有一個登入頁面，留下沒有賬號的我在風中凌亂。

一直懟一個登入框也不是事兒啊，沒辦法，只能先將埠，目錄和弱口令先探測起來。

埠基本都開了感覺有點問題，ping 過之後發現有cdn。

很不幸，弱口令沒爆出來，目錄埠也沒有太多的發現，當務之急就是需要一個賬號進入系統。但是賬號資訊該從哪裡蒐集？？？

等等，專案開始客戶是提供了郵箱地址作為報告的提交地址的，首字母大寫+名@xxx的格式，和許多企業的命名規則一樣。

一邊先把人名字典構造起來，一邊透過google語法去搜索相關郵箱，相關公司名稱，運氣不錯，從大大小小几十個網站論壇上面發現七八個公司郵箱，和幾個qq郵箱。

然後透過一些不可告人的的手段反查到了其中某些qq的繫結手機號，以及歷史密碼資訊。

再次構造相關字典，果然人們都喜歡用類似的密碼，撞庫成功。

進入後臺後，挨個測試了一遍功能點都沒能發現getshell的，上傳也沒能繞過後綴限制。

都說沒有getshell的滲透測試是不到位的，只發現一些中低危漏洞可沒法滿足。

簡單的許可權認證繞過

因為沒有太多的收穫，於是挨個訪問之前dirbuster跑出來的目錄，其中一個頁面訪問之後會有一道黑影一閃而過，然後跳轉到登入頁面，猜測做了許可權驗證，然後強制跳轉了。

測試中有很多時候都可能遇到無許可權訪問的情況

當我們遇到訪問403，401，302，或是彈框提示無許可權可以嘗試一下以下的辦法。

GET /xxx HTTP/1.1 403

Host: test.com 繞過： GET /xxx HTTP/1.1 200 Host: test.com X-Original-URL: /xxx

GET /xxx HTTP/1.1 403

Host: test.com 繞過： GET /xxx HTTP/1.1 200 Host: test.com Referer: http://test.com/xxx

302跳轉：攔截並drop跳轉的資料包，使其停留在當前頁面。前端驗證：只需要刪掉對應的遮擋模組，或者是驗證模組的前端程式碼。

這裡使用burp攔截一下，扔掉後面的跳轉，看到如下介面，彈窗還是提示沒法訪問，許可權不夠，但是和之前的訪問403不一樣了，難道是我使用了普通使用者登入的緣故？？？

熟練的開啟F12開發者模式。刪掉前端程式碼看是否能使用他的功能。

刪完許可權驗證模組的前端程式碼後，運氣不錯，還有部分功能可以使用。

ssrf-通向shell的鑰匙

在客戶系統後臺轉了半天，最後在一個檢視功能處發現了突破點

抓包發現post引數好像有點意思，嘗試換掉預設圖片的地址，改為dnslog地址，返回提示路徑不正確。

猜測是做了字尾的限制，應該只能post png,jpg等字尾的地址，先試試讀取一下遠端伺服器上的圖片，成功返回，果然有東西。

一個標準的ssrf，，因為沒法改變字尾，應該是不能讀取passwd之類的檔案了，還是先打一波dnslog，記錄一下真實ip地址。

但是ssrf可不只是讀個檔案那麼簡單，ssrf通常可以用來打內網應用，透過它來打個redis或者mysql豈不美哉。

先借助ssrf探測一下開放的埠，22，80，443，6379。

看看攻擊redis一般可以利用的dict和gopher兩種協議，使用gopher協議的話需要注意一些利用限制。

gopher協議規則比較複雜，經過查詢，找到了一款工具，使用其生成的payload很準確，且可自定義。

需要的小夥伴可以自取。

https://github.com/firebroo/sec_tools

需要將內容再進行一次url編碼傳到web的引數中才會正常執行。

Dict協議敲命令較為直接。

1.寫入內容；

dict://127.0.0.1:6379/set:x:test

2.設定儲存路徑；

dict://127.0.0.1:6379/config:set:dir:/tmp/

3.設定儲存檔名；

dict://127.0.0.1:6379/config:set:dbfilename:1.png

4.儲存。

dict://127.0.0.1:6379/save

我們一般對redis常見的攻擊方式有：

寫webshell；寫金鑰；定時任務反彈。

第一種需要web路徑，後兩種方法可能需要一定的許可權。

攻擊的思路有了，但是我們透過dict協議訪問後並沒有出現回顯，不知道是否存在未授權的redis服務，盲打一頓可能浪費寶貴的時間，靈光乍現，可以先寫一個圖片檔案到tmp目錄裡，再透過file協議進行讀取，出現內容就表明redis是能夠利用的。

出現回顯，說明檔案成功寫入了，雖然有亂碼，但是影響不大。

為了拿到shell，當然是先試試用gopher協議寫金鑰，本機生成金鑰:ssh-keygen -t rsa。再使用工具將以下命令轉換成gopher協議支援的形式。

config set dir /root/.ssh config set dbfilename authorized_keys set test "xxx" save

寫入後嘗試連線一下頁面啥也沒返回，嘗試連線一下Wfk，突然想起nmap結果好像ssh沒對外開放，決策性失誤。

嘗試反彈計劃任務，但是等了半天也沒見shell彈回來，猜測可能是許可權不夠，沒能夠成功寫入，可惜前期測試中並沒有發現資訊洩露暴露出web目錄的路徑，不然能寫個webshell也是極好的。

沒辦法，這個只能先擱置一邊，條條大路同羅馬，既然這個域名不行，看看有沒有繫結的其他域名在這個ip上。

旁站資訊洩露getshell

透過之前記錄的dnslog上的ip地址進行反查，發現了該ip地址下綁定了其他域名。

訪問後改掉url變數後的預設引數，觸發報錯，成功爆出了絕對路徑，小小的報錯，卻提供了巨大的價值。

因為是旁站，現在獲取到了B站的網站路徑，如果能透過A站的ssrf把webshell寫到B站的web路徑裡也是美滋滋了，說幹就幹。

訪問shell，並敲入whoami命令檢視許可權，發現是個低權www使用者。

提權

彈個互動的shell出來方便進行提權，但是遠端伺服器一直沒法正常收到shell。

切換一下埠，網路管理員可能做了一定的限制，嘗試透過443，53等經常開放的埠彈出shell。

成功拿到shell，獲取到低許可權SHELL後一般會看看核心版本，檢測當前使用者許可權，再列舉Suid檔案，如果都沒發現可能會藉助一些自動化指令碼來檢查可能存在的提權方式。

透過find / -perm -u=s -type f 2>/dev/null看看有s屬性檔案。

Python好像是可以透過suid提權的，翻了翻自己的小筆記，payload一發入魂。

這裡附上centos下suid提權較為全面的總結。

至此測試結束。

總結

整個測試過程遇到很多困難，許多地方看似簡單，其實是反覆嘗試之後才順利過關。

測試中其實並未使用多麼牛逼的攻擊手段，簡單梳理整個流程：全網資訊蒐集發現使用者賬戶撞庫拿到部分密碼前端驗證繞過發現新功能點ssrf探測資訊旁站獲取web絕對路徑跨網站寫入shell拿到shell後透過suid提權。