本文轉(zhuǎn)載于：https://www.freebuf.com/articles/web/290697.html

0x01 前言

寫這篇文章的緣由其實還挺魔幻的，起因是在一次實戰(zhàn)滲透時通過弱口令拿下一個低權(quán)限用戶成功進入后臺，在后臺尋找功能點通過抓包分析，定位到目標(biāo)系統(tǒng)后臺存在SQL注入，通過os shell拿下內(nèi)網(wǎng)之后閑著無聊就谷歌了下，發(fā)現(xiàn)這個系統(tǒng)的開發(fā)商是某某公司，同時cnvd也沒有收錄該產(chǎn)品，于是想著能不能撿漏搞個cnvd證書。

礙于信息檢索能力太差，只收集到屈指可數(shù)的幾個url，而且這幾個系統(tǒng)都沒有弱口令可以進入后臺，因為進不了后臺，就猜測后臺的功能也都無法使用，漏洞無法復(fù)現(xiàn)，于是在知道肯定過不了的情況下還是硬著頭皮只交了幾個url上去（沒記錯通用漏洞需要至少3個以上驗證成功漏洞案例），結(jié)果果不其然，三審的時候給我駁回了。

不甘心，案例找不出來，我把代碼審計一遍還不行嗎？于是就通過webshell打包了一份代碼（因為是.net的站，就只打包了bin包下來），于是便有了這篇文章。

0x02 漏洞利用

還是先簡單聊聊sql注入如何拿下內(nèi)網(wǎng)的吧。（以前的一次實戰(zhàn)，沒有截圖，腦補一下，見諒）

漏洞點抓包

嘗試直接sqlmap拿下--os-shell，苦于沒有絕對路徑，就嘗試百度看看還有沒有其他漏洞，然而網(wǎng)上資料幾乎沒有，就在要放棄的時候從百度文庫中找到一線希望，找到了該系統(tǒng)的使用說明，從說明書中得知系統(tǒng)的mysql數(shù)據(jù)庫安裝路徑和web路徑在同一目錄下，于是通過--sql-shell使用

select @@datadir

獲取到mysql的安裝目錄，同時也就獲得了web目錄，最后就可以直接--os-shell了。

拿到os-shell之后先tasklist，沒有殺軟，不需要免殺；ping了下發(fā)現(xiàn)服務(wù)器出網(wǎng)，基礎(chǔ)操作certutil下載msf馬上線，先用msf上傳一個web shell到網(wǎng)站目錄（感覺拿到web shell后要放心點）。看了下權(quán)限，system，不用提權(quán)了；看了下systeminfo，08的機器，load kiwi模塊，讀取明文密碼；netstat看下3389端口，沒開啟，用注冊表開啟。msf起socks代理，mstsc遠(yuǎn)程連接之。net view看了下沒有域，上傳fscan進行內(nèi)網(wǎng)資產(chǎn)掃描，同時在桌面看到WinScp軟件，而且其中還保存著好幾臺內(nèi)網(wǎng)服務(wù)器，都是root權(quán)限，試了試都能連接上。這里我下了個星號密碼查看器傳上去，想獲取它們的明文密碼，結(jié)果失敗了。谷歌了下，發(fā)現(xiàn)WinScp配置默認(rèn)加密保存在注冊表中，可以修改保存方式為ini文件并用工具破解其密碼，于是修改之后dump到本地通過工具get到密碼。

另一邊f(xié)scan掃到了兩臺服務(wù)器的弱密碼，還有幾臺有redis未授權(quán)漏洞，都可以寫私鑰登錄。

此外，從sql備份文件中又找到另外平臺的賬號密碼。

0x03 代碼審計

從webshell的文件管理處定位到漏洞文件Default.ashx，可以看到調(diào)用了UserInfo.Default這個類。

在bin包中找到對應(yīng)dll文件，使用dnSpy反編譯得到源碼，開始審計。

結(jié)構(gòu)如下：

首先全局搜索一下session關(guān)鍵字，沒有發(fā)現(xiàn)。再在所有外部引用中搜索session關(guān)鍵字，還是沒有發(fā)現(xiàn)，是個好兆頭，說明系統(tǒng)可能沒有對session進行驗證。

