Authentication bypass on Uber’s Single Sign-On via subdomain takeover

TL; DR: Uber通过Amazon CloudFront CDN容易受到saostatic.uber.com的子域接管。此外,Uber最近在auth.uber.com上部署了单点登录(SSO)系统,该系统基于所有* .uber.com子域之间的共享Cookie,被发现容易受到任何受损害的* .uber.com的会话cookie的盗用子域。因此,子域接管的影响可能会增加到Uber的完整SSO系统的身份验证旁路,从而访问受其保护的所有* .uber.com子域名(例如vault.uber.com,partners.uber.com,riders.uber .com等)。 Uber解决了子域收购漏洞,并为两个组合问题授予了五千五百万美元的奖金。

一般来说,SSO系统是以下三种类型的(变体形式):按照人气的顺序:

  • OAuth :安全性主要基于在身份提供者配置的服务提供商的白名单回调URL,以及通过“state”参数进行CSRF保护。缺陷通常是通过打开的重定向链,例如通过OAuth令牌窃取身份验证绕过Airbnb。
  • SAML和朋友 :安全性基于在服务和身份提供者之间使用预先交换的加密密钥签名的XML消息。 缺点通常是XML签名旁路,例如OneLogin身份验证绕过以前位于 Uber的WordPress站点
  • 子域之间的共享(会话)Cookie :安全性基于所有子域的完整性。在SSO系统发布的共享会话cookie中提供攻击者洞察力的任何子域上的任何漏洞都是致命的。因此,缺陷通常是RCE,调试日志曝光,子域名接管和子域名上的朋友,例如通过子域收购对Ubiquity的单点登录进行身份验证

我个人认为,这个名单中的前两名在过去遇到了很多问题,但最近在安全方面有所改善。后一个SSO基于子域之间的共享会话cookie更是一种来自过去的技术,之前的两者甚至存在。通过设计,它强制要求将SSO系统用作与SSO系统所基于的TLD相同的子域的任何内容。由于SSO系统的安全性是基于子域的完整性(见上述报告和Uber案例​​),这是一个颇具讽刺意味的情况。通过设计,它鼓励大幅增加攻击面。

Uber曾经使用OAuth作为* .uber.com子域名的SSO系统,这可以从@ ngalog的最近公开披露报告中看出[Uber 8k Bug]登录CSRF + Open Redirect = Account Takeover 。不过最近,他们已经根据* .uber.com的子域中的共享会话Cookie更改(还原?)到SSO系统。如果您现在浏览到任何需要身份验证的uber.com子域名(例如中心,合作伙伴,车手,保险库,开发人员,...),则可以重定向到auth.uber.com。一旦您登录并访问另一个子域,您就可以透过SSO系统auth.uber.com透明地登录,该系统在登录一次后会为每个* .uber.com子域发布临时会话cookie。

在此SSO系统中发现一个漏洞,允许* .uber.com上的任何受损害的子域透明地发出并窃取由auth.uber.com为* any * uber.com子域名发出的有效会话cookie,只要受害者已经验证一次SSO。 Uber确实采取了一些对策来防止这种情况,但是这些措施被绕过并与子域名接管一起报告,以增加影响。任何受到妥协的* .uber.com子域可以用于执行相同的攻击,尽管Uber在报告时明确地提到了几个* .uber.com子域名超出范围的错误赏金程序策略 (例如* .dev.uber .com,* .et.uber.com,drive.uber.com等)。

子域名接管

Subdomain saostatic.uber.com通过DNS CNAME指向Amazon Cloudfront CDN,但主机名未被注册(悬挂指针)。这让我完全收购该域名,高度相似的子域名上rider.uber.com收购,由于上的Cloudfront不存在分布弗兰斯·罗森 。我有效地将子域名作为概念证明,并托管了一个简单的HTML文件作为证明:

认证旁路

