3个月时间，5名黑客找出苹果55个漏洞，赚了5万多美元，还写了篇博客记录全程

大数据文摘出品

作者：刘俊寰、朱科锦、lin

昨天，翘首期待的iPhone12终于面世，不管是回归经典方框设计，还是首次推出小屏mini版，都让苹果玩家大呼过瘾。

不过，在今年这场别开生面的发布会之前，以安全著称的苹果却忽然被曝出55个漏洞。

想要剁手的朋友们尽管放宽心，因为这些漏洞已经被5名黑客报给了苹果，还因此小赚一笔，获得了5万美金的奖励。

事情是这样的，苹果一直有对漏洞报告者进行资金奖励的传统，并且给这个项目取了个酷炫的名字——Apple Bug赏金计划。今年7月，一位资深技术从业者Brett Buerhaus在twitter上看到一位同行因为发现了苹果的身份验证绕行bug而获得苹果公司10万美元的奖励，于是非常心动，并召集了4位黑客朋友一起，研究苹果的整个基础程式。经过了长达3个月对苹果在线服务的研究和分析，找出了55个漏洞，其中一些还非常危险。

比如，居心叵测的人可以利用这些漏洞制造一种蠕虫，进而自动窃取某人的iCloud帐户中的所有照片、视频和文档，甚至能对受害者的联系人进行同样的攻击。

听上去也太可怕了吧，文摘菌攥紧了早已碎屏的iPhone…

不过还好，在发现这些漏洞之后，这5名黑客就已经向苹果进行了报告，苹果随即修复了这些错误。

Brett Buerhaus接下来也以自述的方式，在自己的博客上把这个过程和所有漏洞内容都记录了下来。

入侵苹果的第一步是弄清楚实际目标是什么。Ben和Tanner都是这里的专家，所以他们开始弄清楚我们可以访问的所有苹果的内容。他们扫描的所有结果都在仪表板中建立了索引，该仪表板包括HTTP状态代码，标头，响应正文以及Apple拥有的各个域下可访问的Web服务器的屏幕快照，我们将在参与过程中参考这些。

简而言之：苹果的基础设施规模巨大。

他们拥有整个17.0.0.0/8 IP范围，其中包括25,000个Web服务器，其中apple.com下拥有10,000个Web服务器，另外7,000个唯一域，最重要的是拥有自己的TLD（点苹果）。我们的时间主要花费在17.0.0.0/8 IP范围，.apple.com和.icloud.com上，因为那是有趣的功能所在。

列出所有Web服务器后，我们开始在更有趣的服务器上运行目录暴力破解。

博客地址：

https://samcurry.net/hacking-apple/

这篇博客很快引起了海外媒体和不少网友的关注。

在国外媒体vice对这件事进行报道后不久，其中一名黑客Sam Curry就在个人推特上表示，苹果告诉他们，他们还有机会获得总计28.85万美元的奖励，因为之前苹果只为部分漏洞付了钱，现在，他们准备再追加28个漏洞的奖金。

5万的奖金，是多了还是少了？

说到这次的项目，Sam Curry在他的博客文章中表示，“没想到会花掉我们3个多月的时间”。

“这原本是一个附属项目，我们每隔一段时间会进行一次工作。但是在新冠疫情的影响下，我们有了很多额外的空闲时间，最终累积下来，每个人平均投入了数百小时。”

不过，在这次的事件上，比起黑客们发现的漏洞，人们对于苹果给予的奖金数额更感兴趣。

我们来简单做一下数学。5名黑客用“数百小时”来研究苹果的在线服务，他们在三个月内发现了55个漏洞，苹果奖励他们5万美元，这么算下来的话，每个人每个漏洞大约值250美元，或者每个人每月的“薪水”是17171美元。

安全公司Phobos的创始人Dan Tentler感叹道，这“非常低”。

Tentler在一次线上会议中对Motherboard表示：“在我看来，两到四周的安全评估，大约就能值到50k美元，尚且不论这5位黑客发现的问题本身其实更有价值。”

