开发者社区> 玄学酱> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

通过子域名来窃取全局共享的Cookie,间接绕过Uber的单点登录认证

简介: 本文讲的是通过子域名来窃取全局共享的Cookie,间接绕过Uber的单点登录认证,Uber使用Amazon CloudFront CDN的本意本来是为终端用户提供低延迟性和高传输速度,增加用户的客户的体验,但没想到,其子域名saostatic.uber.com却被黑客控制以窃取全局共享的Cookie,并间接绕过Uber的单点登录认证。
+关注继续查看
本文讲的是通过子域名来窃取全局共享的Cookie,间接绕过Uber的单点登录认证

通过子域名来窃取全局共享的Cookie,间接绕过Uber的单点登录认证

Uber使用Amazon CloudFront CDN的本意本来是为终端用户提供低延迟性和高传输速度,增加用户的客户的体验,但没想到,其子域名saostatic.uber.com却被黑客控制以窃取全局共享的Cookie,并间接绕过Uber的单点登录认证。

此外,Uber最近在auth.uber.com上部署了单点登录(SSO)系统,该系统基于所有* .uber.com子域之间的共享Cookie。

因此,利用子域进行攻击可能会让黑客绕过Uber的整个的基于SSO系统的身份验证过程,从而让他们访问受保护的所有* .uber.com子域名,例如vault.uber.com,partners.uber.com,riders.uber .com等。 Uber为了解决子域控制的漏洞,总共设置了五千美元的奖金。

重新审视单点登录的安全性

一般来说,SSO系统分为以下三种类型:

1.OAuth:安全性主要基于在身份提供者配置的服务提供商的白名单回调URL,以及通过“state”参数进行CSRF保护。缺陷通常是通过打开的重定向链,例如通过OAuth令牌窃取身份验证并绕过Airbnb。

2.SAML & friends:安全性基于在服务和身份提供者之间使用预先交换的加密密钥签名的XML消息。缺陷通常是XML签名会被黑客绕过,例如OneLogin身份验证绕过了以前位于Uber的WordPress网站。

3.子域之间的共享(会话)Cookie:安全性基于所有子域的完整性,在SSO系统发布的共享会话cookie中,任何子域上的任何漏洞都是致命的。因此,缺陷通常是RCE,曝光的调试日志,子域控制和子域上的朋友,例如。通过子域控制验证绕过Ubiquity的单点登录。

专家们认为,虽然OAuth和SAML & friends最近在安全方面有所改善,但还是存在很多问题。而子域之间的共享(会话)Cookie更是一种过时的技术,它被设计成强制要求将SSO系统用作与SSO系统所基于的TLD相同的子域的任何内容。由于SSO系统的安全性是基于子域的完整性,反而给了攻击者大量的攻击机会。

绕过Uber的SSO

Uber曾经使用OAuth作为* .uber.com子域名的SSO系统,这可以从@ngalog最近公开披露报告中看出,简而言之,就是CSRF + Open Redirect = Account Takeover。不过最近,黑客们已经根据* .uber.com的子域中的共享会话Cookie更改到SSO了。如果你现在浏览到任何需要身份验证的uber.com子域名时,都将被重定向到auth.uber.com。一旦你登录并访问另一个子域,就可以透过SSO系统auth.uber.com公开地登录,SSO系统在登录一次后会为每个* .uber.com子域发布临时会话cookie。

专家们在这个SSO系统中发现一个漏洞,允许* .uber.com上的任何受攻击的子域公开地显示并窃取由auth.uber.com为任何 uber.com子域名发出的有效会话cookie,不过前提是受害者已经验证过一次SSO。

 Uber确实采取了一些对策来防止这种攻击,但是这些措施都被黑客成功地绕过,也就是说任何受到攻击的* .uber.com子域可以用于执行相同的攻击。

控制子域名

虽然子域名 saostatic.uber.com是通过DNS CNAME指向Amazon Cloudfront CDN的,但主机名却未被注册。这样,黑客就能完全控制这个域名了,并有效地将子域名作为PoC,来托管了一个简单的HTML文件:

通过子域名来窃取全局共享的Cookie,间接绕过Uber的单点登录认证

如何绕过认证

