【国际资讯】Facebook聊天记录窃取漏洞，影响十亿Messenger用户(含视频)

翻译：pwn_361

预估稿费：200RMB（不服你也来投稿啊！）

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

在这篇文章中，我们详细讲述一个在Facebook 上发现的服务器安全漏洞，这个漏洞可能会影响数百万CORS(跨域资源共享)中Origin头允许“NULL”值的网站，该漏洞会威胁用户的隐私，恶意实体可以不受限的访问网站。被称为“Originull”的攻击方法，允许黑客访问和浏览到所有经过Facebook Messenger发送的私人聊天记录、照片、和其他附加信息。这个安全问题是由Ysrael Gurt研究团队发现的，目前已经通知了Facebook。

漏洞演示视频

“非技术性”的解释

这个漏洞是一个跨域权限绕过攻击漏洞，允许黑客利用外部网站访问和读取到用户的Facebook 私人消息。通常，浏览器会保护Messenger用户，只会让Facebook 页面访问到这些信息，但是，Facebook 为了使它的子网站能访问到Messenger的信息，它打开了一座能让子网站访问到信息的“桥”。如果恶意程序能成功利用Facebook 管理的子网站的身份，就有可能访问到Messenger的私人聊天记录。

例如，如果一个用户打开了一个黑客的恶意链接，这个黑客就有可能看到所有Messenger用户来往的聊天记录、照片、和其他信息。

Image 1: The chat appears on the BugSec website. The user ID is shown to the lef

“技术性”的解释

这是对以上问题更深层次的研究。Facebook Messenger聊天记录的管理是在一个子域名下，地址是：{number}-edge-chat.facebook.com，而聊天本身是运行在www.facebook.com域名上。

客户端javaScript和服务器的通信通过XML HTTP Request(XHR)。

javaScript为了访问到来自5-edge-chat.facebook.com的数据，Facebook 必须在调用者的HTTP头增加“Access-Control-Allow-Origin”值，且“Access-Control-Allow-Credentials” 的值为“true”，只有这样，数据才能被访问（需要cookies）。

Image 2：The original request

到目前为止，这看起来好像是一个正常的跨域资源共享进程。同时为了阻止其他非法的网站访问这些数据，Facebook对访问的请求头会做检查。如果请求来自一个没有认证的源，服务器会返回带有“x-fb-chat-failure-reason”头的请求错误(HTTP 400)信息。

Image 3: Request from a different origin

但是！但是！但是！：Facebook也允许正常GET请求访问聊天域名。但正常GET请求不带有XHR的控制标识头。XHR控制标识头比较特殊，只有使用XHR请求的浏览器对会发送。

当服务器收到GET请求时，它没有包括CORS的“origin”头。在很多开发语言中，不存在的头标识会被解释成“NULL”值，如果Facebook会接受“origin”头为“NULL”值的话，它就不会阻止来自这个源的请求。

最有可能的是，过滤机制和响应机制是分开的，响应者假设“origin”头的值是允许的，因为如果没有允许，过滤器肯定已经阻止了这个请求。这种开发设计允许Facebook添加一个新的授权访问源，只需要在一个位置修改一下代码。

总之，“origin”值为”NULL”的GET请求绕过了过滤检查。响应者接受了请求头中的”NULL”值，并且在响应头中的“Access-Control-Allow-Origin”值中呈现了出来。

Image 4: Request without origin.

到此，已经清楚了，我们发了一个origin为“NULL”的请求，返回头中带有“Access-Control-Allow-Origin”标识，且为”NULL”值。

首先，我们用“burp”来检验这个结果，当我们发送了“NULL”的请求时，在Facebook的返回信息得到了验证。

Image 5: Request with “null” origin

在这次测试中，我们也发现了在发送origin为“NULL”的请求时，“data URI scheme”可以被使用，（data URI scheme 允许我们使用内联的方式在网页中包含数据，目的是将一些小的数据，直接嵌入到网页中，从而不用再从外部文件载入）。当使用这功能时，浏览器为安全目的，会将origin值默认设置为“NULL”。

Image 6: The example code.

Image 7: The final HTML

Image 8: The HTML in Firefox.

Image 9: The HTML in Chrome

因此，基于实际测试，我们知道了Facebook的处理方法，我们对Messenger聊天用户，可以进行有效攻击了。

Facebook聊天API

Facebood会向服务器发送连续的XHR请求，用来获取新的消息。当收到一个消息或超时，服务器会发出响应。这种方式意味着总会总有一个XHR请求，在等待服务器的返回。当一个服务器返回一个请求时，JavaScripy代码给服务器又会发送一个新的请求。

Image 10: Server response at timeout.

Image 11: Server response for a new message.

为了确保消息以正确的顺序到达，每个请求都有一个序列号（返回的“序列”和请求是对应的）。也就是说每一个请求所用到的参数可以从返回值中得到。

基于以上研究，我们编写了下面的代码，这个代码会和Facebook API进行通信，并窃取到用户的消息、显示在页面上，并发送到BugSec服务器上。如下：

并将这个代码转换成Base64字符串，用data URI scheme的方式插入到元素标签中。

当受害人点击了恶意网页（为什么需要用户点击，因为需要COOKIES），代码开始监听他的Facebook Messenger聊天，并将聊天记录发送到bugsec服务器。

最后

通过Facebook的漏洞奖励计划，这个漏洞已经报告给了Facebook，他们反应很快，几天前已经对这个漏洞进行了修补。