我雖不是人類:且看我如何攻破Google的ReCAPTCHA

寫在前面:
本文是對I’m not a human: Breaking the Google reCAPTCHA的翻譯。論文中簡單介紹了Google的ReCAPTCHA服務,然後主要針對其中兩種驗證碼方式提出了繞過或攻擊方案,並做了模擬測試。

關於ReCAPTCHA的簡單介紹,可以看我的這篇Break Google ReCAPTCHA: ReCAPTCHA科普

此分割線以下是全部譯文,自己翻譯,歡迎勘誤。


驗證碼從誕生之日起,就被廣泛地運用在阻止攻擊者的不合法操作上。儘管驗證碼能在一定程度上攔截攻擊者,但是在經濟利益的驅動下,各種針對驗證碼的自動化攻擊方式層出不窮,驗證碼服務也相應地做出改進。然而最近,出現了一種針對文字驗證碼的通用攻擊方式。Google也適時地公佈了reCaptcha的最新版本。最新版本有雙重目標:一是減少合法使用者通過驗證碼認證的成本,二是提供了對計算機來說,比文字識別更具挑戰性的驗證碼。ReCaptcha是由一個“高階的風險分析系統”驅動的,這種系統能分析收到的請求,並挑出適合難度的驗證碼返回給使用者。使用者可能需要勾選一個checkbox,或者需要挑出描述相同內容的一組圖片。

在這篇論文中,我們對reCaptcha做了系統研究,也對使用者請求的方方面面是如何影響風險分析系統做判斷的。通過大量的實驗,我們發現一些缺陷,攻擊者可以通過這些缺陷輕鬆地影響風險分析系統,繞過驗證碼限制,進而實施大規模的攻擊。接下來,我們利用對圖片做語義註釋的深度學習技術,設計了一種比較新奇同時又低成本的攻擊。我們的攻擊系統非常有效,能夠自動解決70.78%的圖片reCaptcha,每個驗證碼的認證只平均只耗費19s。我們對Facebook的圖片驗證碼也做了測試攻擊,成功率達到了83.5%。基於我們的實驗所得,我們針對我們的攻擊,提供了一系列的保護和改善措施。總之,我們的研究專注於reCaptcha,我們的發現也有非常廣的影響。因為對圖片所傳達的語義資訊的邏輯自動化處理越來越多,越來越頻繁,所以,驗證碼也必須順應趨勢,在更新奇的方向上做更深的探索。

1 理解Recaptcha

Google提供的reCaptcha服務是使用最廣泛的驗證碼服務,許多主流網站都用它來攔截自動化機器的不合法攻擊。Google指出,最新reCaptcha機制的部署,具有更高的使用者友好度和安全性。

網頁控制元件

當訪問一個被reCaptcha保護的網頁時,會顯示一個小網頁控制元件(如圖1(a)所示)。為了避免被第三方分析,這個小控制元件的JavaScript程式碼是被混淆過的。當這個控制元件用來收集使用者瀏覽器的資訊併傳送給後臺伺服器。而且,它還會進行一系列的檢查,來核實使用者的瀏覽器。

工作流程

一旦使用者點選了checkbox,瀏覽器就會給Google傳送一個請求,這個請求中包括(i)Referrer,(ii)網站的sitekey(註冊reCaptcha是獲得的),(iii)提供給google.com的cookie,和(iv)執行此控制元件的瀏覽器收集到的檢查資訊(加密的)。高階風險測試系統會分析這個請求,然後決定該給使用者什麼型別的驗證碼。

使用者點選checkbox之前使用者點選checkbox之後
(a) 使用者點選checkbox之前(b) 使用者點選checkbox之後

圖 1. reCaptcha網頁控制元件

reCaptcha提供的相似圖片驗證碼
圖 2. reCaptcha提供的相似圖片驗證碼

驗證碼型別

