0x01 等保測評項

GBT 22239-2019《信息安全技術 網絡安全等級保護基本要求》中，8.1.4.4安全計算環境—入侵防范項中要求包括：a）應遵循最小安裝的原則，僅安裝需要的組件和應用程序；b）應關閉不需要的系統服務、默認共享和高危端口；c）應通過設定終端接入方式或網絡地址范圍對通過網絡進行管理的管理終端進行限制；d）應提供數據有效性檢驗功能，保證通過人機接口輸入或通過通信接口輸入的內容符合系統設定要求；e）應能發現可能存在的已知漏洞，并在經過充分測試評估后，及時修補漏洞；f）應能夠檢測到對重要節點進行入侵的行為，并在發生嚴重入侵事件時提供報警。驗證碼缺失/繞過對應訪問控制項中要求e），所以安全控制點為入侵防范e。

GBT 28448-2019《信息安全技術 網絡安全等級保護測評要求》中，測評單元（L3-CES1-21） 該測評單元包括以下要求: a）測評指標：應能發現可能存在的已知漏洞，并在經過充分測試評估后，及時修補漏洞。；b）測評對象：終端和服務器等設備中的操作系統（包括宿主機和虛擬主機操作系統）、網絡設備（包括虛擬網絡設備）、安全設備（包括虛擬安全設備）、移動終端、移動終端管理系統、移動終端管理客戶端、感知節點設備、網關節點設備、控制設備、業務應用系統、數據庫管理系統、中間件和系統管理軟件等。c）測評實施包括以下內容：1）應通過漏洞掃描、滲透測試等方式核查是否不存在高危風險漏洞；2）應核查是否在經過充分測試評估后及時修補漏洞；d）單元判定：如果1）和2）均為肯定，則符合本測評單元指標要求，否則不符合或部分符合本測評單元指標要求驗證碼缺失/繞過屬于測評單元（L3-CES1-21）中測評實施的第1項，故定測評單元為L3-CES1-21.1。

0x02 測試內容

通過攔截調用驗證碼處相關數據包，如登錄功能、密碼找回、留言提交等處，測試驗證碼是否有效，是否可以進行繞過或重復利用。

0x03 漏洞原理

驗證碼是什么

驗證碼是一種區分用戶是計算機還是人的公共自動程序。這個問題可以由計算機生成并評判，但是必須只有人類才能解答。由于計算機無法解答驗證碼的問題，所以回答出問題的用戶就可以被認為是人類。

驗證碼有中文字、純數字、英文字母、點擊字符串、圖片圖形、數學運算等等。

驗證碼的作用

?進行人機校驗；

?驗證使用者身份，判斷當前賬戶使用者是否是賬戶的擁有者；

?防止惡意的IP頻繁訪問；

?防止惡意操作導致用戶本身受損失；

?防止暴力破解；

?防止惡意灌水；

?防止刷票；

驗證碼分類常見的驗證碼有：短信驗證碼、語音驗證碼、圖文驗證碼、數字驗證碼等等。形式多樣核心內容一致，根據形式的不同就有了分門別類的應用。具體可看之前寫的文章《滲透遇見驗證碼，跑路？or 拿下它？》。

根據作用可分為以下兩種：

?區分用戶是計算機還是人的公共全自動程序，比如Google登錄時的驗證碼、12306圖片識別的點擊式驗證碼等。

?識別身份的驗證碼，用于識別用戶是否為賬號的所有者，比如短信驗證碼、郵箱驗證碼、電話驗證碼等。

驗證碼繞過

驗證碼大致可通過以下兩種思路進行繞過

1. 識別法：腳本+深度學習、神經網絡的知識；

2. 邏輯繞過，開發人員寫驗證碼校驗代碼時產生邏輯錯誤。

無驗證碼

應用登錄功能未設置驗證碼校驗機制，且無登錄失敗次數過多鎖定策略，這種情況下可直接嘗試進行暴力破解。

驗證碼為空值

有驗證碼機制，但是在請求包中將驗證碼參數刪除，服務器端就不進行驗證碼校驗，會直接校驗賬戶、密碼；或者雖然頁面中顯示有驗證碼機制，但在不填寫驗證碼直接輸入用戶名、密碼的情況下，可直接登錄，存在爆破風險。

萬能驗證碼

0000、1111、8888、000000、123456等，一般多出現于設備、硬件設備。

驗證碼藏于Cookie中

一般情況下系統會將驗證碼的值用Session存儲起來，再通過對比用戶提交的驗證碼和Session中的驗證，就可以知道用戶輸入的是否正確. 但由于Session 會占用服務器資源，有些程序員會將驗證碼的值加密后存儲在Cookie中。針對這種情況，攻擊者可以通過抓取登錄數據包，分析包中的Cookie字段，查看其中有沒有相匹配的驗證碼或者是經過簡單加密后的驗證碼。

驗證碼隱藏于源碼中

記住驗證碼，打開網站源碼，用Ctrl+F搜索，如果搜索到剛才輸入的驗證碼，就說明驗證碼被隱藏于源碼中，接下來就可以使用工具提取源碼中的驗證碼并將其放入每次的請求包中，對用戶名、密碼進行破解。

前端校驗驗證碼

前端對驗證碼進行校驗，相當于沒有設置驗證碼，可通過抓包查看是否有驗證碼傳參，或禁用JS進行繞過。

驗證碼未進行校驗

代碼雖設置有驗證碼模塊，但未對驗證碼進行校驗，隨機輸入就可驗證成功；

