記錄一次利用業務設計缺陷漏洞的精彩實戰測試

本篇文章主要講述在zzcms8.2中挖掘到的漏洞，已經有大佬寫了這個cms的代碼審計，當然，其他的平台也有人寫了。所以，既然寫了，那麼肯定是與他們的文章有所不同，漏洞也不同，攻擊方法也不同，讓讀者讀有所獲。（新手可以考慮認真看看，後半部分有對於新手來說非常精彩的攻擊演示）

漏洞集合

目錄跳轉讀取敏感信息

在zzcms8.2/baojia/baojia.php的第四行，引用了zzcms8.2/inc/top.php這個文件，如圖：

我當時追蹤了一下這個文件，發現這個文件在引用的時候，首先就進行了if邏輯判斷，而if邏輯判斷中，又有可控變數。因此，我當時咋一看的時候，就很懷疑這裡，感覺這裡總可能存在一些問題。如圖：

於是，我就打開網頁看了一下，順便抓個包瞧瞧。結果一看，哎，有點意思，代碼是如果接受post請求，那麼就執行跳轉操作。而我們主動發送的請求是get，那就說明這個漏洞黑盒是百分之八九十測不出來的。黑盒又不知道這裡居然還可能有post請求，就算測試post請求，也不知道參數是什麼，因為前端壓根沒有這裡的參數。

在我的上一篇文章中，我也有個感覺黑盒測不出來的漏洞，但是評論區大佬有人留言說黑盒能測出來，我仔細想了想，的確也有可能，因為當時那個漏洞前端能找到參數。

可是，這裡就不一樣了，無法猜測。莫名其妙的我就對白盒有了點小自豪，哈哈。回歸主題，既然伺服器端接收post請求，那麼我就將get請求包利用burpsuite改造成post請求包。

將get請求包的數據格式以及內容改成post之後，我先嘗試了構造xss，但是經過幾次嘗試，發現被html編碼，單引號被轉義。這就很尷尬了。

於是轉換思路，既然是跳轉，那麼能不能跳轉到敏感文件？或者跳轉到遠程文件呢？如果要按跳轉思路，那麼必須要進行截斷。而在目錄跳轉中，問號偽截斷比較通用，不受版本限制。

如圖，我構造了這樣的post請求包：

由於進行了偽截斷，所以我這裡執行的跳轉就是跳轉到伺服器根目錄，讀取我本地的伺服器根目錄敏感信息：

我不清楚真實的網站根目錄下是否也會存在這樣的漏洞，但是，如果存在，那麼危害還是挺大的。

比如，目標網站有cdn，但是你根據這個漏洞就可直接發現目標網站的真實IP，在本地進行域名和IP綁定後，就可以直接繞過cdn。

邏輯漏洞導致個人敏感信息泄漏

在zzcms8.2/baojia/baojiaadd.php的183-213行中，如果在用戶的cookie中獲取到用戶名，那麼將會提取出該用戶名的個人信息，回顯到瀏覽器頁面。

比如公司名（這個感覺不重要），真實姓名，手機號碼，emai。後面這三個信息我個人感覺是很重要的。會利用的人能利用出各種花樣，這裡我們只交流技術，不談那些非法利用，因此這裡如何利用這些信息我就不寫了。

下圖是我回顯出的測試信息：

漏洞復現的方法非常簡單，只要你設置COOKIE的UserName為資料庫中真實存在的用戶名，那麼就會得到該用戶的這些信息。

下圖，瀏覽器中的cookie信息

下圖，該王二狗用戶在我的資料庫中真實存在：

為了更加嚴謹一點的證明這個漏洞，我又註冊了一個test2用戶，並且註銷了test2用戶的登錄。然後，構造請求包：

成功獲得test2用戶的敏感信息：

前提是我資料庫中存在註冊過的test2用戶：

設計缺陷漏洞+CSRF=累死管理員並且讓網站業務無法正常運行！（前方高能）

