【渗透测试】一次从黑盒转向白盒
前言
本次是針對學校某系統的滲透記錄,已獲得相應授權。通用漏洞涉及影響單位早前已提交至SRC平臺,廠商已發布對應補丁。
【查看資料】
信息收集
目標系統主要是一個支付平臺,是近期剛上線的系統,向學校老師取得相應授權后開始測試。
軟件開發商:`xx軟件開發有限公司/xxsoft/xxxx.com.cn` 開發語言: `Java` 框架: `St2`因為是近期剛上線的系統,單點認證還沒有接入。無法通過單點認證登錄此系統,在嘗試爆破admin密碼后無果. 開始轉向源碼的收集。畢竟白盒才是最直接的手段。源碼的收集大致有以下幾個思路:
1.百度云盤 2.閑魚 (部分商家已搭建第三方系統為主可能有存貨需要主動詢問) 3.同系統站點下存在備份百度云盤和閑魚比較費時間,這兩個主要看自身對關鍵詞的理解。因為這兩個思路基本被人玩的差不多了，也就 不在浪費時間了(后面找了下也確實沒有)。先確定了該系統的指紋,使用fofa收集相同系統站點。
然后丟進御劍里走一遍。字典如下:
這里其實需要注意.很多情況是tomcat下部署了多個應用。在不同目錄中,而 ROOT 目錄中只是幾個簡單的重定向 文件。所以在掃描多應用站點時,應該把 ROOT 改成應用所處目錄名. 如:
/pay/index.jsp-- > /pay/ --> pay.war上面這套思路純粹看運氣.結果也是沒有掃到.
某組件存在安全問題
備份走不通只能走一些歷史漏洞了。把url列表丟進自己寫的輪子里掃一遍: (先是掃了一次目錄,后根據目錄再次驗證)
發現ticket模塊下存在 officeserver.jsp ,訪問后出現提示
典型的某格組件,該組件默認存在 SAVEASHTML 方法,攻擊者構造特殊的數據包可以造成任意文件的寫入: 并且默認使用Base64加密,主要問題在于數據包的構造: 一張圖簡單了解下具體格式. (別噴,我自己也看不懂)
解釋:
具體參考DbStep.jar中的StreamToMsg 方法。這里只做簡單的解釋 數據包的前64字節為配置信息,告訴后端該如何讀取,也就是0-63位。
其中 0:15 賦值給變量 FVersion , 16:31 賦值給變量 BodySize , 32:47 賦值給 ErrorSize . 48:63 賦值給 FFileSize .除了 FVersion ,其余中間內容只能填寫數字,代表著各個變量的內容要讀取多少位. 以 BodySize 為例子,這里的內容為 114 ,也就是說去除數據前64字節,在往后讀114字節.這114字節內容賦值給 FMsgText .之后取參數也是從 FMsgText 中取，每個參數以 \n\t 進行分割。
以此類推. 了解如何構造對應數據包后開始編寫腳本: 該組件默認會有一個 SAVEASHTML 方法。可以將 FFileSize 截取的內容存儲到文件中。導致任意文件的寫入。
當文件夾不存在時會自動創建對應的文件夾。MsgFileSave 方法后面拼接的 mHtmlName 內容可控,寫入文件可以 嘗試跨目錄。編寫生成腳本:
body = f"""DBSTEP=REJTVEVQ OPTION=U0FWRUFTSFRNTA== HTMLNAME=Ly4uLy4uLzEuanNw DIRECTORY=Lw== LOCALFILE=MQ==""".replace( ' ', '\n').strip() coente="""hello1""" fileContent=f''' {coente} '''.replace("\n","").strip() payload="DBSTEP V3.0 " bodysieze=str(len(body)) filesize=str(len(fileContent)) payload+=str(int(bodysieze)+3)+' '*(16-len(bodysieze))+'0'+' '*15+filesize+' '*(16- len(filesize))+body+fileContent FVersion=payload[0:15] print("version:",FVersion) Body=payload[16:31] print("BodySize:",Body) Error=payload[32:47] print("ErrorSize:",Error) File=payload[48:63] print("FileSize:",File) print(payload)使用postman發送payload到指定文件。
可能是覺得我操作的過于順利,返回保存文件失敗的內容,于是陷入了沉思。經過一系列的探索。我發現,當 FileName 中的內容不存在 /…/ 跨目錄符號時就能保存成功。
因為 mFilePath 取值就是當前應用的根目錄
所以文件應該在 HTML 目錄下。嘗試訪問.
?返回404錯誤,證明文件并沒有寫入到指定位置中。
Linux和Windows 寫入文件的差異性
最后在請教忍醬后得知,由于目標是 Linux 系統,在 linux 系統中, \ 被當做成一個文件夾。而 FileOutputStream 在寫入文件時如果文件夾不存在會直接拋出錯誤。
Demo:
當寫入文件時。由于文件夾不存在會創建一個 \HTML\test 的文件夾。而最終寫入路徑中的文件夾名為 \HTML\test\, HTML\test\ 名字的文件夾是不存在的，導致文件無法寫入成功 .
在不使用 /…/ 跨目錄符號時,文件最終會以 \HTML\test\1.txt 的文件名進行存儲,這與預期也是不符合的。
解決方案:
在了解無法寫入的原因后,開始尋找解決方法。既然該方法可以創建文件夾,那么如果我預先創建一個 \HTML\test\ 命名的文件夾,后續不就可以寫入了？\ 在創建文件夾時，如果 mDirectory 的內容不為空,那么最終存儲的目錄地址會進行一個拼接,然后創建。我們可 以在 mDirectory 上做一些嘗試。在創建的文件夾名后面添加 \\ 符號,來確保能創建我們預期的文件夾名
實踐
:
這里寫了一個Demo,模擬最終寫入文件的流程。在 path2 上添加多個 \ .最終成功創建出了預期的\HTML\test\ 文件夾。(實際環境中其實需要3個)
有了對應的文件夾,再次嘗試寫入,由于拼接的原因,需要在原來的目錄后去掉一個 \
寫入成功: 完成跨目錄
根據目標系統生成對應的POC: 總共分兩個步驟: 1.創建文件夾 2.寫入文件
再次嘗試寫入文件:
成功寫入！
終點也是起點
成功拿到Webshell后,根據現有POC.嘗試在目標系統上復現,發現不存在 ticket 模塊？？？,白干了？
好在先前拿的系統中存在 PAY 模塊,可以直接下載下來進行代碼審計。一頓審計過后發現并沒有什么利用點???,該系統不存在文件上傳點,并且SQL注入都會對傳入的字符做處理
統一使用 org.apache.commons.lang.StringEscapeUtils.escapeSql 方法進行過濾。
這導致后續利用難。但是根據 web.xml ,發現該應用使用了 AXIS 且版本為1.4也開啟了遠程訪問
Axis1.4 是存在一個遠程命令執行的,可以向 web service 中添加惡意方法。導致命令執行。
該漏洞利用需要一個SSRF漏洞,來組合利用。
根據現有代碼開始查找,是否有可控點。一頓操作下來發現并沒有可以利用的SSRF點。基本都是固定的URL。
回想起最近才復現的 MySQL JDBC XXE漏洞(CVE-2021-2471) .xxe也是可以發送http請求的。(主要是平時不太關注這類漏洞)
在JAVA中,可能造成XXE漏洞的主要有以下:
SAXBuilder SAXParserFactory SAXReader SAXTransformerFactory TransformerFactory ValidatorSample XMLReader Unmarshaller SchemaFactory .....最終審計發現了一處 SAXBuilder 所造成的XXE漏洞。
構造Payload,測試一下dnslog。
Payload:
得到響應。
有了SSRF,后續利用起來也比較方便了。因為此系統安裝路徑都是統一的,公開的幾個利用鏈都是第三方jar 包,LogHandler比較麻煩。所以這里在內置方法類中找了一個文件寫入的方法。FileUtil下有一個 writeFileContent 方法，可以直接寫入文件。
(公開的鏈中有可以直接執行命令的，如:freemarker。目標不存在此依賴)
使用SSRF GET請求添加到 Web services ,“會有端口不一樣的情況！”
(POST轉換一下格式就可以)
方法被成功添加到Web Services中
調用方法,寫入文件。成功拿到Webshell!
最后
關注我，持續更新······
私我獲取【網絡安全學習資料·攻略】
總結
以上是生活随笔為你收集整理的【渗透测试】一次从黑盒转向白盒的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【网络安全】 利用 EHole 进行红队
- 下一篇： 【安全漏洞】Resin解析漏洞分析