0x00 360Quake牛刀小試
在對某廠商進行授權安全測試時，苦於尋找資產，於是利用360quake的title搜索語法進行搜索邊緣資產。
搜到疑似該廠商的一個邊緣站點。根據經驗，像這種界面的系統一般多多少少都有漏洞。
因為站點只有一個后台界面，所以我們的漏洞利用點一般先是尋找爆破弱口令賬戶，或者是找到一處全局越權。最好是弱口令賬戶。經過一些列的賬戶爆破處理，並沒有一個有效用戶可利用。於是乎只能寄托於能不能搞到這套系統的相似源碼或者框架。
這時候，我注意到之前quake搜索出來的結果。在360quake當中，對存在ico的站點會在搜索欄下告知站點ico的md5值。根據favicon的圖標，我猜測這不是一套原生框架。
刪除對應的title關鍵詞，可以根據favicon來搜索使用同套相似框架的站點。
當然假如quake沒有給出這個站點的icon值，你也可以根據 curl http://xxxx.com/favicon.ico|md5sum的方式，得到站點ico的md5，然后利用quake語法，favicon:"{MD5}"搜索。
運氣較好，在quake的第一頁就發現了和廠商使用同樣cms，並且明示用了什么框架的站點：jeecg-boot。
0x01 如何利用360quake搜索相似站點，並獲得源碼
這里一般我們搜索相似源碼的站點有以下幾種方式：
- 1、
根據favicon搜索 - 2、
根據首頁頁面里的一些特征，利用body:"{特征}"來搜索 - 3、
根據response里的header頭特征來搜索，一般是在cookie里有設置特定的cookie。比如shiro的rememberMe=xxx，或者apache的ofbiz。
搜索到相似站點后，有幾種方式搞到源碼：
- 1、
對相似站點進行入侵，getshell后獲得源碼（動靜較大） - 2、
對相似站點批量掃備份文件 - 3、
得知cms的名稱去凌風雲網盤搜索該cms源碼是否有人分享 - 4、
閑魚搜有沒有對應源碼有人在買賣 - 5、
去github，gitee搜有沒有相似的源碼，是否是根據別人的源碼二次開發的成品
0x02 步入正題，如何搞定這個cms。
這里我們搜索到jeecg-boot是github上開源的成熟項目，項目成熟，不代表沒有漏洞。成熟項目有成熟項目的好，就是有人會去發現漏洞，然后告知到github的issue上，你只要祈禱你遇到的站點不是最新版本就行。項目不成熟，只能你自己審計代碼，好處就是用的人少，相對有漏洞的概率就大。
根據 https://github.com/zhangdaiscott/jeecg-boot 項⽬可知，該項⽬是由java基於 springboot開發的。所以我第⼀時間閱讀了這個項⽬的README。
舒服，有fastjson和shiro，還有我熟悉的springboot的。
首先，登錄抓個包。
符合站點描述縮寫的，確實是可能使用了fastjson，整個response和request里的url都有springboot的氣息。
因為知道有shiro，但是shiro版本⼤於是1.4.0。所以有那個paddingoracle的漏洞，也有⼏個
shiro配合springboot的url繞過漏洞。整理下⼏個漏洞的利⽤條件。
paddingoracle的漏洞利⽤條件：
- 1、需要登錄后的rememberMe的值，也就是說需要賬號密碼。
shiro的url驗證繞過：
- 1、不需要利⽤條件，但是前提是作者那樣⼦配置認證⽅式，其次就是
你有對應的后台漏洞的url。
第⼀個paddingoracle暫時利⽤不了，只能從第⼆個shiro繞過找辦法。
因為是1.4.0所以那個
反序列化還是存在的。因為只是key隨機化了⽽已，查看項⽬，並沒有設置固定的key，所以
⽤⼯具沒跑出來key。
於是乎，根據前面提到的，我們在issue上找到⼀個最近的sql注⼊漏洞。 https://github.com/ zhangdaiscott/jeecg-boot/issues/1887
先看看這個url在未登陸下是啥情況。
提示重新失效。然后根據shiro的最近⼏個未授權漏洞進⾏fuzz。當發現下圖情況時候，返回碼不
⼀樣了。說明已經繞過了shiro認證。
根據issues⾥的圖⽚請求，進⾏填寫剩余的get參數。成功獲取到數據。
注⼊點在code=處。mysql數據庫。
注入點很明顯，直接可以用sqlmap。 --is-dba
然后下載源代碼，看看有沒有upload的漏洞。找到⼀處新版被注釋掉的上傳代碼（大概率可能有洞才被在新版注釋掉）。
// @PostMapping(value = "/upload2")
// public Result<?> upload2(HttpServletRequest request, HttpServletResponse response) {
// Result<?> result = new Result<>();
// try {
// String ctxPath = uploadpath;
// String fileName = null;
// String bizPath = "files";
// String tempBizPath = request.getParameter("biz");
// if(oConvertUtils.isNotEmpty(tempBizPath)){
// bizPath = tempBizPath;
// }
// String nowday = new SimpleDateFormat("yyyyMMdd").format(new Date());
// File file = new File(ctxPath + File.separator + bizPath + File.separator + nowday);
// if (!file.exists()) {
// file.mkdirs();// 創建文件根目錄
// }
// MultipartHttpServletRequest multipartRequest = (MultipartHttpServletRequest) request;
// MultipartFile mf = multipartRequest.getFile("file");// 獲取上傳文件對象
// String orgName = mf.getOriginalFilename();// 獲取文件名
// fileName = orgName.substring(0, orgName.lastIndexOf(".")) + "_" + System.currentTimeMillis() + orgName.substring(orgName.indexOf("."));
// String savePath = file.getPath() + File.separator + fileName;
// File savefile = new File(savePath);
// FileCopyUtils.copy(mf.getBytes(), savefile);
// String dbpath = bizPath + File.separator + nowday + File.separator + fileName;
// if (dbpath.contains("\\")) {
// dbpath = dbpath.replace("\\", "/");
// }
// result.setMessage(dbpath);
// result.setSuccess(true);
// } catch (IOException e) {
// result.setSuccess(false);
// result.setMessage(e.getMessage());
// log.error(e.getMessage(), e);
// }
// return result;
// }
構造請求包：
根據代碼，看下上傳到哪⾥去了。
${jeecg.path.upload}
可惜，這個站點的biz不可控，文件只能上傳到和webapp同⽬錄下的upload⽬錄，那在web的URL下是訪問不到我們的上傳文件。如果是上傳到webapp下⾯，那就可以訪問到。
0x03 后續滲透思路
- 1、利用注入點，新增or修改后台某個賬戶為弱口令。
- 2、利用弱口令賬戶登入系統，獲取到rememberMe的正確值，使用shiro的paddingoracle的JRMP的gadget進行攻擊。
- 3、看了下項目，作者提供了便捷的docker方案。So后續滲透getshell后有大概率是在docker里。
0x04 總結
- 1、在日益艱難的web項目滲透下，利用現有的資產搜索引擎可以更好的幫我們掌握目標站點的情報。
- 2、現在的入侵都不是一步水到渠成，往往需要迂回而上，越了解目標的環境，越有機會拿下目標站點。