針對不同的使用者,會使用不同的驗證碼型別。對於特定的信用較低,或者頻繁請求的,或者輸錯了很多答案的使用者,會使用更難的驗證碼。在我們的測試中,我們遇到了以下型別的驗證碼:

  1. 無驗證碼的reCaptcha”[圖 1]。這是一種新版本的驗證碼,正常使用者可以毫無壓力地解決這樣的驗證碼。當使用者點選過控制元件上的checkbox之後,如果高階風險分析系統認定此使用者的信用度高,則認為此使用者直接通過了驗證。本文以下將這種驗證碼稱作checkbox驗證碼。
  2. 圖片reCaptcha”[圖 2]。這種新版的圖片驗證碼要求使用者識別出相似的圖片。這種驗證碼包括1張樣本圖片和9張候選圖片,使用者需要從候選圖片中選出和樣本圖片相似的圖片。這種驗證碼中也會包括一個關鍵詞,這個關鍵詞就是對使用者應該選的那些圖片特徵的概括性描述。通常需要使用者從候選中挑出2到4張圖片。
  3. 文字reCaptcha”[表 1(a)到(e)]。這些扭曲的(譯註:這裡原文中distored有誤,應該是distorted)文字,就是高階風險分析系統為那些被認定為信用度較低的使用者提供的。在使用者點選checkbox之前,如果使用者機器在某些的瀏覽器檢查中失敗了,那麼分析系統就會返回給使用者類似(e)這種可靠的驗證碼,網頁控制元件會自動收取並顯示此驗證碼。因為這種驗證碼能被機器所識別,但是對於正常使用者卻不太友好,所以,在過去的六個月裡,文字驗證碼似乎正在被逐步地“被淘汰”,現在圖片驗證碼通常被作為預設的驗證碼型別被返回。

    表 1. 文字reCaptcha的一些既有例子

(a)t1_a(b)t1_b
(c)這裡寫圖片描述(d)right-aligned
(e)這裡寫圖片描述

解決方案

從驗證碼顯示的時刻開始,使用者有55秒的時間來解決它。否則使用者需要重新再來一遍:再次點選checkbox,再次收到一個新的驗證碼。一旦使用者點選了驗證碼,一個叫做recaptcha-token的HTML欄位就會被儲存在token中。如果使用者被認定是合法的,不再需要驗證碼來驗證,那麼這個token也就會被Google的伺服器認可。這個token會被提交給網站,來獲得伺服器的認可。網站會通過reCaptcha API傳送一個確認請求,這個請求中包括:(i)一個共享金鑰,(ii)一個響應token和(iii)一個可選的使用者IP地址。如果收到了這個請求的響應,就代表認證成功了。

2 對風險分析系統的分析

這一節,我們探索了Google高階風險分析體系,並且鑑定如此大量的使用者資訊和使用者瀏覽器資訊的特徵值是怎麼影響它的。我們使用黑箱測試,來鑑定我們的系統和測試環境的各個方面是怎麼影響風險分析的。我們的目的就是,發出高階風險分析系統認定為合法的驗證碼請求,這樣,我們就能收到最簡單的checkbox型別驗證碼,只需輕輕一點就能通過驗證。

2.1 瀏覽歷史

Google的追蹤cookie在應該呈現給使用者什麼難度的驗證碼的決策中起著至關重要的作用。有一些合法使用者,正是因為他們本地的某種特定的cookie,保證了他們只需要通過checkbox驗證即可;我們設計的測試方案,就是為了找出什麼樣瀏覽歷史記錄是這樣的特定cookie所需要的,我們不僅要找出是哪些,而且要把這些瀏覽歷史的必需量降到最低。我們研究了多重網路連線的啟動,以及能夠生成瀏覽歷史的活動。我們在我們的分網和US出口節點的Tor網路上都做了測試。我們用自動的方式,在Google上搜尋某些關鍵詞,訪問搜出來的那些結果,看Youtube上的視訊,搜尋Google地圖,訪問包含Google 外掛或控制元件的一些主流網站。令人驚奇的是,我們在第9天一早生成的cookie能夠讓我們獲取checkbox驗證碼,不需要表2中列舉出來的任何瀏覽活動和網路連線型別。我們的測試還發現,每一個cookie能在一天中收到最多8個checkbox驗證碼。

