這是 酒仙橋六號部隊 的第 60 篇文章。html
全文共計2420個字，預計閱讀時長9分鐘。linux
引言git
本文內容記錄下某次受權項目中針對企業站點的滲透測試過程，僅僅分享思路，這還要從我拿到一張二維碼提及，須要針對的是一款經過應用寶平臺發佈的企業APP，看到一百多萬的下載量我人都傻了，總之說來話長，那就長話短說吧。由於當時沒有作好截圖記錄，然後整理思路進行復測後將截圖打碼補全，若有雷同，純屬巧合。github
悠哉遊哉web
經過模擬器抓到APP登陸接口的域名，經過內部資產蒐集平臺獲取到相關域名、IP等信息。shell
考慮到須要使用身份證號碼登陸，暫且不考慮從APP入手，不過仍是象徵性的枚舉了一下top1000用戶名，想都不用想這種用戶名確定是不存在的，又不能註冊，可仍是得皮一下，萬一就進去了呢。數據庫
緊接着對子域名進行蒐集，不巧的是隻有mail系統和一個403頁面，還有一個對我充滿惡意的www主域名。json
巧的是我經過搜索引擎發現403系統其實是一個小程序的域名，仍是site大法好，遂準備對該小程序進行邏輯測試，嘗試獲取到用戶帳號權限小程序
因而在身份驗證功能處輸入帳號密碼對用戶進行綁定，這個時候實際上我須要用獲得測試手機號去枚舉一些開發人員在開發時留存且未刪除的一些手機用戶，順便碰碰運氣能不能成功綁定。windows
結果是存在這麼幾個測試用戶的，而且在測試的一些請求包中機緣巧合的獲得了後臺系統地址，既然有了後臺系統，那麼我確定是很快就拋棄了小程序，去嘗試作密碼重置操做，發現枚舉出來的手機號爲管理員。第一步是將驗證用戶名的正確Response保存，data值爲用戶id。
第二步就是驗證管理員用戶信息，只要將Response替換掉而且修改獲取到的指定用戶id，就能成功修改密碼。
重置成功。
成功登陸系統後，發現只有一個相關人員管理功能還有點用。
經過人員管理功能處的查詢接口能夠獲取到人員的password，因而複製下來解密後獲得一些明文密碼。
到這裏好像就沒什麼頭緒了，那就使出github大法，果真搜到一些郵箱地址什麼的，純屬碰運氣，最重要的是發現一個看上去不太好去fuzz的目錄，訪問後是一個登陸系統，這個登陸系統暫時擱置。
好吧那就先採集一波郵箱，再加上用戶名top1000生成郵箱地址，而後對pop3 ssl服務枚舉一波，終究仍是沒錯付！從這裏開始思路就能夠拓展不少，但我仍是想從web層面入手。
因而翻鴨翻翻鴨翻，翻到了一個郵件，裏面給出了測試系統的IP地址。
而後......而後就弱口令登了進來，連號都沒上。
既然是測試系統，那麼應該和生產系統功能差很少，測試了一下，果真目錄什麼的都和主站相同，可是通過top1000字典的一番伺候，仍是沒能進去，因而在測試系統中添加管理員。
關於這個添加管理員的請求包思來想去，最後把host給改爲了www主域名，而後post過去，神奇的事情發生了，不在同一臺服務器上的主站生產環境被加了個管理員用戶，你看，命運它就是這麼捉弄人。
其實就是這個功能沒有校驗管理員用戶的cookie，致使能夠隨意發送請求。因而登陸主站生產系統的後臺，發現後臺功能和測試環境的不太同樣，沒有上傳點，可是看到了有圖片，那麼說明確定不是在後端上傳的，而是用戶上傳後，到後臺進行審覈，遂複製了一些身份證號碼，準備去APP上面測試。
枚舉了一些弱口令用戶，成功登陸了APP，找到身份認證等幾處功能上傳shell，進行一系列繞過測試，可是都失敗了，準備下號的時候，釘釘機器人忽然出現fastjson漏洞提醒。
就這?
安排
成功彈回shell，不巧的是一臺獨立的某雲機器，上面部署的只有一個客服功能。巧的是在BACKUP目錄下發現了開發人員備份的測試版本APP。
展轉反側
因而乎，安裝測試版本APP，果真和新版本APP大有區別，功能沒有那麼多，可是上傳接口不一樣，在身份驗證功能的上傳處能夠經過修改content-type來繞過驗證，最終成功提交身份驗證申請。
可是訪問JSP須要用戶登陸驗證，考慮到用戶Cookie會過時，因此我得從新上傳JSPX，而後回到測試系統後臺查看審覈功能，這時候已經成功上傳了JSPX的SHELL。
而後想到一個問題就是既然能夠從測試系統越權添加主站系統的用戶，那麼也可能存在越權上傳問題，因而測試修改host爲www主站域名，將上傳請求post過去，最終拿到了主站的shell。
左右芼之
經過在~/.ssh/authorized_keys添加本身的公鑰，成功登上了主站服務器，而後frp代理進內網，期間對當前網段進行常規端口掃描，首先整理出ssh服務，幾乎沒有發現什麼web系統。
既上之，則安之，翻了翻數據庫沒有找到什麼對後期滲透有用的信息，最後仍是經過查看history歷史命令獲取到了ldap帳號。
拋棄主站服務器，登陸ldap後就能看到各類人員信息，這個時候路就比較寬敞，考慮到後面百分之百要爆破，因此提早將人員密碼複製出來進行批量解密。
這時候密碼收集的差很少全了，因此從口令角度出發，經過ldap上解密出的人員密碼整合成字典對堡壘機進行爆破。（在登上主站服務器添加本身公鑰的時候，發現了本來有公鑰，且針對端口進行掃描發現是一臺某裏雲的堡壘機）
激動的心，顫抖的手，我上了一臺堡壘機，我不純潔了，由於管理員在每臺機器都導入了這臺堡壘機的公鑰，因此到這裏已經控到了大部分機器，linux機器踩點暫時結束。
接下來仍是按常規操做來，繼續爆破那種能夠簡單又快速的讓你獲取到權限的服務，爆破出幾臺1433數據庫的弱口令。
經過恢復xp_cmdshell組件，對服務器添加管理員用戶，而後登陸後發現是一臺雙網卡服務器，抓完hash走人。
繼續常規操做，經過抓下來的windows機器密碼和ldap收集的人員密碼作成字典，開始爆破其餘網段的smb服務，這樣不至於擠掉正在登陸的用戶。
最終登陸到域控。
總結
整篇文章貌似確實沒什麼亮點，大概過程就是尋找一些能夠利用的資產不論是APP仍是小程序，只要它是一個域名或者是IP能跟目標關聯在一塊兒，就都有它的存在價值，緊接着就是挖掘一些零零散散的常見邏輯漏洞，這裏提到一點方便你們更好的進行測試的一個問題就是不少開發人員的安全意識不到位，會遺留不少測試帳號，這種帳號不論是姓名仍是手機號之類的格式，一不當心就會致使帳號權限丟失，最後被組合利用拿到相關係統權限，最後再到內網滲透，一套下來看似很順利，其實遇到了很多的坑，仍是能感受到信息收集工做的重要性，歸根結底就是1%的經驗+99%的運氣，但總歸是將經驗思路分享給你們，各位師傅不喜勿噴哈哈哈哈。
本文分享自微信公衆號 - Khan安全團隊（KhanCJSH）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。