欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

看我如何通过子域名接管绕过Uber单点登录认证机制

来源:本站整理 作者:佚名 时间:2017-08-02 TAG: 我要投稿


Uber使用Amazon CloudFront CDN架构的网站saostatic.uber.com存在子域名安全漏洞,可被攻击者接管。另外,Uber近期部署在网站auth.uber.com上,基于Uber所有子域名cookie共享实现认证的单点登录系统(SSO)也存在安全问题,攻击者可通过入侵控制任意一个*.uber.com子域名进行会话cookie窃取。因此,这两个问题的综合应用将造成对Uber整个SSO系统的身份认证绕过,实现对所有Uber子域名网站的访问控制,影响甚大。目前,通过我的漏洞发现,Uber已经修复了这两个安全问题,并为我提供了5000刀的漏洞奖金。下面,我们就一起来进行漏洞分析:
了解单点登录认证系统SSO的安全性
通常,单点登录认证系统主要有以下三种类型:
OAuth: 基于服务提供者(Service Providers)为身份提供者(Identity Providers)配置的白名单回调URL, 并由“state”参数实现CSRF保护。该方式存在的漏洞大多为开放重定向问题,参考Airbnb的认证绕过漏洞。
SAML & friends: 基于XML消息加密,使用服务提供者和身份提供者之间的预交换加密密钥进行认证。该方式漏洞大多为XML签名绕过,参考OneLogin认证绕过。
子域名cookie会话共享: 基于所有子域名空间的整体安全性。任何一个存在漏洞的子域名都可能导致会话共享cookie被劫持,并对SSO系统造成安全威胁。该方式漏洞大多为RCE远程代码执行、调试日志泄露和子域名接管,参考Ubiquity身份认证绕过。
我个人认为,前两种单点登录方式以前存在很多安全问题,但现在其安全性都已得到提升。相比来说,第三种SSO方式的应用比前两种都要早,从设计角度来说,任何利用这种SSO系统发起认证的域名都必须是同一个顶级域名下的子域名,但由于这种SSO系统的安全性依赖于所有子域名的整体安全性,所以也无形中增加了其攻击面。
Uber的单点登录认证问题
从近期的漏洞披露报告来看,Uber在过去曾使用OAuth来作为*.uber.com子域名的SSO系统,但最近却换成了基于会话共享cookie的SSO系统。现在访问任何一个需要身份认证的uber.com子域名,都将被重定向到auth.uber.com进行统一的身份认证。如果在该网站完成登录之后意味着你通过了其SSO系统,利用SSO系统分配的会话cookie可继续实现其它Uber网站的登录访问。
但是这个SSO系统却存在前述的安全漏洞:在受害者为认证登录状态时,通过对任何一个入侵控制的子域名网站可以窃取经auth.uber.com为任意子域名认证分发的共享会话cookie。虽然Uber采取了一些防护对策,但仍然可以被绕过。加上saostatic.uber.com的子域名绕过漏洞,意味着Uber的整个SSO系统身份认证机制都将被绕过。尽管Uber在漏洞赏金项目中明确了某些不在测试范围内的域名,但该漏洞攻击可适用于任意一个*.uber.com子域名。
对Uber的子域名接管
通过DNS CNAME记录观察,子域名saostatic.uber.com指向Amazon Cloudfront CDN,但主机名并没有被注册,这也味着其存在域名注册接管漏洞。在参考类似的Uber漏洞之后,我成功接管了该子域名,以下PoC证明:

对Uber实现认证绕过
在Uber的SSO系统中,auth.uber.com作为具备临时共享会话cookie的身份提供者,向服务提供者(如riders.uber.com等网站)发起认证。成功完成认证之后,为避免冲突和错误,服务提供者在服务端将会立即删除传入的临时共享会话cookie,并降低会话信息被窃取的可能和风险。以下为Uber SSO系统的用户登录流程:

从上图分析可看出,由于在第9步和第12步之间存在一个短暂的浏览器重定向,有效的会话cookie  “_csid”貌似只能从此进行窃取。对此,结合Jack Whitton的CSP欺骗实现cookie重定向发送漏洞,我发现了一种更方便有效的利用方法,通过该方法可以让共享会话cookie在第12步后仍然保存在浏览器中。关键是,如果目标用户已经通过第12步实现了https://riders.uber.com的认证登录,当该用户接着又从auth.uber.com收到了一个新生成的有效共享会话cookie “_csid”时,这个新cookie将被忽略但保持有效。
因此,攻击者可以将上图第3步重放为下图的第13步,并在其后添加一个指向https://saostatic.uber.com的隐藏请求,就可以窃取到有效会话cookie:

理论上来说,一旦攻击者得到了如https://riders.uber.com的受害用户共享会话cookie “_csid”后,就可在自己的浏览器中执行正常的登录认证流程,并会替换掉第9步的“_csid” 分发cookie值,伪装受害用户进行登录。但是,Uber在这里设置了CSRF跨站请求伪造防护措施,所以,加入CSRF防护机制的Uber SSO登录流程图如下所示:

关键就在于GET参数state=CSRFTOKEN,和在第3步中由riders.uber.com添加的,并在第11步验证的本地局部状态cookie。由于我们无法从受害用户浏览器中窃取这些cookie值,但我们的目标又是共享会话cookie“_csid”,那是否就没戏了呢?
NO!由于攻击者可以通过在自己终端,正常进行https://riders.uber.com的登录操作,并从中获取到有效的CSRFTOKEN值和状态cookie,那么攻击者就能够将https://riders.uber.com在第三步生成的auth.uber.com URL链接转发至受害用户的浏览器中,生成并窃取共享会话cookie  “_csid”,最后将这些cookie插入到第9步的自己登录认证过程中。这种方式下,由受害者生成一个临时的会话令牌”_csid”,而攻击者利用该令牌在单独的浏览器实现成功认证登录,非常完美。

[1] [2]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载