在Uber的SSO系统中,auth.uber.com作为用户信息登录平台,为https://*.uber.com(“domain = uber.com”cookie属性)提供临时共享会话Cookie,并向riders.uber.com,partners.uber.com,central.uber.com,vault.uber.com,developer.uber.com等子域提供身份信息。

从下面的Uber SSO登录图中可以看到的,这些使用身份信息的子域会在其结束时立即销毁传入的临时共享会话cookie,以防万一发生信息泄露,例如为其他身份服务商进行的身份验证:

通过子域名来窃取全局共享的Cookie,间接绕过Uber的单点登录认证

因此,共享会话cookie“_csid” 被窃取只能在发生在上图中的步骤9-12之间,这4个步骤之间的反应时间是非常短的(仅仅够自动浏览器重定向)。虽然利用这么短的时间来发起攻击可能很难,但允许共享会话cookie能在第12步之后在浏览器的cookie存储中进行活动。但问题是,如果受害者已经从https://riders.uber.com(上图中, 12步之后的哪个步骤)登录,当接收到来自auth.uber.com中有效的新生成的共享会话cookie“_csid”的请求时,就被简单地忽略并保持可用。因此,它在浏览器中保持活动状态,直到其Cookie存储被清除。攻击者只需要把上图中的第3步作为步骤13进行重播,并以https://saostatic.uber.com的其他隐藏请求结束窃取会话cookie:

通过子域名来窃取全局共享的Cookie,间接绕过Uber的单点登录认证

因此,一旦攻击者从https://riders.uber.com得到受害者的“_csid”共享会话cookie,他们就可以在后台浏览器中伪造正常的登录流程,并在步骤9中替换发出的“_csid”cookie的值,从而伪装成受害者登录,以下就是攻击者伪装的Uber SSO登录示意图:

通过子域名来窃取全局共享的Cookie,间接绕过Uber的单点登录认证

这里的问题是GET服务提供商riders.uber.com会在步骤3中添加GET param state=CSRFTOKEN和本地作用域状态cookie,并在步骤11中进行验证。由于目前研究者还无法从受害者的浏览器中获取这些值,而只能利用“_csid”共享会话cookie,所以要做整体的分析就很困难。

另外,攻击者可以从https://riders.uber.com获取正确的CSRFTOKEN值和附带的状态cookie值,使用的方法就是在其末尾启动一个正常的登录方案,例如在后台浏览器中或通过简单的脚本。然后,他们可以在步骤3中将https://riders.uber.com生成的auth.uber.com URL在后台浏览器中定向到受害者的浏览器,以生成并窃取这些值的“_csid”共享会话cookie,并在步骤9中再次将“_csid”共享会话cookie注入到后台的浏览器登录中。这样,受害者就会在其浏览器中有效地为攻击者的伪装登录生成“_csid”临时会话令牌。不过,这仍然允许以以下方式进行删除,从而避免受害者被冒充,不过,研究人员仍然认为受害者已经登录到auth.uber.com并访问受攻击者控制的网页:

通过子域名来窃取全局共享的Cookie,间接绕过Uber的单点登录认证

PoC

建议大家先观看以下的在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被永久地注入攻击者的浏览器中。

如果你照着以上步骤来操作,也可以伪装成受害者进行登录。

而在实践攻击情形中,攻击者会隐藏在受害者的浏览器中https://saostatic.uber.com/prepareuberattack.php,例如通过iframe。同样,他们可能不会在结果页面上显示URL和所有的Cookie,而是将其存储在服务器端,准备以隐身的方式滥用身份信息。以上的PoC视频演示了攻击者是如何快速有效利用这一招的。 https://saostatic.uber.com/prepareuberattack.php和https://saostatic.uber.com/uberattack.php页面的代码如下,这是专门为PoC编写的:

通过子域名来窃取全局共享的Cookie,间接绕过Uber的单点登录认证

通过子域名来窃取全局共享的Cookie,间接绕过Uber的单点登录认证

第一个文件可以托管在任何地方,第二个文件必须托管在被劫持的子域上,因为它读取并窃取了传入的会话cookie。

