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

阅读量    74077 |   稿费 200

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

http://p6.qhimg.com/t01829e1691294431d9.jpg

翻译:pwn_361

预估稿费:200RMB(不服你也来投稿啊!)

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


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


漏洞演示视频


“非技术性”的解释

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

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

http://p2.qhimg.com/t0123be3e5ef0bf9b70.png

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)。

http://p1.qhimg.com/t019e5e52c84d8359ee.png

Image 2:The original request

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

http://p6.qhimg.com/t01e1587bab275d0d8a.png

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”值中呈现了出来。

http://p3.qhimg.com/t01d3f59021525f6922.png

Image 4: Request without origin.

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

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

http://p0.qhimg.com/t010a7bc4435838c950.png

Image 5: Request with “null” origin

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

http://p6.qhimg.com/t01d59a4cc07304a04d.png

Image 6: The example code.

http://p9.qhimg.com/t0119336b7245413678.png

Image 7: The final HTML

http://p5.qhimg.com/t01ba3d3ba849206b09.png

Image 8: The HTML in Firefox.

http://p1.qhimg.com/t01942975b9d16fc313.png

Image 9: The HTML in Chrome

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


Facebook聊天API

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

http://p4.qhimg.com/t01c41e3ddb9a1ab0ce.png

Image 10: Server response at timeout.

http://p3.qhimg.com/t014c52cd6a603e2a32.png

Image 11: Server response for a new message.

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

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

http://p4.qhimg.com/t01d828611d5863864a.png

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

http://p7.qhimg.com/t01261b9a43a9755347.png

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

http://p4.qhimg.com/t0197cb9d96b859feaa.png

http://p8.qhimg.com/t0123be3e5ef0bf9b70.png

最后

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

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多