在Uber的SSO系统中,auth.uber.com作为身份提供者,并为https://*.uber.com(“domain = uber.com”cookie属性)临时共享会话Cookie,以向身份提供商(如骑手) .uber.com,partners.uber.com,central.uber.com,vault.uber.com,developer.uber.com等等)。如下面的Uber SSO登录图中可以看到,服务提供商在他们的结束时立即销毁传入的临时共享会话cookie,以防万一发生错误(例如为其他服务提供商颁发)或成功的身份验证,以确保盗窃窗口很小。

因此,珍贵的共享会话cookie“_csid”只能在步骤9-12之间被窃取,这是非常短的时间段(自动浏览器重定向)。尽管并不是不可能利用(参见杰克·惠特顿Jack Whitton)的令人敬畏的CSP技巧来阻止某些Cookie被发送到某些域,巧合地也是在Uber的错误赏金程序中 ),但确定了一个更方便的缺陷,允许共享会话cookie在第12步之后保持活动在浏览器的cookie存储中,在上图中。问题是,如果受害者已经从https://riders.uber.com(图中最后一步12之后的情况)登录,当接收到包含auth.uber中有效的新生成的共享会话cookie“_csid”的请求时.com,它被简单地忽略并保持可用。因此,它在浏览器中保持活动状态,直到其Cookie存储被清除。攻击者只需要在上图中重播第3步作为步骤13,并以https://saostatic.uber.com的其他隐藏请求结束窃取宝贵的会话cookie:

因此,一旦攻击者将他/她的手拿到受害者的“_csid”共享会话cookie https://riders.uber.com,他/她可以在自己的浏览器中执行正常的登录流程,并替换发出的“_csid”cookie在步骤9中的值作为受害者登录,对吧?错误。 Uber还有一个令人反感的对策,即登录跨站点请求伪造保护的变体。这是实际更新的Uber SSO登录图:

这里的问题是GET服务提供商riders.uber.com在步骤3中添加的GET参数状态= CSRFTOKEN和本地作用域状态cookie,并在步骤11中进行验证。由于我们无法从受害者的浏览器中窃取这些值,而是只有“_csid”共享会话cookie,这意味着游戏结束了,对吧?

不幸的是,错了攻击者可以从https://riders.uber.com获取正确的CSRFTOKEN值和附带的状态cookie值,方法是在其末尾启动一个正常的登录方案(例如在自己的浏览器中或通过简单的脚本)。然后,他/她可以在步骤3中将https://riders.uber.com生成的auth.uber.com URL在自己的浏览器中传递给受害者的浏览器,以生成并窃取这些值的“_csid”共享会话cookie,并在步骤9中再次将它们注入他/她自己的浏览器登录场景中。以这种方式,受害者在单独的浏览器中有效地为攻击者的登录方案生成“_csid”临时会话令牌,但是这完美无缺(例如没有IP-遇到步骤之间的基础检查)。这仍然允许以以下方式进行剥削,从而使受害者冒充(我们仍然认为受害者已经登录到auth.uber.com并访问受攻击者控制的网页,所以我们基本上继续从上图) :

概念证明

PoC说了一千多张图。在发送到Uber的PoC步骤中,在下面的视频中显示,假设https://saostatic.uber.com实际上是在受害者的浏览器中提供有效的SSL证书,但情况并非如此。然而, 它可以很容易地通过我们的加密生成

  1. 打开受害者的浏览器并浏览到https://riders.uber.com。在被重定向到https://auth.uber.com之后,请使用受害者的凭证登录,以便您再次在https://riders.uber.com跳闸仪表板上查看。
  2. 在受害者的浏览器中打开第二个浏览器标签,并浏览到https://saostatic.uber.com/prepareuberattack.php。接受您可能收到的任何证书警告 - 再次,我们只是模拟该域具有有效的SSL证书。页面加载完成后,您将看到一个URL,“Cookie:”字符串和一个“Set-Cookie:”字符串在其下。这是由攻击者的网络服务器收集的所有信息,该网络服务器需要以受害者的身份登录 - 一切都被自动窃取。
  3. 打开单独的攻击者的浏览器并设置拦截代理工具来拦截请求和响应。浏览到prepareuberattack.php页面输出显示的URL并拦截此请求。现在复制在prepareuberatt.php上显示的“Cookie:...”字符串,并将其粘贴到请求标头中。
  4. 响应应该是重定向到https://riders.uber.com/trips,表示验证成功绕过。最后但并非最不重要的是,从prepareuberattack.php页面输出中复制所有“Set-Cookie:”行,并将其粘贴到响应中,然后再将其转发到浏览器。这样可以确保被盗的cookies被永久地注入攻击者的浏览器中。
  5. 您现在以攻击者的浏览器身份登录成为受害者。

