首页 » 网站建设 » php子域名技巧_经由进程子域名吸收绕过Uber的SSO认证

php子域名技巧_经由进程子域名吸收绕过Uber的SSO认证

访客 2024-10-31 0

扫一扫用手机浏览

文章目录 [+]

译者:WisFree

预估稿费:200RMB

php子域名技巧_经由进程子域名吸收绕过Uber的SSO认证

投稿办法:发送邮件至linwei#360.cn,或上岸网页版在线投稿

php子域名技巧_经由进程子域名吸收绕过Uber的SSO认证
(图片来自网络侵删)

概述

Uber的saostatic.uber.com节点存在安全漏洞,攻击者可以利用该漏洞通过Amazon CloudFront CDN实现子域名接管。
除此之外,Uber近期在auth.uber.com支配的单点登录(SSO)系统中也存在安全问题。
这种SSO系统可以通过在所有.uber.com子域名之间共享cookie来实现单点登录,但个中存在的安全问题将许可攻击者通过任意一个被入侵的.uber.com子域名来盗取会话cookie。
因此,之前的子域名接管问题将会提升为Uber SSO系统的身份认证绕干涉干与题。
目前,Uber已经修复了这个子域名接管漏洞,并且专门为这两个安全问题供应了5000美金的漏洞奖金。

单点登录系统(SSO)的安全问题

一样平常来说,单点登录系统紧张有以下三种类型:

1. OAuth:认证的安全性紧张是通过在白名单中设置做事供应者的URL回调地址实现的,个中CSRF保护是通过“state”参数实现的,可能存在的漏洞一样平常是开放重定向链。
【案例】

2. SAML&Friends:安全性是基于XML信息加密实现的,加密利用的是做事与识别供应商之间预交流的加密密钥,可能存在的漏洞一样平常是XML署名绕过。
【案例】

3. 子域名之间共享会话cookie:这类SSO系统的安全性取决于所有子域名的整体安全性。
任何一个子域名中如果存在漏洞的话,攻击者将有可能盗取到SSO系统的共享会话cookie,可能存在的漏洞一样平常是远程代码实行漏洞、调式日志透露和子域名接管等等。
【案例】

我个人认为,前两种单点登录系统以前确实存在很多安全问题,但现在这两类系统的安全性都已经得到了很大程度的提升。
比较来说,第三种SSO系统涌现得比前两种都要早。
从设计角度来看,任何必要利用SSO系统完成认证的节点都必须是同一个顶级域名下的子域名,由于这种SSO系统的安全性取决于所有子域名的整体安全性,以是这类SSO系统的攻击面也非常广。

Uber案例

在此之前,Uber利用的是OAuth来作为.uber.com子域名的SSO系统,但近期他们将.uber.com子域名的SSO系统换成了基于共享会话cookie的SSO系统。
如果你现在访问任何一个须要进行身份验证的uber.com子域名的话,你都会被重定向到auth.uber.com。
当你在这个节点完成登录之后再访问其他子域名的话,你相称于通过SSO系统上岸了auth.uber.com,由于当用户登录了一次之后,SSO系统便会为每一个.uber.com子域名发送临时会话cookie。

但是研究职员在Uber的这个SSO系统中创造了一个安全漏洞,当目标用户在SSO系统中完成了身份验证之后,该漏洞将许可攻击者盗取auth.uber.com发送给任意uber.com子域名的有效会话cookie。
不过Uber也采纳了一些方法来防止这种事情的发生,但这些方法都可以被绕过。
再加上研究职员报告的子域名接管漏洞,这将意味着任何被入侵的.uber.com子域名都可以用来实行这种SSO认证绕过攻击。

子域名接管

子域名saostatic.uber.com指向的是Amazon Cloudfront CDN(通过DNS CNAME记录),但是主机名并没有进行过注册,这也就意味着我可以完备接管这个域名。
在进行了一番探索之后,我成功接管了Uber的一个子域名,并上传了一个大略的HTML页面来作为PoC:

认证绕过

在Uber的SSO系统中,auth.uber.com作为一个身份供应者给https://.uber.com供应临时共享会话cookie,并与做事供应者(例如riders.uber.com, partners.uber.com, central.uber.com, vault.uber.com和developer.uber.com等等)进行身份信息的验证。
做事供应者在自己的节点中急速打消传入的临时共享会话cookie来降落cookie被盗取的可能性。
下图显示的是Uber SSO系统的用户登录流程:

因此,共享会话cookie“_csid”只能在第九步至第十二步之间被盗取,而这是一个间隔非常短的韶光周期,虽然这并非不能实现,但我们还创造了另一种更加随意马虎利用的漏洞。
在这个漏洞的帮助下,我们可以让共享会话cookie在第十二步之后仍旧保存在浏览器的cookie记录中。
问题就在于,如果目标用户已经在https://riders.uber.com节点完成了登录,那么此时当这个用户又吸收到了一个从auth.uber.com发来的新天生的有效共享会话cookie“_csid”时,这个新的cookie将会被忽略,并且仍保持有效。
由于在浏览器打消保存的cookie内容之前,这个被忽略的cookie将一贯有效,因此攻击者就可以通过重放上图的第三步并在第十三步的要求中添加一个指向https://saostatic.uber.com的隐蔽要求,他们就可以盗取到宝贵的会话cookie了:

