實戰筆記:滑動驗證碼攻防對抗

一、背景介紹??

在業務安全領域,滑動驗證碼已經是國內繼傳統字符型驗證碼之后的標配。眾所周知,打碼平臺和機器學習這兩種繞過驗證碼的方式,已經是攻擊者很主流的思路,不再闡述。本文介紹的是一個冷門的繞過思路和防御方案。這些積累,均來自于實戰之中,希望有用。

二、思路介紹

知己知彼,百戰不殆。

如果不清楚攻擊者的手段,又如何能制定防御方案?

滑動驗證碼繞過思路

漏洞名字:session參數重復校驗漏洞

思路介紹:

此思路來源于一次對黑產路徑的溯源復現,由于每次拖動滑塊后,會發送一個Request請求數據包到服務器,服務器會驗證這個Request請求數據包里攜帶的位移參數,來判斷是否是拖動滑塊到了正確的缺口位置。而服務器接收的數據包有很多,除了你發送的,也還會有其他人發送的請求,所以需要一個session參數來作為標識。本文中的”rid”值就是一個session標識。

其中”rid”值是加引號的,因為它只是一個參數。針對不同的滑動驗證碼廠商,可能參數命名不一樣。

漏洞詳情:

在用戶客戶端完成一次正確的驗證碼滑動后,發送到服務器的session參數,會在服務器后端,默認隱含生成一個有效時間和一個有效次數的值。前提條件是正確的滑動。想想這里會不會存在問題?

曾在黑盒測試中發現,有的滑動驗證碼廠商的后端邏輯設計存在缺陷,一個session參數的有效時間是10分鐘,有效使用次數是5次。那么如何利用呢?這是我在風控后臺的真實業務環境下,挖掘到的一條黑產繞過滑動驗證碼的手法。

思路剖析:

首先,觸發滑動驗證機制,如下圖類似。

接著,滑動滑塊到正確缺口位置,然后抓包。

分析數據包,尋找session參數。通過測試找到”rid”值為session參數。

這里再強調一下,不同的廠商開發的代碼,可能對session參數命名不一樣。比如下圖,”sessionId”值是另一家廠商的session參數,需要我們去分析判斷。

每次滑動正確位移后,使用Brupsuite或者其它中間人代理工具,抓包提取數據包里的session參數(”rid”值),保存到本地。

因為服務器后端默認隱含對我們本地保存的session參數有一個有效時間和有效次數,所以我們不需要再去滑動驗證碼,直接在session的有效期內發送Request請求數據包到服務器即可驗證成功!

上述操作,我用python編寫了一個小工具使其流程化。全自動化過程:調用打碼平臺滑動驗證碼滑塊到正確位置,使用python的mitmproxy庫配合正則提取rid,并寫入保存到本地rid.txt。

最后黑產在實際批量注冊,薅羊毛或刷贊過程中,遇到觸發的滑動驗證碼機制,只要session在有效期內,只需使用python讀取本地的rid.txt內容,調用requests庫發送請求數據包,即可繞過滑動驗證碼。

至此,滑動驗證碼繞過思路剖析完成。

滑動驗證碼js接口XSS攻擊:

眾所周知的跨站腳本攻擊—XSS,攻擊手法可能很平常,但把常用的攻擊手法用在一個不被人注意的地方,有時候會給你意想不到的效果。

在某次實戰中,對一個安全公司的真實后臺登錄頁面做黑盒測試。

首先,給到的只有一個這種后臺登錄頁面。

對常規的地方進行一番測試后,并沒有發現什么脆弱缺陷。既是一家安全公司,安全防護做的比較高,也是意料之中的事。在屏幕前發了很久的呆,沒有思路的時候,喜歡倒退,會回到滲透測試最本質的起點,信息收集。

因為這家公司做的是業務安全,了解到這個后臺是一個風控數據監測的登錄后臺。

風控面對的業務場景有:注冊、登錄、瀏覽,支付,活動等。

面對的威脅有:惡意爬蟲、批量注冊、薅羊毛、盜號撞庫等。

風控策略有:限制注冊登錄頻率、惡意IP識別、驗證碼等。

【惡意/正常行為】——【風控策略】——【業務場景】,風控在其中扮演者中間人的角色,無論是一個正常用戶的行為還是群控設備的惡意行為,風控一方面會使用策略進行過濾行為,另一方面會將惡意/正常行為會被記錄到日志中,進而在后臺展示。

至此,信息收集完畢,我們整理一下思路。

我們先看一下手里拿到的測試頁面,再對比分析一下上面那段信息。

