【轉載】記錄一次滲透測試

轉載自https://www.secpulse.com/archives/57606.html
團隊 一枚 老司機的奇葩司機思路，發出來讓你們看看 他到底有多老司機！

對他老司機這一件事，我能怎麼辦，我也很絕望呀！

我和你們同樣看文章之前 都是一枚不明真相的吃瓜土狗

可是如今呢，皮皮蝦咱們走！

滲透範圍
系統 XXXXX網
URL http://XXXXX/login.jsp
接到公司下發的受權滲透測試項目任務，咱們的老司機同事把油門加滿了。
基礎信息收集服務器環境

關鍵信息
服務器環境 Linux ,csvserver, Apache Tomcat
程序語言 Jsp
關鍵端口 80,8010,8087,8899
關鍵信息
泄露關鍵字 xxxxxxxxxxxxx, xxxxx

系統功能枚舉
系統後臺(http://XXXXX/login.jsp)

忘記密碼(http://XXXXX/XXXX/XXXX.jsp)

SQL注入漏洞
http://XXXXX/XXXX/XXXXX.jsp?prename=XXXX=1' or '1'='1
參數：mobile,prename,loginName
類型：boolean

因爲自動化工具SQLmap不能識別注入點，且因爲注入語句的限制，只能獲取部分信息，
編寫程序獲取到mysql數據庫的用戶:

帳戶信息收集Google Search
關鍵詞: xXXXg,xxxxw

驗證用戶
經過嘗試登陸系統後臺驗證用戶存在與否。

admin帳戶不存在，嘗試使用收集到的關鍵字進行猜想。

xXXx這個用戶是存在的，因此如今拿到了系統的用戶名。
嘗試爆破密碼信息收集
通過對服務器其餘端口的信息收集，在80端口上運行的服務和8010端口上的服務是相似的，程序有多是同一個公司開發的(xxx科技？？？)，再次利用XXX嘗試登錄系統，發現這個用戶也是存在的。
分析登錄請求
經過客戶端的js代碼，發現登錄採用DES加密

把加密算法放在前端，廠家我就想問你

廠家：

普通的登陸請求都是明文直接登陸，能夠利用burpsuite很方便進行爆破，可是這裏採用用戶名和密碼都加密的方法，讓爆破工做難度增大了許多，要編寫程序進行爆破可能又要花費不少時間。因此須要另尋他法。

該系統還有一個安全問題，系統對登陸的用戶名和密碼進行加密發送，目的頗有多是爲了防止網絡竊聽攻擊，採用DES加密自己是相對比較安全的，可是在分析加密過程發現系統把默認的加密key放在了客戶端，還有在http流中明文傳輸key，因此攻擊者徹底能夠竊取key對密文進行解密，獲得明文帳戶密碼信息。
(MDZZ)
尋找新爆破點
http://xxxxx//xxxxx/XXXXX.jsp

在信息收集階段，發現系統有一個隱藏了的功能，就是修改密碼，這個修改密碼的過程並無採用加密的方式，因此能夠經過修改密碼驗證舊密碼的正確來進行爆破密碼。（安全脈搏https://www.secpulse.com/archives/57606.html）
這裏有一點要注意的是若是咱們爆破到正確的密碼時，系統正好也就修改了原來的密碼，因此必定要先記錄下修改後的密碼是什麼。
此外，若是爲了避免讓管理員知道本身的密碼被更改了，能夠在爆破的過程當中，直接把新的密碼填寫爲咱們的爆破值。
爆破工做
對上述爆破點進行爆破，嘗試了6000多個經常使用弱密碼，可是很遺憾，並無一個是正確的密碼，因此爆破工做結束，並不能如願以償。。。。

系統邏輯分析
經過前期的信息收集工做，發現系統在前臺的功能不多，都是一些靜態的內容，嘗試在前臺挖掘可能存在的安全漏洞，幾個端口運行的web服務上，的確發現存在上傳文件的功能，在「XXX」的系統功能上。（安全脈搏https://www.secpulse.com/archives/57606.html）
經過測試發現上傳功能對上傳的文件名進行了限制，而且系統的處理邏輯使得即便繞過了文件擴展名的限制，也沒辦法訪問到上傳的文件(訪問上傳的文件會提示文件不存在)。

滲透項目到這裏，簡直江郎才盡，太特麼尷尬了。。。。
再次回到咱們的忘記密碼功能上，來看看這個地方是否存在除了SQLinject以外的其餘安全問題。

思考:系統對忘記密碼的邏輯是怎樣的？
首先咱們看不到源代碼，因此這裏只能對處理邏輯進行猜想，想辦法讓猜想的結果儘量地接近系統的源碼。
首先，當咱們輸入用戶名和手機號碼的時候，程序應該是獲取數據庫中用戶名(xxxx)的數據，並比較用戶的手機號碼和咱們輸入的是否是相同，若是找不到，就提示輸入的信息有誤，假設找到對應的用戶了，那麼程序就會把密碼發送到對應的手機上。
這個處理邏輯是沒有問題的。咱們要知道用戶XXXX的密碼，那麼就得知道對應的號碼（號碼是：1XXXXX5，別問我怎麼來的），而且可以拿到手機接收到的短信。這看起來很難，固然也確實挺難的。

可是若是咱們能控制系統把密碼發送到 咱們的手機 呢?

系統在驗證用戶名和手機後是怎麼給手機發信息的，安全的作法應該是拿到數據庫中對應用戶的手機號碼，而後發送信息。
可是系統這樣作了嗎？？？？
很顯然是沒有的，要否則我這個逼早就裝不下去了。。。。。。
(MDZZ)
既然系統沒有取數據庫中的手機號碼，那麼就是從客戶端的輸入獲取手機號碼，也就是手機號碼可被控制。
可是直接輸入想要收短信的手機號碼，會致使用戶名和手機號碼的驗證不經過。
那麼怎麼才能經過驗證又能把密碼發送到咱們的手機上呢?

若是結合以前的SQL注入漏洞呢?

爲何這樣就能夠達到想要的結果呢？看看系統的邏輯的僞代碼。
usename=get(用戶名);phone=get(手機號碼);query_str=」select * from user_table where username=’」+username+」’ and phone=’+phone+」’」;res=mysql_query(query_str);if(res) send_pw_to_phone(phone,…);else return error;

成功結合SQL注入 致使直接不用校驗手機號 最後把密碼發送到輸入處的手機號（也就是咱們的手機上）

後臺GetShell
用戶密碼：xxxx/xxxxxx6
http://xxxxx/xxxx/xxx/xxx?txxxxx=1492570302687
文件上傳

POST /XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=1.jspx&fileSize=0
POST http://XXXX/XXX/XXXX?ownerId=ff8080815b8319f0015b842ff87f00d0&ownerName=visitAttach&ownerClass=VisitContent&unzipAttach=undefined&filename=1.jsp&fileSize=0

系統採用黑名單限制文件擴展名，可以使用jspx繞過限制，apache默認解析jspx文件。

SHELL
http://xxxxxxx/bed58ce10310421cbc654ee45239e2d4.jspx密碼：pxxxxxxxxx

一張圖總結和警示本身

Now Game Over !!!

有感受打碼的安全脈搏小編很強，一看就是那種專業打碼30年的！ 可是對於老司機來講這都不算事，閱片無數 心中天然無碼