唉，本來是挖漏洞的，結果邊挖漏洞，邊給人改BUG。。。

這裡插入的欄位資料庫中根本沒有，導致發布功能壓根無法實現，原因就是classid，被錯寫成了classzm。。。想挖這的漏洞，還得給他先改好BUG。。。幫助這個cms實現功能，我才好測試功能是否有漏洞利用。。。

所以，我個人是不建議新手費勁心思來挖這套cms，因為還有其他地方的功能存在錯誤，比如點擊目錄跳轉的鏈接會顯示「該文件不存在」，原因是程序員的跳轉路徑寫錯了。。又比如驗證碼壓根不顯示，為了方便測試，我只能注釋掉檢驗驗證碼是否正確的代碼。。所以，對於這套cms，新手隨便挖幾個洞就可以了，代碼能力不強的要想練習改BUG技能，可以認真對待這套CMS。

言歸正傳，在對baojiaadd.php的測試中，我發現同一用戶可以反覆的發布報價信息，雖然發布報價信息需要得到管理員的審核，但是並沒有對發布報價信息的用戶做出數量限制或者其他的限制（普通驗證碼在一些大佬眼中可以直接利用機器學習識別的，我這裡由於驗證碼的功能並沒有實現，所以我就直接後台注釋了驗證碼，在此前提下，有了後面的攻擊實驗），那麼這就給「調皮」的用戶留下可乘之機。

比如，我大量的發送具有迷惑性質的報價信息，讓這些信息存入資料庫，並且讓讀取這些信息的審核人員無法分辨是否是真實用戶，那麼這個漏洞就完全可以嚴重影響該網站的業務。所以，我給這個漏洞的評價是「高危」

漏洞出現的文件在zzcms8.2/baojia/baojiaadd.php中的183-242行以及

274-313行。

我圖片中沒截取到的代碼部分，是我覺得不影響理解漏洞，利用漏洞，所以就沒截取。

上面兩幅圖實際上是我說的第二個漏洞，邏輯漏洞，但是當時只能讀取用戶私人敏感信息，在這裡，因為我寫的exp順便就讀取了個人敏感信息，需要用到那個邏輯漏洞的判斷邏輯，所以我就截取了，方便大家閱讀。而且之所以用到這個漏洞，是因為正規網站不會讓遊客發帖，而這裡貌似是可以的（我沒刻意去追蹤不偽造cookie能否發帖的文件，感興趣的讀者可以自己嘗試），為了保險起見，我就當作偽造cookie才能發帖。

下面兩幅圖是伺服器端的處理邏輯

最後，附上我寫的偽造數據包之「洪水攻擊」exp腳本，第一次寫exp，寫得不好多多見諒！功能就是根據我們想偽造數據包的個數，進行個人信息偽造，同時列印返回包（返回包中能看到邏輯漏洞中的敏感信息，我沒寫正則，所以讀者可以自己改造）

exp腳本：

簡單說明一下，我寫的這個exp只是雛形，如果你想偽造的更像，更難以排查，更難以被審核人員過濾，那麼我腳本中的那些變數，list，你可以加以改造，增加他們的數量以及不同的值，利用暴力破解的思路組合成新的個人信息，就像生成新的字典那樣。另外，由於我這個是邊測試邊編寫的，因此裡面有不少的注釋以及我注釋掉的測試代碼。。。大家將就著看吧。。

exp腳本攻擊演示：

輸入數字後，就會一直發送數據包，直到發送5個為止，會出現提示結束的信息。這裡可以在返回的html代碼中找到邏輯漏洞的敏感信息，用正則能匹配出來，我腳本中沒寫。。。懶了。。。感興趣自己寫吧。

為了證明我們的攻擊是有效的，我下面提供我的資料庫截圖：

像這裡的用戶信息，都可以通過改造我的exp或者讀者自己寫exp來實現。注意看我這裡偽造的地址，電話，郵箱，是不是很真實？其他的值也都可以做到這種地步，我這個exp只是提供思路，進行簡單的攻擊演示。