“想象一下，如果有任何威胁国家安全的不法分子发现并利用了这些漏洞，造成的损害将会有多大。但是，苹果却告诉他们和大众，这一切只值5万，这让我不得其解，并且这与他们所宣扬的将严肃对待隐私和安全问题的说法背道而驰。”

不过在著名漏洞悬赏专家Katie Moussouris看来，苹果给出的金额可能是公平的。

Moussouris表示：“查找基于网络的漏洞所需的技能比移动端或iOS的要更容易。”

“从逻辑上讲，苹果会为能够入侵其核心操作系统的人支付更高金额。这可能也是为什么苹果愿意为iCloud数据泄露等系统漏洞支付金额。”

Moussouris总结说：“真正的问题是，苹果可以向专业的渗透测试人员提供文档，让他们在更少的时间内找到更多的漏洞，而不是浪费时间进行黑匣子检查，尤其是考虑到两者的价格并不会相差太大。”

噱头有了，但奖金太少，没人愿意把漏洞报告给苹果

在黑客们向苹果报告了发现的漏洞后，苹果发言人表示，“我们重视与安全研究人员的合作，以帮助确保用户的安全，感谢团队的协助，我们将从Apple Security Bounty计划中奖励他们”。

Apple Security Bounty是苹果在2016年宣布启动的一个计划，时任苹果安全工程和体系结构负责人Ivan Krstic在Black Hat上宣布，苹果将开始向发现其产品漏洞的研究人员提供最高200,000美元的现金奖励。

Apple Security Bounty的设立，旨在消除安全架构的某些秘密，并向愿意帮助改善苹果安全性的黑客、研究人员和密码学家开放，这其中涵盖了HomeKit、AutoUnlock和iCloud钥匙串的安全功能。

不过，这四年间，尽管苹果也开始慢慢向部分研究人员发放奖励，但总的来说，这项计划并没有达到最初的目的。因为对于大多数安全研究人员来说，参与这项计划可能并不划算，他们需要投入大量的精力，最终的收入也无法可能证明前期的时间投入是合理的。

一位前苹果员工就在推特上吐槽到，“奖金就是最好的劳动力”。

2017年，Motherboard采访了部分安全研究员，他们都表示，iOS漏洞非常值钱，但与之相对的是，苹果给出的奖金太少，因为就算发现了漏洞，他们也不会报告给苹果，这些漏洞在黑市上可以卖到更高的价钱。

Zimperium安全研究员Nikias Bassen 表示：“把漏洞卖给其他人可以得到更高的价格，对于那些以此谋生的人来说，肯定是不会选择把漏洞直接报告给苹果的。”

不过，毫无疑问，这5个人在未来几个月内，会获得更多的收入。

“我认为，苹果可能会支付与这些发现同等价值的金钱。公平地说，我们在短时间内解决了大量问题，但处理这些问题的过程比报告1或2个问题要困难得多。”

尽管如此，这只是错误专家赏金行业中许多专家认为是个大问题的又一个例子。正如网络安全咨询公司Trail of Bits去年在博客文章中所写的那样，“试着以程序员的身份参加漏洞奖励活动谋生，就像说服自己在德州足够优秀，辞掉工作也能正常生活一样”。

黑客们发现了哪些苹果漏洞？

想必到现在，大家对于这些黑客到底发现了苹果的哪些漏洞还十分好奇。

别担心，在博客上，Brett Buerhaus公开了他们发现的55个漏洞，这里文摘菌也节选了其中两个，先给大家过过眼瘾。

博客链接：

https://samcurry.net/hacking-apple/

通过认证和授权旁路，苹果杰出教育家计划完全被攻破

我们花时间入侵的第一个服务器之一是"苹果杰出教育家"网站。这是一个仅限邀请的Jive论坛，用户可以使用他们的苹果账户进行认证。这个论坛的有趣之处在于，一些注册应用的核心Jive功能是通过苹果公司建立的自定义中间件页面移植过来的，以便将他们的认证系统（IDMSA）与使用用户名/密码认证的底层Jive论坛连接起来。