当攻击者得到了目标用户的共享会话cookie“_csid”(例如https://riders.uber.com的cookie)之后,攻击者就可以在他们自己的浏览器中完成正常的登录流程,即更换上图中第九步的“_csid” cookie值并伪装用户进行登录。
不过别焦急,这只是空想状态,由于Uber在这里还采纳了一种名叫登录跨站要求假造保护的应对方法。
下面给出的是更新后的Uber SSO登录流程:

问题就在于这里的GET参数state=CSRFTOKEN,而状态cookie是做事供应者https://riders.uber.com在第三步中添加的,并在第十一步进行验证。
由于我们无法从目标用户的浏览器中盗取这些cookie值,但我们的目标又是共享会话cookie“_csid”,那这是否就意味着Game Over了呢?

当然不是!
由于攻击者可以通过正常的登录操作从https://riders.uber.com获取到精确的CSRFTOKEN值(state cookie),那么攻击者就能够在自己的浏览器中将https://riders.uber.com在第三步天生的auth.uber.com URL链接转发至目标用户的流啊理念个中,然后天生并盗取共享会话cookie “_csid”,末了按照第九步的操作将这些盗取来的值注入到自己浏览器的登录场景中。
通过这种方法,目标用户将会天生临时会话令牌\"大众_csid\"大众,而攻击者就可以在另一个浏览器中利用这个token。
攻击的实现过程如下图所示:

PoC

再多的流程图也比不过一个PoC来得清楚。

攻击演示流程:

1. 打开目标用户的浏览器,访问https://riders.uber.com。
在被重定向到了https://auth.uber.com之后,利用用户的凭据完成登录,终极重新回到https://riders.uber.com仪表盘。

2. 在目标用户的浏览器中打开另一个网页标签,访问https://saostatic.uber.com/prepareuberattack.php。
无论弹出什么对话框,都点击“接管”,页面完成加载之后,你就可以看到底部会涌现一个URL、“Cookie:”和“Set-Cookie:”,这便是我们自动盗取来的所有登录信息。

3. 打开攻击者的浏览器,然后设置一个拦截代理来拦截要乞降相应信息。
访问prepareuberattack.php页面输出的URL链接,然后拦截要求。
末了,将prepareuberattack.php页面中显示的“Cookie:”信息拷贝到要求头中。

4. 相应信息该当是指向https://riders.uber.com/trips的重定向链接,这表明我们成功绕过了Uber的身份认证。
接下来,在相应信息到达浏览器之前将“Set-Cookie:”所有的内容拷贝到相应信息中,这样将担保盗取来的cookie永久注入到了攻击者的浏览器中。

5. 现在,攻击者就已经在自己的浏览器中以目标用户的身份完成了登录。

攻击演示视频如下:

视频地址: https://youtu.be/0LoQ1rZfyP4

在真实的攻击场景中,攻击者可以在目标用户的浏览器中(例如通过iframe)悄悄加载https://saostatic.uber.com/prepareuberattack.php。
攻击者可以直接将盗取来的cookie信息保存在做事器端,而无须显示在prepareuberattack.php页面中。
下面给出的是页面https://saostatic.uber.com/prepareuberattack.php和页面https://saostatic.uber.com/uberattack.php的代码。
虽然代码写的不是很好,但它的功能是没问题的:

prepareuberattack.php

第一个文件可以托管在任何地方,第二个文件必须托管在挟制的子域名中。
我们可以将这两份PHP文件中的“riders.uber.com”改为其他的Uber子域名,例如vault.uber.com、partners.uber.com和developer.uber.com。

修复建议

我们供应给Uber的建议紧张有以下两个方面:

1. 通过移除指向AWS CloudFront CDN的无效CNAME记录来办理saostatic.uber.com的子域名接管问题。

2. 通过以下几种方法办理身份认证绕干涉干与题:

a) 将SSO系统规复为利用OAuth 2协议;

b) 引入IP地址检测机制;

c) 将所有的.uber.com子域名加入Uber的漏洞褒奖操持范畴;

终极,Uber移除了不屈安的CNAME记录,并通过引入IP地址检测机制来降落了Uber SSO系统的攻击面。

标签:

相关文章

微信第三方登录便捷与安全的完美融合

社交平台已成为人们日常生活中不可或缺的一部分。微信作为我国最受欢迎的社交软件之一,拥有庞大的用户群体。为了方便用户在不同平台间切换...

网站建设 2025-02-18 阅读1 评论0

广东高速代码表解码高速公路管理智慧

高速公路作为国家交通动脉,连接着城市与城市,承载着巨大的物流和人流。广东作为我国经济大省,高速公路网络密布,交通流量巨大。为了更好...

网站建设 2025-02-18 阅读1 评论0