我们黑了苹果3个月

在我本人的7月6日至10月6日期间，布雷特·比尔豪斯(Brett Buerhaus)、本·萨德希普尔(Ben Sadechiour)、塞缪尔·厄布(Samuel Erb)和坦纳·巴恩斯(Tanner Barnes)一起工作，侵入了苹果漏洞赏金计划。

在我们的行动中，我们在他们的基础设施的核心部分发现了各种各样的漏洞，这些漏洞使得攻击者能够完全危害客户和员工的应用程序，发动蠕虫病毒，能够自动接管受害者的iCloud账户，检索苹果内部项目的源代码，完全危害苹果公司使用的工业控制仓库软件，并通过访问管理工具和敏感资源的能力来接管苹果员工的会话。这些漏洞可以让攻击者完全侵入客户和员工的应用程序，发动蠕虫病毒自动接管受害者的iCloud账户，检索苹果内部项目的源代码，完全侵入苹果公司使用的工业控制仓库软件，并通过访问管理工具和敏感资源的能力接管苹果员工的会话。

总共发现了55个漏洞，其中11个为严重级别，29个为高级别，13个为中等级别，2个为低级别报告。这些严重程度由我们出于总结的目的进行了评估，并取决于CVSS的组合以及我们对业务相关影响的理解。

截至2020年10月6日，这些调查结果中的绝大多数已经修复并归功。它们通常在1-2个工作日内修复(有些修复只需4-6小时)。

大约在7月的某个时候，当我浏览Twitter时，我注意到有人分享了一篇博客文章，其中一名研究人员从苹果公司获得了10万美元的奖励，因为他发现了一个身份验证绕过，允许他们任意访问任何苹果客户账户。这让我大吃一惊，因为我之前了解到，苹果的漏洞奖励计划只奖励影响其实体产品的安全漏洞，而不会为影响其网络资产的问题支付费用。

在看完这篇文章后，我在谷歌上快速搜索了一下，找到了他们的程序页面，上面详细说明了苹果愿意为对用户产生重大影响的漏洞买单，无论该资产是否明确列在范围内。

这引起了我的注意，因为这是一个有趣的机会，可以调查一个新的程序，它看起来范围很广，功能也很有趣。当时我从未参与过苹果的漏洞赏金计划，所以我真的不知道会发生什么，但我决定为什么不碰碰运气，看看我能找到什么。

为了让这个项目更有趣，我给我过去合作过的黑客发了几条信息，询问他们是否愿意在这个项目上合作。尽管没有关于支付的保证，也没有对该计划如何运作的理解，但每个人都说可以，我们开始对苹果进行黑客攻击。

入侵苹果的第一步是找出真正的目标。本和坦纳都是这里的专家，所以他们开始找出苹果所有的东西都是我们可以接触到的。他们扫描的所有结果都在一个仪表板中建立了索引，仪表板包括HTTP状态代码、标头、响应正文和苹果拥有的各个域名下可访问的Web服务器的屏幕截图，我们将在合约中引用这些域名。

他们拥有整个17.0.0.0/8IP范围，其中包括25,000台Web服务器，其中10,000台在apple.com下，另外还有7,000个独特的域名，最重要的是，他们拥有自己的TLD(Dot Apple)。我们的时间主要花在17.0.0.0/8IP范围、.apple.com和.icLoud.com上，因为这似乎是有趣的功能所在。

在列出了所有Web服务器之后，我们开始对更有趣的服务器运行目录暴力强制。

通过这些过程获得的信息有助于了解授权/身份验证在整个Apple中是如何工作的，存在哪些客户/员工应用程序，使用了哪些集成/开发工具，以及各种可观察到的行为，如Web服务器使用某些cookie或重定向到某些应用程序。

在所有扫描完成后，我们觉得我们对苹果的基础设施有了大致的了解，我们开始瞄准那些本能地感觉比其他服务器更容易受到攻击的个别Web服务器。

这开始了一系列的发现，这些发现贯穿了我们的整个项目，并逐渐增加了我们对苹果计划的理解。

内存泄漏会导致员工和用户帐户受损，从而允许访问各种内部应用程序。

盲XSS允许攻击者访问内部支持门户，以跟踪客户和员工问题

服务器端PhantomJS执行允许攻击者访问内部资源并检索AWS IAM密钥。

ICloud上的IDOR允许攻击者通过增量数字标识符检索受害者姓名和电子邮件地址。

Apple Application缺乏访问控制，使得攻击者能够检索所有用户的姓名、地址、电话号码和联系信息。

Apple App Store上的IDOR允许攻击者修改Apple Store应用程序的各种组件。

对Apple Application的不正确访问控制使得攻击者能够泄露和修改内部应用程序资源。

Apple Application缺乏速率限制，使得攻击者能够验证和访问受保护的资源。

