在寻找安全漏洞时，对未知资产和功能模糊端点的过分探索，常常会使注意力从明显且重要的功能转移开。

接近一个渗透测试目标，就好像你是第一个对它进行安全评估的人，彻底检查一切，我相信你一定会发现一些新的东西——特别是如果你测试的代码已经持续开发了很长一段时间。

我将要讲述的是一个严重漏洞，它影响了PayPal最常被访问的页面：登录表单。

最初的发现

在研究PayPal的身份认证流程时，我注意到一个JS文件，其中包含一个CSRF令牌和一个会话ID：

这立即引起了我的注意，因为在有效的JS文件中，任何类型的session数据都预示着危险。

在所谓的XSSI（跨站脚本包含）攻击中，一个恶意Web页面可以通过<script>引入跨域脚本，从而访问文件中包含的任何敏感数据。

果然，我通过一个快速测试证实了XSSI漏洞，尽管每个请求上中的变量名都被混淆，但关键的令牌仍然可以一眼看到，你可以轻松提取出来。

不过，我还不知道_csrf和_sessionID到底意味着什么，是否能用来攻击用户。

进一步挖掘

通过在PayPal平台上无数次尝试用_csrf的值替换身份验证请求中的常规CSRF令牌之后，我得出结论，这个和CSRF攻击无关。而更不幸的是，受害者的_sessionID也不足以劫持他们的帐户。

接下来，我又开始研究那个JS脚本，试图查找出它们的实际用途。为此我深入了PayPal的防止暴力破解的机制，虽然这个机制在很多页面都有使用，但我主要关注登录表单。

机制很简单：在几次登录失败之后，就会出现reCAPTCHA挑战，成功后才能再次验证身份。当然，肯定会有人对这种机制进行安全研究。

在检测到暴力破解后，下一次身份验证请求的响应只包含一个谷歌reCAPTCHA页面。如果用户通过了验证，就向/auth/validatecaptcha发送一个POST请求。

在以上请求中你可以看到类似的_csrf和_sessionID参数，其他参数我稍后会介绍。

通过谷歌验证，意味着重新进行正常的身份验证流程。因此，接下来的响应包含一个自提交的表单，其中有用户在登录请求中所提供的所有数据，包括用户的电子邮件和纯文本密码。

我意识到，通过恰当的时间和一些用户交互，了解以上请求中使用的所有令牌就足以获得受害者的PayPal凭证。在真实的攻击场景中，唯一需要的用户交互就是受害者对攻击者控制的Web页面进行一次访问。

于是我试图找出缺失的参数如何填充，这比预期的要容易：

• jse参数根本没有进行验证。

• recaptcha参数是谷歌在用户解决recaptcha挑战时提供的令牌。它并没有绑定到特定的session，因此，任何有效的令牌——例如某些自动破解服务产生的令牌——都可通过验证。

利用

综上所述，我创建了一个PoC，除了captcha自动破解服务外，它演示了整个攻击流程。

首先，PoC（恶意网站）将利用最初的XSSI漏洞获得一组令牌。随后，它将发出一些不可能成功PayPal身份验证请求，模拟暴力破解，触发安全挑战。

此时，一旦受害者使用相同的浏览器登录到PayPal，缓存的错误凭证将被用户自己的电子邮件和密码所取代。最后，攻击者获得一个新的reCAPTCHA令牌，通过向/auth/validatecaptcha发出请求来获得明文密码。

后来我发现，在一些未经身份验证的结帐页面上也存在相同的漏洞，会导致***数据泄露。

漏洞流程

PoC连同所有漏洞信息都于2019年11月18日提交给PayPal的漏洞悬赏计划，18天后通过HackerOne验证。

在PayPal团队的快速确认和一些额外交流后，我在12月10日获得了15300美元的赏金，CVSS分数为8.0，这也在我预测范围之内。

大约24小时后，修复补丁出现，这意味着这个漏洞在PayPal发现它5天后就被修复了——相当不错的修复周期。

修复

/auth/validatecaptcha端点现在需要一个额外的CSRF令牌，不能使用跨站脚本包含所泄露的令牌。

虽然漏洞被修复，但我觉得，如果一开始密码并没有明文传输，那么这个漏洞本来是可以避免的。

本文由白帽汇整理并翻译，不代表白帽汇任何观点和立场：https://nosec.org/home/detail/3870.html
来源：https://medium.com/@alex.birsan/the-bug-that-exposed-your-paypal-password-539fc2896da9