通过在这两个PHP文件中简单地将“riders.uber.com”更改为uber.com的任何其他子域,攻击者可以伪装成受害者为这些子域生成有效的会话,例如, vault.uber.com,partners.uber.com,developer.uber.com,…

Uber所采取的预防措施

1.通过将悬垂结构(dangling)的CNAME重新恢复到AWS CloudFront CDN来解决saostatic.uber.com的子域名控制。

2.按照以下优先级顺序解决以下任何一种的身份验证绕过:

2.1将SSO系统恢复到OAuth 2,因为这并不会产生像当前的共享会话SSO系统那样所进行大型攻击的副作用。

2.2实施IP地址检查,在auth.uber.com上发布共享的“_csid”会话cookie时,存储用户的外部IP地址,并验证向* .uber服务提供商呈现此共享会话cookie的用户。由于 *.uber.com具有相同的外部IP地址,所以这样做可以防止如上所述的中继攻击。不过这里还有一个风险,即攻击者可能具有与其受害者相同的外部IP地址,例如在同一个公司网络或无线接入点。

2.3将所有* .uber.com子域包含在你的程序范围内,因为它们有可能完全危及SSO系统,包括高价值目标vault.uber.com,partners.uber.com和riders.uber.com

总之,就是Uber通过删除了悬垂结构的CNAME,并实施IP地址检查,来降低基于cookie的SSO系统风险。




原文发布时间为:2017年7月18日
本文作者:luochicun
本文来自云栖社区合作伙伴嘶吼,了解相关信息可以关注嘶吼网站。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
如何防止网站跨域数据共享信息泄露
数据共享出入口作为机密信息统一管理和集中管理的关键环节,在数据共享出入口采取有效的防护措施,可以极大地提高防护效率,减少对正常业务的干扰。一般的数据共享出入口包括连接因特网的网关设备或连接其它网络的数据交换平台,单向传输设备如网闸、单导等。支持嵌入复杂逻辑功能的数据交换平台或单导服务器,可直接增加保护数据泄露的措施,而网关、网闸等设备功能单一,只能通过串联独立网关设备来保护数据泄露。
0 0
安全漏洞问题7:失效的身份认证和会话管理
应用程序的功能一般包含权限管理和会话管理,但是由于应用程序设计不当,让攻击者可以窃取到密码、密钥、session tokens等信息,进而冒充合法用户身份,获取敏感信息或者进行恶意操作。
5172 0
SS7协议存严重漏洞,可劫持用户短信验证码
本文讲的是SS7协议存严重漏洞,可劫持用户短信验证码,最近有安全研究团队再次证明,手机移动网络中的漏洞可以被利用来拦截短信中的一次性双因素认证令牌(验证码)。 具体来说,安全性的问题出在7号信令系统(SS7协议)上,其是一个适用于无线和有线的公共交换电话网协议。
2524 0
窃取 OAuth 令牌绕过 Airbnb 身份验证
本文讲的是窃取 OAuth 令牌绕过 Airbnb 身份验证,登录过程中的CSRF与Airbnb的OAuth登录流程中的基于HTTP Referer头的开放重定向跳转漏洞相结合,可能会被用来窃取所有的Airbnb身份提供商的OAuth访问令牌
1941 0
关于第三方cookie的作用域以及针对用户行为的使用
cookie,很多网站都会用的一个机制,可以保存用户的相关信息,token等等,很多人熟知的应该是第一方cookie,可以针对二级域名进行信息的保存,如果遇到跨域的情况,那么第一方cookie是没有用的,因为他做不到跨域。
766 0
登录凭证的方式(公司使用cookie)
<div class="markdown_views"> <p>效果: <br> 在同一个浏览器中登录了应用A ,就可以在该浏览器中直接访问应用B,而不用重新登录. <br> 具体实现原理: <br> 1,登录之前访问 认证系统的动态口令接口,获取动态口令:auth_token <br> 同时会返回cookie:CCC ,目的:把浏览器和 auth_token 挂钩 <br>
1875 0
+关注
玄学酱
这个时候,玄酱是不是应该说点什么...
文章
问答
文章排行榜
最热
最新
相关电子书
更多
从身份开始的零信任基础
立即下载
安全机制与User账户身份验证实战
立即下载
微信客户端怎样应对弱网络
立即下载