从低级别用户到高级别用户的盲XSS允许攻击者危害应用程序。

我们不能写出我们发现的所有漏洞，但这里是一些更有趣的漏洞的示例。

我们花时间破解的第一批服务之一是“苹果杰出教育者”网站。这是一个仅限邀请的Jive论坛，用户可以使用他们的Apple账户进行身份验证。这个论坛的一些有趣之处在于，一些注册到应用程序的Jive核心功能是通过苹果构建的自定义中间件页面移植的，目的是将他们的身份验证系统(IDMSA)连接到底层Jive论坛，后者通常使用用户名/密码身份验证。

这是为了让用户可以轻松地使用他们已经存在的苹果账户来验证论坛的身份，而不必再创建一个额外的用户账户。您只需使用“登录Apple”即可登录论坛。

不允许访问论坛的用户的登录页面是一个应用程序门户，您可以在其中提供有关您自己的信息，这些信息由论坛版主评估以供批准。

当您提交使用论坛的申请时，您提供了几乎所有的帐户价值，就像您正常注册Jive论坛一样。这将允许Jive论坛根据您的IDMSA cookie知道您是谁，因为它会将您属于Apple帐户的电子邮件地址绑定到论坛。

在注册使用论坛的应用程序页面上隐藏的其中一个值是“Password”字段，其值为“#INVALID#%！3”。当您提交包含用户名、名字和姓氏、电子邮件地址和雇主的申请时，您还提交了一个“密码”值，然后该值被秘密绑定到您的帐户，该帐户来自页面上的一个隐藏输入字段。

在观察到隐藏的默认密码字段后，我们立即有了一个想法，即找到一种方法来手动验证应用程序并访问论坛的批准帐户，而不是尝试使用“登录Apple”系统进行登录。我们之所以调查这一点，是因为我们每个人在各自的注册上的密码都是相同的。

如果任何人申请使用此系统，并且存在可以手动验证的功能，您只需使用默认密码登录到他们的帐户，即可完全绕过使用Apple登录。

乍一看，您似乎无法手动进行身份验证，但经过几次Google搜索后，我们发现了一个“cs_login”端点，该端点用于使用用户名和密码登录Jive应用程序。当我们手动形成测试HTTP请求以验证Apple Distdicated Developers应用程序时，我们发现它试图通过显示不正确的密码错误来验证我们的身份。当我们使用之前申请的我们自己的帐户时，申请出错，不允许我们进行身份验证，因为我们还没有获得批准。如果要进行身份验证，我们必须找到已获批准的成员的用户名。

此时，我们将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”功能之一来完全危害应用程序。

在攻击苹果时，我们经常考虑的问题是，他们是否有任何与其产品的制造和分销相关的可获得的服务。事实证明，有一款名为DELMIA Apriso&34；的应用程序是第三方全球制造套件，它似乎提供了各种仓库解决方案。

遗憾的是，这项技术似乎没有太多可用的交互，因为您只能从可用的界面登录和重置密码。

在试图在有限的页面数量上查找漏洞后，发生了一些奇怪的事情：我们被认证为一个名为"；Apple No Password User"；的用户，这是基于站点右上角出现的一个栏。

发生的情况是，通过单击重置密码，我们暂时被验证为拥有使用该页面的权限的用户。

应用程序的身份验证模式有效，而用户拥有使用特定页面的特定权限。重置密码页面被视为页面本身，因此为了让我们使用它，应用程序自动将我们登录到能够使用该页面的帐户。

为了提升我们的权限，我们尝试了各种方法，但似乎很长一段时间都没有取得任何进展。过了一段时间后，我们向OAuth端点发送了一个HTTP请求，试图生成一个授权载体，我们可以使用该授权载体来探索API。这是成功的！

我们的用户帐户，即使其权限仅限于授权和重置密码，也可以生成有权访问应用程序API版本的载体。

我们现在能够探索API，并希望找到一些权限问题，这将允许我们危害应用程序的某些部分。幸运的是，在我们的侦察过程中，我们发现了应用程序的API请求列表。

遗憾的是，我们无法访问大多数API调用，但是像操作部分这样的部分披露了大量可用的功能。

如果命中"；/Apriso/HttpServices/api/platform/1/Operations"；端点，它将返回近5,000个不同API调用的列表。除了我们最初发送的初始授权载体之外，所有这些都不需要身份验证。这里披露的行动包括像这样的事情。

您可以向特定操作发送GET请求，并使用以下格式接收预期参数：

{"；InputTypes"；：{"；OrderNo"；："；字符"；，"；订单类型"；："；整数"；，"；操作序列编号"；："；字符"；，"；注释"；："；字符"；，"；strStatus"；："；字符"；，"；用户名"；："；字符"；}，"；OutputTypes"；：{}，"；OperationCode"；："；APL_Redated"；，"；OperationRevision"；："；APL.1.4"；}。

