你与Uber的用户信息，只有一个域名的距离。利用子域名接管就可以轻松搞定。

一名比利时的技术人员Arne Swinnen就在其博客上详细讲解了如何利用子域名接管绕过Uber的单点登录。

Arne发现，Uber的saostatic.uber.com子域名可以被接管。

此外，Uber最近在auth.uber.com上部署了单点登录（SSO）系统，该系统会在所有* .uber.com子域之间共享Cookie。

因此，子域名接管可以绕过整个SSO系统的身份验证，从而访问到其他所有* .uber.com子域名，例如vault.uber.com，partners.uber.com，riders.uber .com等重要业务站点。

什么是单点登录？

SSO主要有下面三种类型：

OAuth：安全性主要基于白名单的回调URL，以及通过“state”参数进行CSRF保护。缺陷通常存在于URL重定向漏洞，可以盗取OAuth令牌，绕过身份验证。

SAML：安全性基于服务商和身份提供者之间的XML消息，这些消息需要通过双方预先交换的密钥进行验证。缺点通常在于XML签名绕过。

子域间共享Cookie：安全性基于所有子域的安全性。任何子域存在漏洞，都会导致来自SSO系统的共享会话cookie被盗取。

Uber是如何使用SSO的

Uber之前使用OAuth作为单点登录，现在改成了子域间共享cookies的方式。

浏览任何需要身份验证的uber.com子域名，例如客服中心，Uber司机，开发者中心，都会被重定向到auth.uber.com。

只要登录并访问另任意一个子域名，浏览器就可以通过SSO系统透明地登录，该系统在登录一次后会为每个* .uber.com子域发布临时会话cookie。

这个系统中存在漏洞，就是受害者只需要进行一次SSO身份验证，就会导致任何被接管的* .uber.com子域名发送并盗取有效的会话cookie。

Uber对此采取了不少防护措施，但是都被黑客绕过了。

子域名接管

Uber的一个子域 saostatic.uber.com通过DNS CNAME指向Amazon Cloudfront CDN，但是主机名没有被注册，这就允许黑客完全接管这个域名。这个情况很像 Frans Rosén在rider.uber.com上进行的一次子域名接管。

Frans Rosén

为了证明这个漏洞，Arne Swinnen在被接管的子域名上放了一个HTML文件，表明他已经接管这个了这个子域名。

绕过认证

在Uber的SSO系统中，auth.uber.com是身份提供者，并为https：//*.uber.com提供临时共享会话Cookie，为Uber司机、合作商和开发人员提供身份认证信息。

从下面的SSO登陆图中可以发现，服务提供方会马上销毁传入的临时共享会话cookie，防止出现错误的身份验证，减少数据盗取的可能。

因此，黑客只能在步骤9到步骤12之间盗取共享会话cookie“_csid”，而且由于浏览器的自动重定向，留给黑客攻击的时间非常短。

虽然黑客还是可以在这么短的时间内进行盗取，但根据上图显示，这个系统中还有一个更方便利用的错误，允许共享会话cookie在步骤12后继续保存在浏览器的cookie存储中。

问题在于，如果受害者已经从https://riders.uber.com登陆（图中步骤12之后的情况），当他接收到来自 auth.uber.com的一个新请求，而这个请求包含共享会话cookie“_csid”时，cookie就会被忽略，直至浏览器的cookie被清理。

黑客只需要重复上图中的步骤3作为步骤13，并向https://saostatic.uber.com发送一个隐藏的请求，就可以盗取重要的会话cookie。

因此，一旦黑客拿到受害者的共享会话cookie“_csid”，他就可以在自己的浏览器上执行正常的登录流程，并在步骤9中把自己的“_csid”cookie替换成受害者的然后登陆.

实际上，Uber还有另外一层防护措施，存在跨站请求伪造防护。下面是实际的Uber SSO登陆图。

问题在于，GET参数 state=CSRFTOKEN，服务提供方 riders.uber.com 加在步骤3中的本地作用域cookie，以及步骤11中的验证。黑客没办法从受害者的浏览器中拿到这些值，他们手里只有“_csid”cookie。

不过黑客依然可以从https://riders.uber.com获取正确的CSRFTOKEN值和附带的state cookie值，方法是在其末尾启动一个正常的登录方案（比如用自己的浏览器或写一个简单的脚本）。

然后，他可以在步骤3中将https://riders.uber.com生成的auth.uber.com URL传送到受害者的浏览器，生成并盗取“_csid”共享会话cookie，并在步骤9中再次将它们注入到自己的浏览器中。

通过这种方式，受害者就会在自己的浏览器上为黑客提供临时的“_csid”会话令牌。

PoC漏洞证明

一个PoC胜过一千张图片解释。在下面的PoC中，假设的情况是https://saostatic.uber.com在受害者的浏览器上提供有效的SSL证书。

1、受害者打开https://riders.uber.com，被重定向到https://auth.uber.com，使用受害者的凭证登录。

2、在受害者的浏览器中打开https://saostatic.uber.com/prepareuberattack.php。接受你可能收到的任何证书警告 - 再说一次，我们只是在模拟该域名具有有效的SSL证书的情况。

页面加载完成后，你将得到三个字符串：URL字符串，“Cookie：”字符串和“Set-Cookie：”字符串。这些就是黑客收集的用来以受害者身份登陆的所有信息。

3、打开自己的浏览器，设置拦截代理工具来拦截请求和相应。打开prepareuberattack.php页面输出显示的URL并拦截此请求，然后复制 prepareuberattack.php上的 “Cookie: …” 字符串并粘贴到请求标头中。

4、重定向到https://riders.uber.com/trips，表示成功绕过验证。还有一点，从prepareuberattack.php页面输出中复制所有“Set-Cookie：”字符串，并将其粘贴到响应中，然后再将其转发到浏览器。这样可以确保被盗的cookies被永久地注入到你的浏览器中。

5、现在黑客就可以在自己的浏览器上以受害人的身份登陆了。

在真正的攻击中，黑客会在受害者的浏览器上加载saostatic.uber.com/prepareuberattack.php，例如通过iframe。

prepareuberattack.php和uberattack.php的页面代码如下：

第一个文件可以托管在任何地方，第二个文件必须托管在被劫持的子域名上。

通过在这两个PHP文件中将“riders.uber.com”更改为uber.com的任何其他子域名，黑客可以代表受害者生成这些子域名的有效会话。

建议

Arne提供给Uber的建议有两个方面：

1、通过检查所有的子域名，停用或者解析存在接管风险的子域名。

2、使用安全性更高的OAuth 2的SSO系统进行单点登录验证。

Arne Swinnen