在寻找安全漏洞时，对未知资产和功能模糊端点的过分探索，常常会使注意力从明显且重要的功能转移开。接近一个渗透测试目标，就好像你是第一个对它进行安全评估的人，彻底检查一切，我相信你一定会发现一些新的东西——特别是如果你测试的代码已经持续开发了很长一段时间。下文将要讲述的是一个严重漏洞，它影响了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令牌，不能使用跨站脚本包含所泄露的令牌。
虽然漏洞被修复，但我觉得，如果一开始密码并没有明文传输，那么这个漏洞本来是可以避免的。
转自：白帽汇
快到碗里来吧！扫码或者点击阅读原文了解详情↓↓↓。
本文资讯内容来源于互联网，版权归作者所有，如有侵权，请留言告知，我们将尽快处理。
关于安全帮®
安全帮®，是中国电信网络与信息安全研究院旗下安全团队，致力于成为“SaaS安全服务领导者”。目前拥有“1+4”产品体系：一个SaaS电商(www.anquanbang.vip) 、四个平台（SDS软件定义安全平台、安全能力开放平台、安全大数据平台、安全态势感知平台）。
原文始发于微信公众号（安全帮）：寻找PayPal密码泄露漏洞（15300美金）