这样做的目的是为了让用户能够轻松地使用他们已有的Apple账户来验证身份，而不需要创建一个额外的用户账户。你只需要使用“用苹果登录”就可以登录到论坛。

不被允许进入论坛的用户的登陆页面是一个申请入口，你提供自己的信息，然后由论坛版主进行评估审批。

当你提交使用论坛的申请时，就像你正常注册Jive论坛一样，你提供了几乎所有的账号信息。这样就可以让Jive论坛根据你的IDMSA cookie知道你是谁，因为它把你苹果账号的邮箱地址和论坛绑定在一起。

在申请注册使用论坛的页面中，有一个隐藏的信息是“密码”字段，其值为“##INvALID#%！3”。当你提交了包括用户名、姓名、邮箱地址和雇主在内的申请时，你也在提交一个 "密码 "值，这个密码值从页面上的一个隐藏的输入字段被秘密地绑定到你的账户上。

<div class="j-form-row">
<input id="password" type="hidden" value="###INvALID#%!3">
<div id="jive-pw-strength">
...

观察到这个隐藏的默认密码字段后，我们立即想到一种方法来手动认证应用程序，并访问论坛的核准账户，而不是尝试使用 "用苹果登录 "系统登录。我们采取这个方法是因为我们每个人分别注册时的密码都是一样的。

如果有人使用这个系统进行申请，并且存在手动认证的功能的话，你可以简单地使用默认密码登录到他们的账户，完全绕过“用苹果登录”登录。

从表面上看，你似乎并不能手动认证，但在谷歌搜索了后，我们发现了一个“cs_login”端点，它是用来用用户名和密码登录Jive应用的。当我们手动提出测试HTTP请求来验证苹果杰出开发者应用时，我们发现它试图通过显示密码错误来验证我们。当我们使用自己之前申请的账户时，由于我们还没有被批准，所以应用程序不允许我们进行身份验证。如果我们想进行身份验证，就必须找到已经批准的会员的用户名。

这时，我们将HTTP请求加载到Burp Suite的入侵器中，并尝试通过登录和默认密码来强行输入1到3个字符的用户名。

大约两分钟后，我们收到了一个302响应，表示用默认密码成功登录到用户名“erb”的账号中。我们成功了！现在，我们的下一个目标是对具有高权限的人的身份进行认证。我们截图了几张访问记录，点击 "用户 "列表，查看哪些用户是管理员。我们登录到列表中看到的第一个管理员账户，试图证明我们可以通过管理功能实现远程代码执行，但是，我们遇见了一些障碍。

当我们试图以管理员账户浏览“/admin/”（Jive管理员控制台）时，应用程序重定向到登录页面，看起来像是我们还没有通过认证。这很奇怪，因为这只是Jive应用的行为，我们之前都没有观察到这种情况。我们的猜测是，苹果公司根据IP地址限制了管理控制台，以确保应用程序永远不会完全被攻克。

我们尝试的第一件事是使用X-Forwarded-For来绕过我们猜测的限制，但很遗憾，这失败了。接下来我们尝试的是加载不同形式的“/admin/”，以防应用程序有访问管理员控制台的特定路径黑名单。

仅仅经过几次HTTP请求，我们就发现“GET /admin;/”允许攻击者访问管理控制台。我们通过设置一个Burp Suite规则，自动将HTTP请求中的“GET/POST /admin/"改为 "GET/POST /admin;/”，从而实现了自动绕过。

当我们最终找到并加载管理控制台时，障碍又出现了。我们无法使用一般的功能来演示远程代码执行（没有模板、插件上传，也没有标准的管理调试功能）。

这时，我们停下来想了想自己的问题，意识到我们认证的账号可能不是应用程序的 "核心 "管理员。我们又继续认证了2-3个账户，最后才认证为核心管理员，并实现了可以进行远程代码执行的功能。