我們發現這個登錄頁,是有滑動驗證碼的。而對比上面的信息,我將紅色框圈出來的文字,構建了一個我的漏洞測試想法。如果我能控制滑動驗證碼的輸入,那在后臺的輸出也可能將是可控的。紅色框圈出的最后四個字,“后臺展示”,第一反應就是用XSS攻擊手法再合適不過了。

開始行動

首先,找到獲取滑動驗證碼的js接口

 

分析接口參數

找到以下參數:

channel,appId,orgaization,lang,data,sdkver,callback,model,reversion

黑盒XSS——FUZZ

刷新驗證碼,截斷,抓包。

蠻力碰撞,直接把所有的參數的值替換成XSS payload,但這樣往往容易失敗,因為有些參數是硬編碼,一旦更改,服務器返回的respnse就會直接顯示reject拒絕。

舍近求遠,9個參數,抓9次包,分別替換參數值成XSS payload,最后,幾分鐘后,成功打到了cookie。

(因為XSS平臺更新,當時的記錄未保存)

因為是黑盒測試,在漏洞修復后,內部人員把后臺觸發漏洞的位置告訴了我。

下面這張圖是,風控后臺的滑動驗證碼記錄的行為信息展示欄,未修復之前這里有一列language的值,就是參數里的”lang”,而插入的XSS payload也就會出現在這個位置。

由于開發人員未考慮到這個隱秘的js接口,所以未做過濾防護,且未申明http only,導致XSS payload可以順利執行。

最后,在黑盒測試盲打XSS中,很大一部分靠運氣。但使用極限語句再配合一個超短域名的XSS平臺,會增加成功率。

風控防御方

滑動驗證碼可能會部署在:注冊、登錄、反爬、支付等場景當中,而黑產繞過滑動驗證碼的技術會有很多種,但凡只要有一種是當前風控策略未考慮的情況,就可能會造成比較嚴重的損失。

攻擊手法總結

從黑產/攻擊者的角度,針對滑動驗證碼,我們介紹了一種繞過的思路:session參數重復校驗漏洞,一種攻擊的手法:JS接口的XSS攻擊。

那么,從風控/防御方的角度,我們如何制定防守方案呢?才疏學淺,不敢無稽之談,只能把平時實戰之中碰到的問題,記錄下來,希望有用。

被動防守——針對攻擊者

這里沒什么特色,既然是被動防守,自然是要避免亡羊補牢。針對諸如XSS等OWASP TOP漏洞,不能依賴開發的細心。除了在業務上線之前,內部測試和攻防測試;還可以在在業務上線之后,托管類似國外Hackone平臺的國內賞金平臺,或自運營SRC。當然,結合考慮預算成本。

主動出擊——針對灰黑產

主動出擊,針對的是利用滑動驗證碼,來精準識別灰黑產。

在上一篇文章實戰筆記之X廠滑動驗證碼漏洞挖掘里最后一節,提到了多缺口、滑塊多樣化的方案。

在一次滑動驗證碼更新升級過程中,發現了一個新思路。

原始過程:在用戶完成一次驗證碼滑動后,將request請求數據包發送給服務器。

升級方案:在服務器后端升級滑動驗證碼的js代碼,使每一個滑動驗證碼都在用戶客戶端生成一個或多個隨機參數,這些隨機參數需要跟隨request請求發送到服務器進行一個簡單邏輯驗證。重點在于:正常用戶只有通過滑動滑塊發送的request數據包才一定是攜帶隨機參數的,但并不強制要求發送的request請求攜帶這些隨機參數。

精準識別:因為核心圈的黑產下放的工具,都是通過直接通過發送request請求數據包來進行批量注冊、刷量刷贊和惡意爬蟲等行為。稱之為:“協議刷”或“打接口”,這種方式效率極高。加上利益化的原因,黑產不會去在乎過程,只在乎是否結果能成功。

升級的方案:只有通過正常滑動滑塊,才能發送攜帶隨機參數的request數據包發到服務器。

舊方案:通過以前的舊接口直接發送不攜帶隨機參數的request數據包到服務器也可以通過驗證。

在無聲無息升級后,兩種方案并行運行,那么拐點就到來了。

是不是就意味著舊方案的驗證碼接口過來的ip,sdk,captcha_flag等數據一定都是源于黑產池;而升級方案的驗證碼接口過來的ip,sdk,captcha_flag等數據不說百分百,也絕大部分都是來自正常用戶群體。這就悄然無聲的就達到了精準識別灰黑產的目的。

持續化:在被黑產發現后,就需要做持續化更新的對抗了。

還是那句,攻防本身就是一場不公平的戰斗,或許只要能大大增加黑產攻擊者的成本,就是有效果的防守。

三、總結

以上理論,皆為實戰總結。希望有用。

如果沒有,我想下篇或許會有。

【via@freebuf.com