表 2. 構造追蹤cookie和“模擬”使用者行為

NetworkWeb SurfingAccountThreshold
DepartmentalFrequentNo9th day
DepartmentalModerateNo9th day
ToRFrequentNo9th day
ToRModerateNo9th day
AnyNoneNo9th day

2.2 瀏覽器環境

為了發現可以的瀏覽器屬性或行為,reCaptcha控制元件執行了一系列的檢查。儘管控制元件的JavaScript程式碼已經被混淆了,但是反混淆的程式碼現在也已經被髮布了,通過反混淆,我們就能清楚地知道它具體做了什麼樣的檢查。這裡,我們探究了我們的自動的瀏覽器環境的各個方面是怎麼影響風險分析的結果的。

表 3. 我們系統使用的和使用者機器包含的不匹配資訊的組合

Component9-day CookieSystem runsUser-Agent reportsCaptcha
BrowserFirefox/36.0fMobile/8C148 Safari/6533.18.5, Chrome/42.0.2311.135 Safari/537.36gimage
Browser versionFirefox/36.0Firefox/f10.0, 35.0, 36.0, 3.0.12gcheckbox
Browser versionFirefox/36.0Firefox/f10.0, 35.0, 36.0gimage
Browser versionFirefox/36.0Firefox/1.0.4fallback
Browser versionChrome/42.0Chrome/f15.0.861.0, 4.0.212.1gimage
Browser versionChrome/42.0Chrome/3.0.191.3fallback
Engine versionChrome/42.0; AppleWebKit/537.36AppleWebKit/f528.10, 530.5, 531.3gfallback
Engine versionChrome 42/0; AppleWebKit/537.36AppleWebKit/f532 and upgimage
Engine version✔/✘Firefox/36.0; Gecko/20100101Gecko/20040914image
Engine versionChrome 42/0; AppleWebKit/537.36Chrome 42/0; Gecko/20100101fallback
Browser/EngineFirefox/36.0; Gecko/20100101Firefox/36.0; AppleWebKit/537.36image
Browser/Engine✔/✘Linux x86 64f(Macintosh; Intel Mac OS X 10.8;), (Android; Mobile;), (Windows NT 6.3;)gcheckbox
wrong format or incomplete informationfallback
Linux x86 64; Firefox/36.0Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420 (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3checkbox

Canvas著色

Canvas著色是一種既有技術,用來跨機器或瀏覽器識別使用者。reCaptcha的JavaScript程式碼建立一個canvas節點並構造成一種預定義的結構。著色完成之後,當使用者點選checkbox時,這個canvas節點會被編碼成base64格式,連同其他資料傳送回伺服器。這些資訊可以被瀏覽器的著色功能使用,來確定瀏覽器的版本,然後和使用者機器登記的資訊做對比,發現不同之處。

使用者機器

為了確定使用者機器如何影響使用者的信用度,我們按特定的情況分組,在每組中做同樣的測試。我們發現,如果使用者機器的瀏覽器或者瀏覽器引擎的版本太低,控制元件就會自動認定環境可信度太低,然後給使用者返回一個可靠的驗證碼(表 1-(e))。如果瀏覽器或者引擎是最新的版本,但是和實際的測試環境的版本不相符,控制元件還是會返回一個可靠的驗證碼(例如,如果我們使用的是Firefox,而之前登記的是Chrome)。當使用者機器上的資訊沒有被正確的格式化時,返回的還是可靠的驗證碼。

螢幕解析度和滑鼠

我們測試了不同螢幕解析度的各種組合和各種滑鼠行為的配置(指標的移動速度和模式)。這些對風險分析系統的決策沒有任何影響。

2.3 網站限制

如果我們能夠解決我們控制的一個網站(attacker.com)的驗證碼,但是這些驗證碼卻能將我們獲取的token和目標網站(example.com)關聯起來,這樣,我們就能提高攻擊的命中率。利用這樣的方式,驗證碼破解服務能構造有效的token賣給別人,從而降低網路活動量,也就是說,降低了攻擊的成本。這種簡單明瞭的點選劫持式的攻擊已經被證實。為了攔截這樣的攻擊,reCaptcha被重新設計,來保證token是和提供驗證碼的網站繫結起來的。除了檢查Referrer之外,控制元件還會通過document.location.hostname來檢查網站,這個document.location.hostname是隻讀的,不可能被攔截而出現安全問題。我們提供了一種變通方案來繞過這個限制。我們在我們的伺服器上構建了一個虛擬主機,給這個主機起了一個和example.com一樣的名字和其他必要的配置。通過使用a2ensite和修改hosts檔案,我們可以在虛擬主機上執行我們的網站,欺騙reCaptcha來把我們的請求和example.com關聯起來。為了完整我們的攻擊,我們還需要傳送目標網站的sitekey,這個sitekey能從網站的網頁原始檔中輕易地得到。

3 簡單的驗證碼破解器

目的是為了構造看起來像是合法使用者生成的而不是機器人自動生成的cookie。每一次,我們都在一臺乾淨的虛擬機器上建立cookie,虛擬機器上的瀏覽器自動系統沒有儲存google.com的任何賬號的cookie。

3.1 獲取Token

我們還研究了網站是否會禁止我們使用同一個IP地址去獲取大量的cookie。我們在一天內建立了63000個cookie,沒有任何問題,瓶頸僅在於機器的硬體效能。這表明,用同一個IP地址去獲取大量的cookie是沒有任何限制的。我們發現的唯一的限制是大量的併發請求(例如,檢測到DoS洪泛攻擊)。至今為止,沒有任何攻擊是依賴於建立大量的cookie的,所以導致了對於這種單IP建立大量cookie的保護措施的缺失。沒錯,我們確實發現了一種能讓攻擊者有利可圖的,通過濫用追蹤cookie的攻擊方式。

3.2 評價

接下來,我們在這些cookie“成熟”之後部署了我們的系統,來看看我們一天內能解決多少checkbox驗證碼。我們在不同的驗證碼請求頻度下做了測試,發現隨著請求頻度的上升,準確率成下降趨勢。最後,儘管系統被阻塞了很短的一段時間,但在最佳的請求頻度下,我們一個小時內收到了大概2500個checkbox驗證碼,在最高的請求頻度下,一個小時大概是1200個。我們發現,週末時的阻塞會更少,一天能獲得大概59000個checkbox驗證碼。

4 圖片驗證碼

這一節,我們研究新的Google圖片驗證碼,展示我們在測試中發現的各式各樣的特性。攻擊者可以利用其中的一些特性,來解決圖片驗證碼,我們的目的就是找到這些可能被利用的特性。

4.1 圖片驗證碼方案的靈活性

我們探索了,在判斷驗證碼方案是否正確時,reCaptcha是否具有靈活性。在任何情況下,至少需要選出兩張圖片,然後才會傳送回覆響應。我們手動地用不同的正確圖片數(n)和錯誤圖片數(k)的各種組合來嘗試通過驗證碼驗證。在大多數情況下(74%),我們發現正確的候選圖片數通常是2個;其餘的多是3個,我們也發現有兩個驗證碼裡有4個正確的候選圖片。我們的測試發現,即使少選了一個正確圖片,或者多選了一個錯誤圖片,使用者仍然能通過驗證。基於這些結果,我們按照選3個圖片來設定我們的驗證碼破解系統;這樣的破解策略能保證,在正確的圖片數為2時,我們仍可能通過驗證碼的驗證。

最終,我們的實踐結果證實了我們策略的正確性,圖片驗證碼確實具有一定的靈活性,在表4中展示了我們發現的總是會返回true的各種結合方式。

表 4. 通過圖片reCaptcha的組合情況

Image SelectionConstraintPass
n Correct k Wrongk ≤ 1
(n – 1) Correctn > 2
(n – 1) Correct k Wrongk > 0

4.2 重複的圖片

在我們的測試中,我們遇到過幾次不同的驗證碼中存在相同的圖片的情況。有時我們也遇到完全相同的兩個驗證碼:完全相同的圖片,甚至完全相同的圖片順序。這暗示我們,這些驗證碼不是被“即時”建立出來的,而是從一個相對較小的驗證碼庫中挑選出來的。

我們也發現,驗證碼間可能會重複部分圖片。然而,在多數情況下,這些圖片的MD5值都是不相同的。因此,我們使用感知的雜湊方法,來歸類那些即使MD5不相同,但是卻具有相同含義的圖片。我們發現了20%的重複圖片。最多的重複了12次。

5 圖片驗證碼破解器

最近在計算機領域可謂是碩果累累,並且已經有人開始把這些最新的成果利用在圖片識別服務上了。這些識別服務也變得更有效,適用面也變得更廣,所以我們探究,究竟我們能不能把它們用在解決圖片驗證碼上。

為了解決一個圖片驗證碼,我們的系統必須能夠自動地判斷,哪些候選圖片和樣本圖片在語義上是相符的。收到一個圖片驗證碼後,我們解析樣本和候選圖片,標記樣本圖片的語義資訊(例如,“wine”)。然後,把所有的圖片都傳給一個圖片註釋模組。

5.1 圖片註釋服務與庫

有幾款線上的服務和庫能提供這樣的功能:通過對無描述的圖片加標籤(關鍵詞)來做圖片分類。

GRIS

Google Reverse Image Search是由Krizhevsky等人建立的,提供了基於圖片的搜尋服務。如果搜尋成功了,它可能會返回一個對此圖片“貼近真實情況的”描述(見圖3),同時會返回這個圖片出現過的一系列網站列表。儘管這不是Google的公用API,但是我們通過瀏覽器除錯識別出了這個搜尋URL,並把此功能用在我們自己的模組上。在對9個候選圖片做搜尋的同時,我們還收集了與這些圖片相關的網站的網頁標題作為備用資訊。在條件允許的情況下,我們同樣獲取了每張圖片的更高解析度的版本,這會幫助提高圖片註釋模組的準確度。如果返回得描述資訊不是英文,我們就用Google翻譯的自動語言識別功能,將它們翻譯成英文。

ImageGRISAlchemyClarifaiTDLNeuralTalkCaffe
Browserwine and bloodwine, glassglass, red wine, wine, merlot, liquid, bottle, still, glassware, alcohol, drink, wineglass, beverage, pouring, white wine, cabernet, taste, leaded glass, dining, party, vinored wine, goblet, wine bottle, punching bag, beer glass, perfume, balloona glass of wine sitting on top of a tablered wine, wine, alcohol, drug of abuse, drug, red wine, punching bag, beaker, cocktail shaker, table lamp

Clarifai

這是由Zeiler等人在一個反摺積網路上搭建的,對於一張圖片,會返回20個標籤,每個標籤還有信用度得分。

Alchemy

同樣是在深度學習的基礎上搭建的,並且提供了圖片識別的API。對於每一個提交的圖片,這個服務會返回一組標籤,每個標籤都有相應的信用度得分。在我們的測試中,對每個圖片返回了8個很明確的標籤(例如,“wine”)。

TDL

Srivastava和Salakhutdinov利用他們的深度學習系統釋出了一個具有圖片聚類功能的系統。對每個圖片,它會返回8個帶信用度得分的標籤。

NeuralTalk

Karpathy和Fei-Fei開發了NeuralTalk,一個對無描述圖片生成描述資訊的週期性神經網路架構。我們把它返回的描述分解成若干個單詞。

Caffe

Jia等人釋出了Caffe,一個深度學習架構,我們同樣用它來在本地處理圖片。Caffe返回一組共10個標籤:5個最高可信度得分的標籤,和5個可信度得分較低,但是更像是關鍵詞的標籤。

5.2 標籤分類器

返回的標籤並不總是能夠和reCaptcha的圖片驗證碼中的圖片對的上。為了解決這個問題,我們(自主地)研究機器學習,並利用機器學習開發了一個能夠在一組標籤的基礎上“猜”圖片真實含義的分類器。我們使用了由Mikolov等人開發的Word2Vec單詞向量引擎來尋找這些候選圖片標籤和樣本圖片標籤的相似之處。在訓練我們的分類器期間,我們對每一個標籤(候選圖片的和樣本圖片的)在向量空間內建模出一個真實的向量。每一個候選圖片標籤都和樣本圖片標籤配對,然後把所有標籤都作為輸入,傳入我們建立的數學模型。等對分類器的訓練結束之後,它就能通過計算預測樣本圖片標籤和候選圖片標籤的單詞向量之間的餘弦相似性,來分析標籤之間的相似處,從而最終識別出和樣本圖片標籤具有較高關聯度的候選圖片標籤的集合。因此,通過這樣的方式,即使圖片註釋系統提供了不相符的標籤,我們的分類器也能夠識別出相似的圖片。

5.3 歷史模組

驗證碼中的圖片很多都是被重複使用的。正是因為這樣,我們建立了一個圖片的標籤資料庫,來記錄我們遇到過的圖片,和我們分析出來的與之對應的標籤。每一張圖片都和驗證碼中給出的樣本圖片標籤(例如,貓,湯)相關聯。我們同樣維護了一個hint_list,來儲存我們遇到過的所有的樣本圖片標籤。

5.4 方案

每一個模組都會將候選圖片分為三類:selectdiscardundecided。首先,我們通過GRIS收集所有圖片的資訊。然後,如果樣本圖片的標籤沒有被顯示的提供的話,我們就會去找我們的標籤資料庫,看看能不能找到這張樣本圖片的標籤。接下來,歷史模組會去處理候選圖片,同樣是去標籤資料庫中找他們的標籤,如果找到了,就和樣本圖片標籤做比對,匹配的那些,就會被加入select列表。對那些剩下的不匹配的圖片,我們會和hint_list中的那些標籤再做進一步比對,如果匹配上,就會加入discard列表中。接著,圖片註釋模組會去解析所有的圖片,然後給它們打上標籤。同樣,如果和樣本圖片標籤匹配,就會被加入select列表中;如果和hint_list中的標籤匹配,就會被加入discard列表中。對於那些我們利用第三方的公共服務和庫獲取的最佳結果以及網頁標題,我們也進行以上同樣的操作。當所有模組都執行結束後,系統會整合這些模組的子結果。有時,不同的模組對同一張圖片,會給出不同的結果,所以,我們會給子結果賦予不同的“權重”(比如,通過對網頁標題分析得到的標籤,這些標籤權重會比較低)。如果select列表中的圖片數量不夠3個,系統會優先從undecided列表中挑選圖片,來湊夠3個。至於要從中挑選哪個(些)圖片,可能是用我們的標籤分類器來挑選,也可能是挑選那個(些)和樣本圖片具有最相似的(比如,最有共同點的)標籤的圖片。

5.5 評價

模擬攻擊

我們在我們下載資料庫中模擬了驗證碼攻擊。圖4中,展示了每個模組和不同資訊型別的攻擊精確度。這裡,我們使用了我們測試中生成的hint_list,但是沒有用我們的歷史模組或者標籤分類器。

在模擬攻擊中,不同模組與資料的組合對reCaptcha圖片驗證碼的攻擊精確度
圖 4. 在模擬攻擊中,不同模組與資料的組合對reCaptcha圖片驗證碼的攻擊精確度

就像我們之前在表4中展示的一樣,reCaptcha的圖片驗證碼策略是有一定靈活性的,即使我們選錯了一個候選圖片,我們一樣能通過驗證。既然如此,我們就打了個“擦邊球”,把我們的系統設定成挑選3張圖片。圖4中的Pass Challenge顯示的就是攻擊結果。

對於每種模組,在它們基於重合標籤挑選圖片的時候,我們給它們設定了一個最低準則;對於GRIS,它同樣需要用到驗證碼中的樣本圖片標籤和RIS返回的最佳標籤。總的來說,GRIS的命中率受限於我們獲取到的候選圖片的最佳標籤的數量。對於其他的模組,最低準則就是挑出來3張和樣本圖片有最相似標籤的那些候選圖片。當使用樣本圖片標籤、候選圖片的最佳標籤和網頁標題時,Alchemy模組通過了49.9%的驗證碼,Clarifai通過了58%。Caffe同樣很有效,通過45.9%的驗證碼。多數情況下,樣本圖片標籤起著至關重要的作用,依賴註釋系統能提高1.5%到15.5%的準確率。

我們也探究了高解析度的圖片會如何影響圖片註釋模組的準確率。我們通過自動化的方式獲取了700個驗證碼中2909張具有更高解析度的圖片。其中371張是相同的圖片。高解析度的圖片能提高攻擊的準確度,Alchemy和Clarifai分別通過了53.4%和61.2%的驗證碼。TDL的精度稍低,45%,而Caffe則提高到了49.1%。

我們還測試了,如果忽略圖片驗證碼的靈活性,我們的系統是否還能成功通過驗證。因為在多數的情況下,只有兩張候選圖片是正確的,所以我們把我們的系統也修改成了只挑選兩張圖片。圖4中的Exact Solution展示就是忽略靈活性的結果,其中,所有的圖片註釋服務在識別正確圖片方面都相當有效。Clarifai是最有效的,因為它精確匹配了驗證碼中40.2%的圖片,Alchemy達到了31.5%,Caffe達到了28.3%。

標籤分類器

為了量化我們的驗證碼破解系統中標籤分類器的作用,我們基於資料庫中700個圖片驗證碼做了10層迭代訓練和測試。在我們第一次試驗中,我們跳過了所有其他的圖片挑選步驟,單單通過分類器來挑選圖片。對於每一張圖片,分類器接收樣本圖片標籤和一組標籤作為輸入,返回一個“相似度”評分;我們挑選3張最高得分的圖片作為結果。我們的攻擊在精確匹配情景下達到了26.28%精確度,解決了44.71%的驗證碼。在第二次試驗中,我們把分類器放在整個系統中使用,在從undecided列表中挑選圖片時,使用基於分類器的選擇結果,而不是基於近似標籤的選擇結果。當使用分類器的時候,我們使用Clarifai攻擊的平均準確度達到了66.57%,提高了約5.3%。分類器的方式比直接的相似度匹配更有效,因為它識別的是和樣本圖片標籤相關的標籤集合中的特定子集,而不是根據相似標籤劃分出來的簡單子集。而且,分類器方式並不影響攻擊效率,僅僅多耗時大概0.025s。

實時攻擊

為了對我們攻擊準確度做精確測量,我們直接用我們的自動驗證碼破解器攻擊reCaptcha。因為Clarifai在我們的試驗中表現最好,所以我們使用它作為我們的識別服務。
標籤資料庫。我們建立了標籤資料庫來減少重複圖片的影響。我們手動給驗證碼中的3000個圖片打上標籤,每個圖片都有一個描述圖片內容的標籤。我們從我們的hint_list中挑選了合適的標籤。我們使用pHash來做對比,因為它效率很高,能幫助我們的系統在3.3s內就比對了一個驗證碼中的所有圖片。
我們用驗證碼破解器去識別2235個驗證碼,準確率達70.78%。之所以比我們模擬攻擊的準確率要高,部分是因為圖片重複較多;歷史模組從我們的標籤資料庫中識別了1515張樣本圖片和385張候選圖片。
平均執行時間。我們的攻擊非常有效率,破解一個驗證碼平均耗時19.2s。多數的時間耗費在執行GRIS上,因為它會去Google上搜尋所有的圖片並返回結果,包括那些指向更高解析度圖片的網站連結。
離線模式。我們同樣評估了離線模式下的攻擊,我們不使用任何的線上註釋服務或者GRIS;僅僅使用本地的庫、標籤資料庫和分類器。一共使用了兩個庫:NeuralTalk和Caffe。當使用Caffe和我們的分類器時,我們的系統解決了41.57%的圖片驗證碼,每個的平均耗時提高到了20.9s。當使用NeuralTalk時,大概解決了40%,耗時也相當長,達到了117.8s,因為NeuralTalk處理10個圖片需要110.9s。但是,利用GPU來做計算會提高效率,減少耗時。

因此,攻擊者能對reCaptcha的圖片驗證碼部署精確有效的攻擊,並且不需要依賴外部的服務,這些處理大量圖片或報告可疑活動的服務可能會不是免費的。

Facebook的圖片驗證碼
圖 5. Facebook的圖片驗證碼

6 適用性

我們攻擊的原理也適用於其他的情況,通過解析圖片的語義資訊,我們能夠攻擊基於圖片的驗證碼,比如Facebook的驗證碼(圖5)。當使用者給別人傳送包括可疑連結的訊息時,Facebook會要求使用者通過一個圖片驗證碼,只有通過驗證,訊息才能傳送成功。Facebook的圖片驗證碼和reCaptcha原理類似,使用者需要從候選圖片(12張以內)中根據提示挑選圖片。但是也有一些不同。Facebook在HTML裡動態地調整圖片的大小,允許訪問圖片的高解析度版本。同時,沒有樣本圖片。和reCaptcha一樣,它的系統也具有一定的靈活性。正確的圖片數量範圍是2到10張,多數是5到7張。相應地,我們調整我們的演算法,只挑選select列表中的圖片,而不是選指定數量的圖片。

在200個Facebook的圖片驗證碼中,我們基於Clarifai的攻擊達到了83.5%的準確率。比reCaptcha更高的準確率,主要有兩個原因。一是候選圖片的高解析度,二是Facebook在建立驗證碼時,對於不正確的圖片,使用的是毫不相關的圖片。而reCaptcha對於不正確的圖片,選擇的也是同類別的圖片(比如,都是食物,只是種類有些區別),所以更難區分。

7 經濟分析

因為驗證碼破解通常源於經濟利益,我們把我們的攻擊看做是一個驗證碼攻擊服務,從經濟角度分析了我們的發現。

7.1 圖片驗證碼

拿我們的效率和Decaptcher,一個古老的驗證碼破解服務,作對比。我們選擇Decaptcher做對比是處於兩個原因。一,它支援reCaptcha圖片驗證碼,每解決1000個驗證碼收費$2。二,它之前的表現,證明它是準確度最高的驗證碼破解服務。

我們向Decaptcher提交了700個圖片驗證碼,然後測量了響應時間和準確度(利用了圖片驗證碼的靈活性)。有意思的是,Decaptcher拒絕了我們提交的很多驗證碼。

我們提交的一些驗證碼被拒絕了,是因為服務過載了,我們必須過段時間再提交,並且受到了一個在時間視窗期沒有被服務處理的超時異常。258個驗證碼(佔總數的36.85%)成功地精確匹配。當考慮靈活性時,321個(44.3%)驗證碼被解決。平均的解決時間是22.5s。隨著人們越來越適應圖片驗證碼,人工破解的精確度會隨著時間提高,但是不可否認,我們的系統還是一種比較有經濟效益的可選方案。我們的完全離線驗證碼破解系統在準確度和效率上完全比得上專業的破解服務,儘管如此,我們也不會提供給任何攻擊者來獲利

7.2 Checkbox驗證碼

假設每1000個解決的驗證碼收費2美元的話,我們的token攻擊,一個主機(IP地址)一天,能收入104到110美元。通過使用代理服務做並行攻擊的話,這個收入的數字會比單機有顯著的提高。

8 道德宣告

我們把我們的發現和建議報告給了Google,幫助他們提高reCaptcha對自動攻擊的健壯性。根據我們的揭露成果,reCaptcha改變了安全策略和風險分析過程,來緩解我們的大規模token攻擊。他們也移除了圖片驗證碼方案的靈活性和樣本圖片,從而降低了攻擊的準確度。我們也通知的Facebook,但是我們還沒有發現他們做了任何改變。總之,我們希望,通過分享我們的發現,能幫助發起研究者和企業之間關於驗證碼未來的亟需的討論。

致謝

我們的工作得到了NSF的支援,得到了CNS-13-18415的撥款。作者Suphannee Sivakorn現在兼職於泰國皇家科學技術部門。文中的任何觀點、發現、結論或建議都是作者的表述,並不代表US政府或NSF。

引用

見原文。略。