總的來說，我覺得這個漏洞應該屬於設計上的缺陷吧，不知道讀者是怎麼定義這個漏洞的。

另外，我一開始就覺得這裡還有有CSRF漏洞，因為按道理來說，進行這類操作最好都要先token驗證一下，可是這裡並沒有驗證。在說點題外話，在我我進行CSRF頁面構造的時候，遇到一個urf8編碼的坑，導致我一度以為這裡引用了token機制，但是怎麼看前端源碼，伺服器源碼都沒找到token機制。無意之間在html中看到自己寫的中文變成了亂碼，才忽然想到可能是編碼問題導致我CSRF總是失敗。於是我改了自己CSRF利用頁面的源碼，果斷成功！

下面是我CSRF攻擊頁面的源碼：

綜上所述，攻擊思路就是：在訪問流量比較大的網站掛上有CSRF攻擊的偽造網頁（可以做的逼真一點，我這裡並不逼真），或者想其他方法引誘大流量的互聯網網民來到你這個CSRF攻擊頁面，誘導他們點擊觸發CSRF攻擊的按鈕，讓所有訪問這個大流量網站的人亦或是訪問這個CSRF頁面的人，都去瀏覽zzcms這個站並且發布報價信息。同時，自己在本地利用腳本，對目標進行惡意發布報價的「洪水攻擊」（不知道怎麼形容，就這樣用洪水攻擊形容了）來掩蓋正常用戶的正常發布報價的業務請求，同時也要能夠儘可能的迷惑審核報價信息的管理人員，讓其無法輕易利用腳本或者過濾機制分辨哪種報價信息是真實用戶的業務請求，哪種報價信息是攻擊者惡意偽造的。

只要有用戶進入我們這個CSRF頁面，便會自動生成偽造信息。只要用戶點擊我們這個CSRF頁面的小電影「開始播放」按鈕，那麼就會向zzcms站發送一次請求，報價信息便會存入zzcms的資料庫中，混淆其他的真實數據，影響網站業務，累死負責審核信息的管理員～

看下圖，偽造的信息成功進入了資料庫：

我點擊了兩次CSRF頁面的播放按鈕，所以就生成了兩條不同的數據。由於點擊完，還會再次刷新到此CSRF頁面，若用戶第一次點擊不明所以，還有可能再點擊一次。那麼在流量非常大的情況下，就等於將非常大的流量放大兩到三倍去攻擊zzcms站點。可以說，很恐怖了。

如果想最大限度的進行DDos攻擊，那麼還得補充相關知識，比如，什麼情況下伺服器解析最慢？我這裡只提供思路。。因為我技術有限。。。留下來沒技術的淚水。。。

總的來說，這思路結合了DDos攻擊、無線網干擾中的「洪水攻擊」思路，同時結合一些欺騙的藝術以及利用網站的邏輯漏洞/設計缺陷來完成的一次精彩攻擊。（儘管我偽造的頁面很簡陋，但是也不失為一次精彩的攻擊，不是嗎？）

額，剛好由於我投稿的時候，可能是當時太累了，圖片複製粘貼的居然有一些是外鏈。。也沒提示，標題也有點敏感，導致審核失敗，正好借這次修改機會，再多說兩句。再次強調，因為這套cms的驗證碼功能有bug，我為了方便測試就將其注釋掉，但是，對於普通的驗證碼，一些大佬完全可以做到識別，因此，這篇文章的精髓在於攻擊的思路。如果說硬要加上驗證碼，那麼CSRF的攻擊以我的技術就無法實現了，因為我不知道如何在CSRF的時候，還能同時獲得正確的驗證碼（ajax的思路可以嗎？）。除非網站的驗證碼做的很BT，否則，只要能識別，那麼我們的python腳本就依舊可以「泛洪」一下。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！