代碼第20行，定義ProcessRequest方法并將http請求體作為該方法的參數(shù)傳入，并在第22行定義httpCookie變量存儲當(dāng)前cookie中鍵名為"WCMS.User"的數(shù)據(jù)，可以看到在代碼第23行，程序只進行了三種判斷，cookie不為空，cookie中UserID不為空且RoleID也不為空

只要滿足上述三個條件，程序就會繼續(xù)處理請求，否則才返回204代碼報錯。

這里由于身份校驗不嚴(yán)，導(dǎo)致攻擊者可以在沒有后臺管理員權(quán)限的情況下也能執(zhí)行相應(yīng)操作。審計到這里我興奮起來了，因為之前擔(dān)心系統(tǒng)會對session進行判斷就沒有對另外幾個站點進行復(fù)現(xiàn)，導(dǎo)致cnvd提交被駁回，然而現(xiàn)在完全不需要擔(dān)心了，因為系統(tǒng)根本就沒有對session進行驗證，只需要修改http請求中的host參數(shù)就可以實現(xiàn)漏洞的批量利用。

但是審計到這里還沒有結(jié)束，我們繼續(xù)對sql注入漏洞的成因進行分析。

在代碼第32行，對action參數(shù)進行判斷，我們根據(jù)payload中的Read值，跟進到GetData()函數(shù)

從代碼第190行，不難看出該函數(shù)并未對參數(shù)進行過濾，只進行了是否為空的判斷

在代碼第197行程序還進行了RoleInfoID的校驗，擔(dān)心這里可能會要求提供服務(wù)器中存在的id導(dǎo)致身份鑒權(quán)失敗，我們著重分析下這里

定義一個text變量接收結(jié)果，如果在http form表單中不存在RoleInfoID，就調(diào)用Lib.CommonFunction類中的GetRoleID()方法進行獲取，我們跟進后發(fā)現(xiàn)程序仍然只判斷了cookie是否存在，只有當(dāng)cookie不存在時才會返回為空，導(dǎo)致代碼第198行判斷為假進而導(dǎo)致api返回為空

如果cookie存在，會調(diào)用DESDec()函數(shù)將cookie中RoleID的值進行DES解密，并將結(jié)果保存以待后用。

這里我根據(jù)源碼用c#重寫了下解密過程，并將payload中的RoleID用于解密，結(jié)果最后是亂碼（可能是我代碼沒寫對的鍋...）

然后我用在線的DES工具解密出來又是正確的...（蚌埠住了，我寫的代碼就是屎嗚嗚嗚）

然后我們再回到GetData()函數(shù)，代碼第186行通過Lib.Factory類中的CreateUserInfo()函數(shù)創(chuàng)建了DBHelper對象，并在第205行調(diào)用了GetItems()函數(shù)

通過分析發(fā)現(xiàn)IDBHelper接口由Mysql.DBHelper類實現(xiàn)，跟進到DBHelper類的GetItems()函數(shù)進行分析

代碼第302行，使用for循環(huán)遍歷之前text變量中的值，構(gòu)造sql語句，使用where in語法對查詢結(jié)果進行限定。同時，我們注意到，搜索關(guān)鍵字keyWords到目前為止仍未進行任何的過濾，而且后續(xù)通過分析，發(fā)現(xiàn)開發(fā)者也未在全局使用預(yù)處理和參數(shù)化，導(dǎo)致keyWords參數(shù)易于受到攻擊。

綜上，雖然RoleID會用于獲取子賬號ID，然而如果數(shù)據(jù)庫中不存在該RoleID的用戶也沒有關(guān)系，因為我們的攻擊方式是基于時間的盲注，即使數(shù)據(jù)庫查詢返回為空，也不妨礙我們通過時間比較進行攻擊。因此可以下定結(jié)論，該漏洞在未經(jīng)授權(quán)就可被利用。

整個流程如下圖所示：

0x04 后話

細(xì)心細(xì)心細(xì)心！

總結(jié)

以上是生活随笔為你收集整理的记一次CNVD通用漏洞审计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。