用户
搜索
  • TA的每日心情
    擦汗
    2019-1-31 10:58
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]初来乍到

    官方账号

    Rank: 7Rank: 7Rank: 7

    230

    主题

    230

    帖子

    1951

    魔法币
    收听
    0
    粉丝
    1
    注册时间
    2018-12-21

    i春秋认证

    发表于 2020-1-10 20:00:12 01304

    22.png

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

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

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

    最初的发现

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

    33.png

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

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

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

    44.png

    不过,我还不知道_csrf_sessionID到底意味着什么,是否能用来攻击用户。

    进一步挖掘

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

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

    55.png

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

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

    66.png

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

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

    77.png

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

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

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

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

    利用

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

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

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

    88.png

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

    漏洞流程

    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
    
    发新帖
    您需要登录后才可以回帖 登录 | 立即注册