[嵌入式内容]

在真正的攻击情况下,攻击者会隐藏在受害者的浏览器中https://saostatic.uber.com/prepareuberattack.php,例如通过iframe。同样,他/她可能不会在结果页面上显示URL和所有的Cookie,而是将其存储在服务器端,准备以隐身的方式被滥用。虽然这是一个漫长的解释,但PoC视频展示了攻击者的快速有效利用是如何。 https://saostatic.uber.com/prepareuberattack.php和https://saostatic.uber.com/uberattack.php页面的代码如下。这是为PoC的目的写得很快,肮脏,但它做的工作:

第一个文件可以托管在任何地方,第二个文件必须托管在被劫持的子域上(因为它读取并反映了传入的会话cookie)。通过在这两个PHP文件中简单地将“riders.uber.com”更改为uber.com的任何其他子域,攻击者可以代表受害者生成这些子域的有效会话,例如vault.uber.com,partners.uber。 com,developer.uber.com,...

建议

向Uber提供的建议有两个方面:

  1. 通过将悬挂的CNAME删除到AWS CloudFront CDN来解决子站点收购saostatic.uber.com。
  2. 按照以下优先级顺序解决以下任何一种的身份验证旁路问题:
    • 将SSO系统恢复到OAuth 2,因为这并不具有像当前的共享会话SSO系统那样真正鼓励大型攻击的副作用。
    • 或者,实施IP地址检查:在auth.uber.com(身份提供商)上发布共享的“_csid”会话cookie时存储用户的外部IP地址,并验证向* .uber服务提供商呈现此共享会话cookie的用户。 com具有相同的外部IP地址,以防止如上所述的中继攻击。这里存在一个剩余风险,即当攻击者具有与其受害者相同的外部IP地址(例如,在同一个公司网络/无线接入点/ ...)时。
    • 或者,接受固有风险,并将所有* .uber.com子域包含在您的错误赏金程序范围内,因为它们有可能完全危及SSO系统,包括高价值目标vault.uber.com,partners.uber。 com和riders.uber.com

最终,Uber删除了悬挂的CNAME,并决定实施IP地址检查,以通过其当前基于cookie的SSO系统降低暴露的风险。因此,他们选择接受所涉及的剩余风险。

时间线

  • 07/04/2017:向Uber提交错误报告
  • 11/04/2017:由Uber审理
  • 14/04/2017: 最低赏金 500美元
  • 06/06/2017:Pinged Uber关于报告,因为我现在还拥有saostatic.uber.com
  • 06/06/2017:从Uber的回应,这份报告通过裂缝,现在开始缓解
  • 07/06/2017:删除了saostatic.uber.com的DNS CNAME记录,报告标记为已关闭
  • 14/06/2017:奖励额外$ 4.500奖金
  • 07/07/2017:Uber部署的IP地址检查,并在重新测试后确认
  • 11/07/2017:授予Uber发布博客的权限

为您推荐了相关的技术文章:

  1. Dnsteal:一个利用DNS请求传输文件的工具
  2. 如何高效的进行子域名收集与筛选?
  3. 不同系统间的账户登录-Cookie跨域|一个phper的博客
  4. 信息收集初步 (Open Source Intelligence) // Neurohazard
  5. Box:开源扫描器集合 - 嘶吼 RoarTalk – 回归最本质的信息安全,互联网安全新媒体,4hou.com

原文链接: www.arneswinnen.net