攻击者可以(1)通过使用隐藏的默认登录功能手动认证绕过认证，然后(2)通过在请求中发送修改后的HTTP路径访问管理控制台，最后(3)通过使用插件上传、模板或文件管理等众多RCE的功能中的一个来彻底破坏应用程序。

总的来说，这将使攻击者能够做到以下事件：

• 在ade.apple.com网站服务器上执行任意命令；
• 访问内部的LDAP服务以管理用户账户；
• 访问苹果公司的大部分内部网络。

存储跨站点脚本漏洞：允许攻击者通过修改电子邮件窃取iCloud数据

苹果基础设施的核心部分之一是他们的iCloud平台。该网站作为苹果产品的照片、视频、文档以及app相关数据的自动存储机制。此外，该平台还提供了邮件和查找我的iPhone等服务。

邮件服务是一个完整的电子邮件平台，用户可以发送和接收电子邮件，类似于Gmail和雅虎。此外，iOS和Mac上都有一个默认安装的邮件应用程序。邮件服务与文件和文档存储等其他服务一起托管在“www.icloud.com”上。

这意味着，从攻击者的角度来看，任何跨站点脚本漏洞都将允许攻击者从iCloud服务中检索他们想要的任何信息。在这一点上我们开始寻找任何跨站点脚本问题。

邮件应用程序的工作方式非常简单直接。当服务收到一封电子邮件，用户打开它时，数据被处理成一个JSON blob，通过JavaScript进行过滤清理和分解，然后显示给用户。

这意味着就内容过滤而言，没有服务器端对电子邮件进行处理，而呈现和处理邮件体的所有实际功能都在客户端完成的JavaScript中。这并不一定是件坏事，通过理解我们需要在源代码中具体破坏什么，可以简化标识XSS的过程。

基于Style标签混淆来存储的XSS

当测试此功能时，我最终遇到的一件事是“ <style>”标签。这个标签很有趣，因为DOM只会取消带有结尾“ </ style>”标签的元素。这意味着，如果我们编写“ <style> <script> alert（1）</ script> </ style>”并且完全在DOM中呈现，则由于标记的内容严格是CSS，因此不会出现警告提示 并且脚本标签已填充在标签内，并且没有超出结束标签。

从安全清理的角度来看，Apple唯一需要担心的是结束Style标签，或者如果页面上有敏感信息，则是通过导入链接进行CSS注入。

我决定集中精力打破Style标签，因为这将是一个非常简单的存储XSS，如果可以实现。苹果不会意识到这一点。

我玩了一段时间，尝试了各种排列，最后发现了一些有趣的现象:当邮件中有两个Style标签时，Style标签的内容会被连接到一个Style标签中。这意味着，如果我们可以将“</sty”放入第一个标签，并且将“le>”放入第二个标签，就有可能欺骗应用程序，使其认为我们的标签仍然是开放的，而实际上它并不是。

我发送了以下有效负载以测试是否有效：

<style></sty</style>
<style>le><script>alert(1)</script></style>

该电子邮件在我的收件箱中弹出。我点击了它。有警报提示！它奏效了！

页面的DOM包括以下内容：

<style></style><script>alert(1)</script></style>

由于邮件应用程序托管在“www.icloud.com”上，这意味着我们具有浏览器许可权，可以检索iCloud服务的相应API的HTTP响应（如果我们可以潜入JavaScript以与他们联系）。

上述有效负载的解释如下：

在这一点上，我们认为最酷的概念证据会是窃取受害人的所有个人信息（照片，日历信息和文件），然后将相同的漏洞利用转发给其所有联系人。

我们构建了一个简洁的PoC，它将从iCloud API返回照片URL，将其粘贴到图像标签中，然后在其下方附加用户帐户的联系人列表。这表明可以检索这些值，但是要渗入它们，我们必须绕过CSP，这意味着除了“.apple.com”和其他几个域外，没有其他任何简单的出站HTTP请求。

对我们来说幸运的是，该服务是一个邮件客户端。我们可以简单地使用JavaScript来给自己发送电子邮件，附加iCloud照片URL和联系人，然后发送受害者签名的iCloud照片和文件url。

