記一次信息泄漏引發的慘案
本次文章較為基礎，作為一次項目經歷中的趣事記錄，有很多不足的地方，還請各位大佬輕錘。
在某項目中撈到一處目標站點，是一處某某監控系統的登錄頁面。登陸的頁面大概長如下的樣子。
看起來和找到的其他站點都一樣，平平無奇。準備敲弱口令admin/123456進行測試，但是當點擊用戶名的時候，注意到該登錄點的用戶名框寫著大大的三個字“請選擇”，直接就無需手動輸入。
看來不用先枚舉一波可用的用戶名了，直接有現成的了。
選擇某個看上去像是測試賬號的用戶名后，輸入密碼123456，非常絲滑而又毫無懸念的登錄……失敗。
看著屏幕上冰冷的“用戶名或密碼錯誤”8個字，想著先對網站進行一波弱口令猜解。
但是，當我抓取登錄數據包，發現網站在前端對密碼使用了某種加密方式，直接添加字典進行爆破是沒戲了，需要先對前端的加密方式進行繞過。
閱讀源碼嘗試對前端的加密方式進行繞過，找到登錄時對密碼進行加密處理的guomi函數。
通過關鍵字passowrd和guomi在網址admin.js中，找到該函數，確認前端使用的SM4的加密方式。找到該加密函數，剩下的就好辦了。
通過下斷點的方式，找到用戶在登錄時對密碼進行加密所調用的js腳本。通過分析，發現主要有admin.js以及sm4.js。
嘗試在瀏覽器上直接調用該加密方式，對我們的明文字典進行加密。這種方式非常的快捷，只要我們找到登錄時對密碼加密的函數即可。
當無法確定后續調用的加密js時很好用，但缺點是每次更換暴破字典都需要先生成密文字典。
根據admin.js中的guomi加密函數編寫密文字典生成代碼，使用只有123456的密碼字典進行測試，得到的密文和數據包中密文內容相同。
感覺一切歐克，就在下面的網站對手頭的弱口令字典進行處理，轉化為列表的格式。
https://uutool.cn/list2json/
在瀏覽器調試模式console中，使用js腳本，對明文的列表數據調用網站的加密函數進行加密，用得到的密文字典在burp上進行弱口令枚舉即可。腳本可以參考如下進行編寫：
function guomi(password) {
var s4 = new SM4Util();
s4.iv = "XXXXXX";
var md5str = s4.encryptData_CBC(password);
return md5str;
}
var list=["123456","111111"];
var newlist=[];
for(var i=0;i<list.length;i++)
{
newlist+=guomi(list[i])+"";
}
console.log(newlist);
本想前端提供的用戶也不少了，有些賬號看著就像簡單的測試賬號，應該問題不大，結果硬是沒有找到弱口令賬號（字典都不太行的亞子）。之后對站點進行了未授權訪問測試、在JS中搜索敏感路徑以及進行注入等測試，均未發現可以利用的點。
就在無聊翻開瀏覽burpsuite的歷史記錄中，準備一個一個數據包看看的時候，一個被敏感信息插件標綠的可疑數據包引起我的注意。
通過對該數據的重放發現，該數據包在登錄用戶選擇時，會對服務器的用戶信息進行查詢，并將用戶的敏感信息一并帶出，造成敏感信息泄露。這一波操作，開發真的整了一套好活。
在json返回的數據中，發現存在passowrd的字段，后面的數值推測是加密后的登錄密碼。看起來比較像base64編碼，但是嘗試解開失敗，應該還是與前端相同的SM4方式。這個好辦，因為之前注意到這個網站在登錄時就使用了密文密碼，因此直接將數據包中泄露的登錄密碼拿來用即可。
使用對應管理員用戶的密文密碼放到登陸數據包中，成功獲得登錄所需要的token。
在cookie editor中對token內容進行修改，利用在js文件中找到到的后臺地址，成功登錄到監控系統。
進入網站后，需要對網站的各個功能點進行測試。本次運氣比較好的是，在后臺找到一處文件上傳點，仿佛看到getshell的希望。
在測試的過程中，發現該上傳點在服務器端使用了黑名單限制，在前端進行繞過失敗，上傳jsp以及jspx后綴文件會引起500報錯。
嘗試上傳txt、cer、html等文件都可以，但是服務器端會對文件名進行修改。這里需要注意的是linux服務器對文件后綴大小敏感，并且tomcat中間件默認情況下是不解析大小寫混寫或者大寫的jsp/jspx后綴文件。
在嘗試了諸多文件上傳繞過的方法未果后，經過大佬指點，注意到該網站使用了JFinal框架。
閱讀網上參考文章，發現是該web框架通過黑名單機制對上傳文件進行攔截，并且在3.8版本及之前都存在很玄學的任意文件上傳。該框架在上傳jsp/jspx文件時，會先上傳到服務器上后，再對這些惡意文件進行刪除。但是當最末行缺少分割的boundary時，會導致刪除惡意文件出錯，造成任意文件上傳。
于是根據POC重新構造數據包，結果還是返回500的錯誤。啊這，是姿勢不對？因為開始懷疑這個漏洞是否還存在，就下意識多點了點了Go按鈕。嘗試訪問upload/svg/加上傳日期目錄下的上傳文件也無果。
一籌莫展之際，對上傳后的路徑目錄進行縮進，正好發現存在目錄遍歷。然后跳到upload目錄下，已然造成了悲劇。
需要注意的是JFinal框架的任意文件上傳漏洞，會將目標文件傳遞到upload目錄下，而非正常的upload/svg/[date]目錄下。
利用該文件上傳漏洞，成功上傳webshell并連接。（灰溜溜的上去先把多余的木馬文件刪除）