驗證碼可控

某些系統獲取驗證碼的方式為通過參數的方式去加載，比如http://www.123.com/yanzhengma.php?code=**** 等，攻擊者就可以嘗試將參數code的值改為undefined，即設為控制；也可以通過便便攜腳本的方式獲取驗證碼并傳入驗證流程。

驗證碼重復使用

應用程序設置了驗證碼校驗機制，但是驗證碼可重復使用，沒有過期限制，相當于無驗證機制。一般是在某一段時間內，無論登錄失敗多少次，只要不刷新頁面或者不刷新驗證碼，就可以無限次的使用同一個驗證碼來對一個或多個用戶帳號進行暴力猜解。換句話說，攻擊者可以在同一個會話下，在獲得第一個驗證碼后，后面不再主動觸發驗證碼生成頁面，并且一直使用第一個驗證碼就可循環進行后面的表單操作，從而繞過了驗證碼的校驗作用，對登錄進行暴力猜解。

驗證碼有規律

驗證碼有生成規則而非隨機驗證碼，比如某些系統會設置驗證碼為時間戳的后6位。

驗證碼包含于返回包中

由于開發在寫代碼時不嚴謹導致通過抓包可在返回包中查看以明文或者簡單加密的驗證碼，這種情況相當于驗證碼直接返回，攻擊者可利用此漏洞進行任意賬戶注冊、任意用戶密碼重置、修改綁定信息等。

驗證碼可識別

若驗證碼過于簡單，就可以使用工具對圖案進行識別，比如驗證碼識別工具Pkav HTTP Fuzzer。

驗證碼輸出至HTML頁面

應用程序登錄功能、找回密碼等處設置了短信/郵件驗證碼校驗機制，但驗證機制存在問題，發送的驗證碼直接輸出到客戶端HTML頁面。

0x04 代碼示例

Pikachu漏洞練習平臺驗證碼繞過（on server） 源碼vulurteforcef_server.php文件中，在用戶名、密碼和驗證碼均不為空的情況下判斷輸入驗證碼是否與生成后保存在session中的驗證碼相同，但比較完后并沒有刪除該session，導致下一個數據包輸入該驗證碼也會判斷正確，出現驗證碼重復使用漏洞。

0x05 測試案例

測試案例1

驗證碼有條件不刷新某些時候會有這種情況：用戶在登錄失敗后，系統會打開一個新的頁面或者出現彈窗，提示用戶登錄失敗，點擊“確定”后返回登錄界面，驗證碼也會刷新。但是這種情況下，只要我們不關閉新窗口、彈窗，直接使用BurpSuite截取登錄請求包，先發送至Repeater模塊，多“Go”幾次，看看會不會返回“驗證碼錯誤”的提示信息，如果依舊返回“密碼錯誤”則說明驗證碼不進行刷新。再將數據包發送到Intruder模塊，把密碼設為變量再進行MD5編碼，就可直接爆破了。

不點擊【確定】

多Go幾次，判斷驗證碼是否會刷新。

將密碼編碼，爆破。

從返回包中可以看到仍舊提示“密碼錯誤”，驗證碼是不失效的。正常使用的時候，直接上弱口令字典跑就是，跟平常的爆破操作一樣。（為寫文章隨變寫了幾個弱口令進行測試截圖）

測試案例2

驗證碼識別抓包查看此系統未采用前端校驗驗證碼，多次刷新驗證碼發現驗證碼易識別，決定采用識別工具進行識別爆破。

右鍵復制驗證碼地址

使用Pkav工具進行驗證碼識別。

確認可以正常識別驗證碼后，對賬號、密碼進行爆破。

0x06 風險分析

?在資金提現、轉賬、充值、修改銀行卡、修改密碼等的重要操作，驗證碼可以啟到防賬戶盜用、篡改賬戶、的作用；

?如果網站有提交表單的功能，并且需要由站點管理員審核才可通過，惡意用戶會產生大量的垃圾表單，影響網站訪問速度，加大工作量，且合法用戶的請求有可能會因此被拒絕服務；

?惡意用戶可利用程序發送短信/郵件的功能，發送大量垃圾郵件/短信，造成短信/郵件轟炸，影響用戶體驗及站點短信服務過度消費；

?通常在網站的用戶注冊、密碼找回、登錄等頁面處使用驗證碼，但當這些驗證碼具有一定的規律性并且沒有做好對應的防護措施時會導致攻擊者通過爆破等方式猜解/繞過驗證碼機制，可導致任意用戶注冊、批量注冊無用賬戶、重置任意用戶密碼、獲取系統權限等危害。

?系統易遭受DDOS攻擊；

?機器人自動批量注冊；

?對特定的注冊用戶用特定程序爆破方式進行不斷的登錄、“灌水”、“刷單”、短信/電子郵件轟炸等；

0x07 加固建議

1. 不要把驗證方式置于前端，手機號和短信驗證碼在服務端進行唯一性綁定驗證；

2. 在服務端限制短信驗證碼發送周期，設置時效性，限制發送次數；

3. 封禁的應該是惡意請求的手機號而不是IP地址，對一天內每一個手機號獲得的驗證碼次數進行限制；

4. 手機驗證碼生成6位或者以上的數字+字母組合的驗證碼，并且保證用后即失效；

5. 禁止用戶自定義短信內容；

6. 在服務器進行有效驗證，手機號和驗證碼在服務器進行唯一性綁定驗證等。

審核編輯 ：李倩