以下视频展示了一个概念的证据，一个受害者的照片被盗。在由恶意方执行的充分利用场景中，攻击者可以悄悄地窃取受害者的所有照片、视频和文档，然后将修改后的电子邮件转发给受害者的联系人列表，并对iCloud邮件服务实施跨站点脚本有效载荷蠕虫攻击。

基于超链接混淆存储的XSS

后来，我发现了第二个以类似方式影响邮件的跨站点脚本漏洞。

对于这类semi-HTML应用程序，我总是要检查的一件事是它们如何处理超链接。自动将未标记的URL转换为超链接似乎很直观，但如果它没有被正确地清理或与其他功能结合在一起，就会变得很混乱。这是查找XSS的常见位置，因为依赖于regex、innerHTML和所有可在URL旁边添加的可接受元素。

此XSS的第二个有趣功能是完全删除某些标签，例如“ <script>”和“ <iframe>”。这很整洁，因为某些东西将依赖于字符，例如空格，制表符和换行符，而remove标记留下的void可以提供这些字符而无需告知JavaScript解析器。这些差异使攻击者可以混淆应用程序，并潜入可以调用XSS的恶意字符中。

我花了一段时间来研究这两种功能（自动超链接和某些标签的完全删除），直到决定将两者结合起来并尝试观察它们的表现方式。令我惊讶的是，以下字符串破坏了超链接功能并混淆了DOM：

https://www.domain.com/abc#<script></script>https://domain.com/abc

在通过电子邮件本身发送以上内容之后，内容解析如下：

 <a href="https://www.domain.com/abc#<a href=" https:="" www.domain.com="" abc="&quot;" rel="noopener noreferrer">https://www.domain.com/abc</a>

这在一开始是非常有趣的，但利用它会有点困难。在标签中定义属性很容易(例如src, onmouseover, onclick等)，但是提供值就很困难了，因为我们仍然需要匹配URL regex，这样它就不会逃脱自动超链接的功能。最终在不发送单引号、双引号、括号、空格或反引号的情况下工作的有效负载如下：

 https://www.icloud.com/mail/#<script></script>https://www.icloud.com/onmouseover=location=/javascript:alert%28document.domain%29/.source;//

有效负载在DOM中生成如下内容：

 <a href="https://www.icloud.com/mail#<a href=" https:="" www.icloud.com="" onmouseover="location=/javascript:alert%28document.domain%29/.source;//&quot;">https://www.icloud.com/onmouseover=location=/javascript:alert%28document.domain%29/.source;//</a>

并给我们这个美丽的警告：

这个有效负载来自@Blaklis_的一个CTF解决方案。我最初认为它可能是不可利用的XSS，但似乎总有某个地方可以解决边界情况下的XSS。

我最好的解释是（1）加载初始URL时，“ <script> </ script>”中的字符在自动超链接过程中是可接受的，并且没有破坏它，然后（2）删除了脚本标签创建了一个空白或某种类型的void，这些在不关闭初始超链接功能的情况下重置了自动超链接功能，最后（3），第二个超链接添加了额外的引号，该引号用于打破href并创建onmouseover事件处理程序。

第二个XSS的影响与第一个XSS相同，不同之处在于，用户必须通过将鼠标置于电子邮件正文中的某个位置来触发onmouseover事件处理程序，但是可以通过制作整个电子邮件的超链接简化此部分以使其更容易触发。

总体而言，攻击者可能会滥用此信息来：

• 创建一种蠕虫病毒，该蠕虫能够以静默方式泄露/修改iCloud帐户信息（包括照片和视频）；
• 在受害者的浏览器中静默执行任意HTML和JavaScript。

看到最后，你认为苹果这5万美元给少了吗？欢迎在评论区留言讨论~

相关报道：

https://www.vice.com/en/article/v7g5ea/hackers-found-55-bugs-in-apple-productsmade-dollar51500

https://techcrunch.com/2016/08/04/apple-announces-long-awaited-bug-bounty-program/