这花了一些时间，但过了一段时间后我们意识到，为了真正调用API，您必须以以下格式发送包含JSON数据的POST请求：

上面的格式(事后)看起来非常简单易懂，但在黑客入侵时，我们完全不知道如何形成这个呼叫。我甚至试着给提供软件的公司发电子邮件，询问你应该如何组织这些API调用，但他们没有回复我的电子邮件，因为我没有订阅这项服务。

我花了近6个小时试图弄清楚如何形成上面的API调用，但在我们弄清楚之后，一切都非常顺利。CREATE EMPLOYEE&34；函数需要依赖于UUID的各种参数，但我们能够通过另一个操作检索这些参数，并在进行过程中填充它们。

发布/Apriso/HttpServices/api/platform/1/Operations/redacted HTTP/1.1主机：Colormaster s.apple.com授权：持有者编辑连接：关闭内容-类型：应用程序/json内容-长度：380{"；输入"；：{"；名称"；："；塞缪尔·库里"；，"；员工编号"；："；密文"；，"；登录名"；："；您的登录名123"；，"；密码"；："；您的密码123"；，"；语言ID"；："；密文"；，"；AddressID"；："；密文"；，"；联系人ID"；："；密文"；，"；默认设备"；："；密文"；"；部门"；："；"；，"；DefaultMenuItemID"；："；密文"；，"；角色名"；："；密文"；，"；Workcenter"；："；"；}}

在我们发送此API调用之后，我们现在可以作为应用程序的全局管理员进行身份验证。这给了我们对仓库管理软件的完全监督，并可能通过一些公认的功能对RCE进行监督。

有成百上千种不同的功能会导致大量的信息泄露，并能够扰乱似乎是用于库存和仓库管理的一个有点关键的应用程序。

存储的跨站点脚本漏洞存在漏洞，使得攻击者能够通过修改后的电子邮件窃取iCloud数据。

苹果基础设施的核心部分之一是他们的iCloud平台。该网站作为苹果产品的照片、视频、文档和应用程序相关数据的自动存储机制。此外，该平台还提供像Mail和Find My iPhone这样的服务。

邮件服务是一个完整的电子邮件平台，用户可以在这里收发类似于Gmail和Yahoo的电子邮件。此外，iOS和Mac上都有一个默认安装在产品上的邮件应用程序。邮件服务与所有其他服务(如文件和文档存储)一起托管在“www.icLoud.com”上。

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

邮件应用程序的工作方式非常简单。当服务接收到一封电子邮件并且用户打开它时，数据被处理成一个JSON BLOB，该BLOB由JavaScript进行清理和挑选，然后显示给用户。

这意味着在内容卫生方面不存在电子邮件的服务器端处理，呈现和处理邮件正文的所有实际功能都在JavaScript中完成，在客户端完成。这不一定是一件坏事，但通过了解我们需要在源代码中具体中断什么，简化了识别XSS的过程。

在测试此功能时，我最终弄乱的一件事是“<；style>；”标记。这个标记很有趣，因为DOM只会取消以“<；/style>；”标记结尾的元素。这意味着，如果我们编写了“<；style>；<；script>；alert(1)<；/script>；<；/style>；”，并且它完全呈现在DOM中，则不会出现警告提示，因为标签的内容严格是css，脚本标签被填充在标签内，而不是在结束标签之外。

从清理的角度来看，Apple在这里唯一需要担心的事情就是结束样式标签，或者如果页面上有敏感信息，通过导入链接进行CSS注入。

我决定专注于尝试打破苹果意识不到的风格标签，因为如果可以实现，这将是一个非常简单的存储XSS。

我对此进行了一段时间的尝试，尝试了各种排列，最终观察到一些有趣的事情：当电子邮件中有两个样式标记时，样式标记的内容将连接在一起成为一个样式标记。这意味着，如果我们可以将“<；/sty”放入第一个标记，并将“le>；”放入第二个标记，那么就有可能欺骗应用程序，使其认为我们的标记仍处于打开状态，而实际上它并没有打开。

那封电子邮件突然出现在我的收件箱里。我点击了它。有警报提示！它起作用了！

由于邮件应用程序托管在“www.icLoud.com”上，这意味着我们有浏览器权限来检索iCloud服务的相应API的HTTP响应(如果我们可以偷偷进入JavaScript以联系它们的话)。

在这一点上，我们决定最酷的概念证明是窃取受害者的所有个人信息(照片、日历信息和文档)，然后将相同的漏洞转发给他们的所有联系人。

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

对我们来说幸运的是，该服务是一个邮件客户端。我们可以简单地使用JavaScript来调用。

.