新類型【漏洞】驗證碼大小可控導致的拒絕服務攻擊漏洞
來自專欄誠殷網路
23 人贊了文章
前言
這個漏洞是我在挖掘某工信部下面的某個眾測平台，發現他們的驗證碼參數大小可控，在那一晚突然而來的靈感，目前大多數CMS的漏洞和SRC,都已經刷完了才公開的，所以不會對市面上大型企業造成影響，針對大型企業比較好的伺服器，還是需要上千個才能解決。
1. 這個漏洞不能幫你獲取到敏感信息
2.這個漏洞不能幫你獲取到shell
3.這個漏洞沒有啥利用條件
利用過程
今天這裡以PHPcms為例子，講解一下。
首先我們來到PHPCMS的
第一步
會員登錄頁面：http://192.168.1.101:81/index.ph ... /index.php?m=member
然後驗證碼處單擊右鍵
獲取該鏈接。或者將網址替換到下面鏈接地址。
http://192.168.1.101:81/api.php?op=checkcode&code_len=5&font_size=14&width_=120&height=26&font_color=&background=
第二步
在得到了上面的鏈接地址之後呢 我們進行如下修改
http://192.168.1.101:81/api.php?op=checkcode&code_len=5&font_size=14&width_=120&height=26&font_color=&background=
將其中的參數：
font_size
width
height
改為：
font_size：1000
width：1000
height：1000
然後得到鏈接地址
http://192.168.1.101:81/api.php?op=checkcode&code_len=5&font_size=1000&width_=1000&height=1000&font_color=&background=
第三步：返回值大小判斷是否存在
Burp開起來，訪問上面的鏈接
http://192.168.1.101:81/api.php?op=checkcode&code_len=5&font_size=1000&width_=1000&height=1000&font_color=&background=
抓取數據包
Ctrl+R 將數據包放到重放功能，以方便做測試
當我們點擊了Go之後看紅色圈中處會有一個數字。
8112 bytes
這個可以代表我們當前從服務端返回到客戶端的數據包大小，這樣理解即可。
然後我們在請求包中修改一下參數
看圖改數據
接著繼續。我們看一下返回的數據包大小是否與 1000 有差距
可以看到我們的返回包的數據大小已經變為了：
23759 bytes
與上次的結果相差了萬多。
那麼證明其存在漏洞
在這裡給各位說一下注意的要點：
1. 其中返回的數值 與我這裡不一定相等，也就是你測試其他網站的數據返回值與我的估計不是一樣的，我們主要測試 1000 與 10000 返回的數據包大小是否有相差值，如果你的相差值只有幾百，那麼不代表就存在。如果存在的話，他們的相差值是非常巨大的。
第四步：怎麼造成DDOS攻擊？
通過上面的測試我們知道了漏洞存在，如果我們發送一個10000的數據包到伺服器，伺服器需要 10s 時間來處理，那麼我們如果發送 10 個 10000的數據包呢？
10x10 = 100s
也就是伺服器需要花費100s時間去處理，當我們發送 100 個這樣的數據包（當然你千萬不要用100個數據包扔過去，一般來說經過測試結果 20-50個就能導致網站癱瘓。）
第五步：看一下伺服器CPU有何變化？
伺服器當前Apache進程Httpd的進程CPU情況如下
為 0 狀態，現在我們開始發送數據，先發一個 10000 的數據包我們看看。
可以看到 CPU 損耗 50 % ，我當前配置為 2核3G
如果 發送 10個 10000的數據包呢？
最後發送 10 個，發現還是在 50%左右，於是我加了一個 0 。發送了大概 5 ， 6條 100000 的數據包，達到了預期效果
可以看到伺服器 CPU 已經 100%了。成功達到了攻擊的目的性。
結後語
如果一個 0 不能解決，那麼就再加一個 0 ，直到問題解決，如果一個包沒效果，那麼就來兩個 ，或者 20個，200個。
推薦閱讀：