在寻找安全漏洞时,对未知资产和功能模糊端点的过分探索,常常会使注意力从明显且重要的功能转移开。
接近一个渗透测试目标,就好像你是第一个对它进行安全评估的人,彻底检查一切,我相信你一定会发现一些新的东西——特别是如果你测试的代码已经持续开发了很长一段时间。
我将要讲述的是一个严重漏洞,它影响了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
来源:freebuf.com 2020-01-10 20:02:49 by: 白帽汇
请登录后发表评论
注册