CloudKit 是一个允许 App 开发者将键值数据、结构性数据和资源储存在 iCloud 中的框架。对 CloudKit 的访问通过 App 授权进行控制。CloudKit 支持公共数据库和专用数据库。公共数据库被 App 的所有副本使用（通常用作一般性资源），且不加密。专用数据库储存用户的数据。与 iCloud 云盘一样，CloudKit 使用基于帐户的密钥来保护储存在用户专用数据库中的信息，且与其他 iCloud 服务类似，会使用第三方服务对文件进行分块、加密和储存。CloudKit 使用密钥层级，与数据保护类似。文件独有密钥由 CloudKit 记录密钥封装。记录密钥则会受到区域作用域内密钥的保护，而区域作用域内的密钥则受到用户的 CloudKit 服务密钥的保护。CloudKit 服务密钥储存在用户的 iCloud 帐户中，只有在用户使用 iCloud 认证后才可使用。
捷径 Shortcuts，是 iOS 平台上的流程自动化效率增强APP，在iOS 13版本，已集成到系统中。它能通过流程自动化来处理手机上各种需要复杂、重复操作的事务，让你运行一次就完成一系列的操作。
Shortcuts，原名为Workflow。自苹果官方关注到它的巨大运用价值后，便收购过来，改名为Shortcuts，中文名为捷径。Shortcuts捷径在 iOS 相对么封闭的系统中，释放了用户的想象力、解放了繁琐操作，堪称效率应用中的佼佼者。
Apple 的数据存储框架 CloudKit 具有各种访问控制，这些访问控制可能会被漏洞配置，甚至是 Apple 自己，这会影响 Apple 自己使用 CloudKit 的应用程序。这篇文章详细解释了 Frans Rosen 在分析 Cloudkit 时在 iCrowd+、Apple News 和 Apple Shortcuts 中发现的三个严重程度不同的漏洞。
研究人员在分析时首先创建一个带有名称的容器，格式为反向域名结构，如 com.apple.xxx，因为创建的所有容器都将从 iCloud 开始。
在容器内部，有两个环境，分别是开发环境和运行环境。
在环境中，研究人员会设置三个不同的域，分别是私有、共享和公共。私有只能由自己的用户访问，共享用于在用户之间共享数据，公共可供任何人访问，某些部分具有公共 API 令牌，而某些部分具有身份验证。
在每个作用域中，研究人员都可以创建不同的区域，且默认区域被称为_defaultZone。在每个区域内，都可以创建不同的记录类型。
每个记录类型可以包含不同的记录字段，这些字段可以保存不同类型的数据，如 INT、BOOLEAN、TEXT、BINARY 等。
每个区域也有各自的记录，每个记录总是连接到一个记录类型。当然，它还有更多功能，例如创建具有权限的索引和安全角色的能力。
对于私有和共享作用域，研究人员始终需要以自己的身份进行身份验证。对于公共作用域，可以在不进行个人身份验证的情况下读写该作用域。研究人员也可以启用允许他们访问公共作用域的公共令牌，但是通过将身份验证与自己的用户相结合，研究人员可以访问私有和共享作用域。
了解所有不同的身份验证流程和安全角色非常复杂，让我感到好奇的是，不仅对研究人员来说很复杂，而且对 Apple 内部使用它的团队来说也很复杂。
为了了解苹果自己在哪里使用了CloudKit服务，研究人员开始了解所有不同的应用程序是如何连接到它的。通过代理iPad、浏览器和所有应用程序，他们可以收集大量的请求和响应。仔细查看之后，他们注意到苹果使用不同的方式连接到CloudKit。
iCloud 资产，如 www.icloud.com 上的笔记和照片使用了一个 API：
而icloud.developer.apple.com的开发者门户网站有一个不同的API ：
许多 iOS 应用程序在 gateway.icloud.com 上使用了第三个 API。此 API 使用标头来指定正在使用的容器，这些请求几乎总是使用 protobuf：
如果你使用CloudKit Catalog来测试CloudKit API，它将改为使用 api.apple-cloudkit.com：
对于 CloudKit Catalog，研究人员需要一个 API 令牌来访问公共作用域。当他们尝试连接到拦截 iOS 应用程序时看到的 CloudKit 容器时，由于缺少完成身份验证流程所需的 API 令牌而失败。
iCrowd+
在测试 Apple 的所有应用程序和子域时，Apple 制作的一个网站实际上使用了 api.apple-cloudkit.com 并提供了 API 令牌。
转到 https://public.icrowd.apple.com/，可以看到在 Javascript 文件中使用的容器：
然后它请求获取 iCrowd+ 应用程序的当前版本，以便在开始页面显示该版本：
研究人员还可以在网站发出的请求中看到它正在查询数据库的记录，记录类型称为Updates：
由于我有令牌，我可以使用 CloudKit Catalog 连接到容器：
查看公共作用域的记录，我可以看到网站为使用按钮的版本数据而获取的数据：
然后研究人员尝试将他们的记录添加到同一个区域：
回应如下：
当再次访问https://public.icrowd.apple.com/，看到的如下内容：
这意味着以修改网站的数据。
概念证明视频请点击这里。
这意味着可能存在与权限相关的其他漏洞，并且公共作用域是最有趣的一个，因为它是在所有用户之间共享的。研究人员将继续寻找使用 CloudKit 数据库的位置的过程。
苹果在2月25日做出回应，并修复了这个漏洞，从 https://public.icrowd.apple.com/ 网站上完全删除了 CloudKit 的使用。
由于研究人员位于瑞典，而由于在瑞典无法访问Apple News，所以他们在美国创建了一个新的Apple ID来使用它。一进来，就注意到所有的新闻都是使用CloudKit提供的，所有文章都是从公共作用域提供的。这是有道理的，因为所有用户的新闻内容都是一样的。研究人员还可以看到 iOS 上的 Stock 应用程序也从同一个容器中获取：
不过，通过gateway.icloud.com使用CloudKit API有点困难。所有的通信都是通过protobuf进行的。有一个很棒的项目叫做InflatableDonkey，它试图从iOS 9中逆向工程iCloud备份过程。由于该项目只专注于获取数据，Protobuf 中的很多方法都没有完全逆向，所以研究人员不得不使用暴力尝试找到修改所需的方法，并且由于 Protobuf 是二进制的，所以研究人员真的不需要专有名称，由于格式的设计方式，protobuf 中的每个属性都是可枚举的：
我花了太多时间，大约两天,但是当研究人员发现可以使用的方法，在公共作用域内修改记录仍然需要我的用户授权，研究人员一直无法弄清楚如何生成适当作用域的 X-CloudKit-AuthToken，因为他们主要对私人作用域感兴趣。
但还记得我提到过不同的 API 与 CloudKit 的通信方式不同吗？
研究人员登录到 www.icloud.com 并进入Notes-app，它使用 p55-ckdatabasews.icloud.com 与 CloudKit 通信：
然后研究人员将容器从 com.apple.notes 更改为 com.apple.news.public 并改为使用公共作用域。在这篇文章中，你可以看到使用应用程序在protobuf通信到gateway.icloud.com：
回应是：
研究人员还核实了库存数据是否真的存在：
结果如下：
成功！现在可以使用 p55-ckdatabasews.icloud.com 上的经过身份验证的 API 与 com.apple.news.public-container 通信了。
研究人员还设置了一个不同的Apple ID作为新闻发布程序，这样他们就可以创建文章草稿并为Apple News应用创建一个发布渠道。研究人员创建了一个渠道并发布了一篇文章，并开始测试与它们的通话。由于使用了Apple ID向API发出请求，如果可以修改内容，则意味着可以修改任何文章或库存数据。
拥有的频道 ID 是 TtVkjIR3aTPKrWAykey3ANA，进行查找查询：
测试通道如下：
在研究人员的iPad上，他们还通过https://apple.news/TtVkjIR3aTPKrWAykey3ANA验证，并可以在苹果新闻应用程序中看到创建的频道。
然后，研究人员根据 CloudKit 文档尝试了使用记录/修改对记录可能使用的所有方法：创建、更新、强制更新、替换、强制替换、删除和强制删除。
所有方法的响应都是这样的：
但是，在 forceDelete 上：
回应如下：
研究人员在 Apple News 中重新加载了频道：
这让研究人员确信，他们可以删除stock和Apple News ios应用程序使用的容器com.apple.news.public中的任何频道或文章，包括stock条目。这是因为他们可以从 www.icloud.com 上用于 Notes-app 的 API 对 CloudKit 进行身份验证调用，也因为com.apple.news.public-container中添加的记录配置漏洞。
苹果的回应
苹果公司在 3 月 19 日通过修改添加到 com.apple.news.public 的记录的权限进行了修复，即使是 forceDelete 调用也会响应：
研究人员还通知了苹果，他们自己的容器仍然有能力删除内容，然而，不清楚这些容器是否真的在使用公共范围。
Shortcuts
另一个使用 CloudKit 公共作用域的应用程序是Shortcuts。使用 Apple Shortcuts，你就可以创建可以自动或手动启动的逻辑流程，然后在 iOS 设备上的应用程序中触发不同的操作。这些Shortcuts可以使用 iCloud 链接与其他人共享，从而围绕他们创建一个生态系统，有一些网站专门通过 iCloud 链接推荐和分享这些Shortcuts。
如上所述，CloudKit 容器中有一个共享作用域。当你决定共享任何私人内容时，通常会使用此作用域。你会得到一个叫做 Short GUID 的东西，它看起来像 0H1FzBMaF1yAC7qe8B2OIOCxx，可以使用 https://www.icloud.com/share/[shortGUID] 访问。
但是，Apple Shortcuts 链接的工作方式略有不同。当共享Shortcuts时，将在公共作用域内创建记录类型为 SharedShortcut 的记录。。所使用的记录名称将形成一个 GUID：EA15DF64-62FD-4733-A115-452A6D1D6AAF，然后记录名称将被格式化为不带连字符的小写字符串，最终变为：https://www.icloud.com/shortcuts/ea15df6462fd4733a115452a6d1d6aaf，这可URL可以被公开分享。
访问此 URL 将调用： https://www.icloud.com/shortcuts/api/records/ea15df6462fd4733a115452a6d1d6aaf ，这将从 CloudKit 返回数据：
这样研究人员很兴奋，因为他们已经可以看到一些攻击场景。如果攻击者可以修改其他用户的Shortcuts，那将是非常糟糕的。与Apple News漏洞相同，此漏洞也能够删除别人的Shortcuts。公共作用域还包含了在应用程序中显示的Shortcuts Gallery ：
因此，如果可以修改该内容，那将是利用漏洞的关键。
Shortcuts 应用程序本身使用了 gateway.icloud.com 上的 protobuf API：
由于研究人员已经花了很多时间修改 InflatableDonkey 来尝试所有方法，因此我现在还可以使用拦截中的 X-CloudKit-AuthToken 尝试进行授权调用以将记录修改为公共作用域。然而，所有实际进行修改的方法都给了我权限漏洞：
这让研究人员意识到通过 gateway.icloud.com 上的 API， X-CloudKit-AuthToken 不允许他们修改公共作用域内的任何记录。
由于研究人员已经通过 Apple News 报告了这些漏洞，并且苹果已经修复了这些漏洞，因此当研究人员尝试使用最初从 www.icloud.com 上的 Notes 中获取的相同 API 连接方法时，出现了如下结果：
这也失败了，无法通过 www.icloud.com 使用的身份验证访问容器 com.apple.shortcuts。
还记得上面提到过不同的 API 与 CloudKit 的通信方式不同吗？
通过icloud.developer.apple.com 并连接到我自己的容器，接受其中一个请求并将容器修改为 com.apple.shortcuts：
这很有效！研究人员可以通过使用记录/查找来验证这一点，并将 protobuf 内容中的 UUID 用于 iOS 应用程序中的gallery banner：
结果如下：
完美！这现在是研究人员与 Shortcuts 数据库通信的方式，来自 CloudKit 开发人员门户的 CloudKit 连接允许研究人员正确地对 com.apple.shortcut-container 进行身份验证。现在他们就可以开始检查公共记录的权限。最简单的方法是添加一个 Burp 替换规则，用 Shortcuts 容器 com.apple.shortcuts 替换任何请求数据中研究人员自己的容器 iCloud.com.mycontainer.test。
现在就可以开始从CloudKit文档中查看终端，并从 CloudKit 开发人员门户点击 UX。公共作用域内的记录无法修改或删除。研究人员在公共作用域内找到的一些记录类型是可索引的，这允许研究人员以列表的形式查询它们，但是，无论如何这都是公共信息。
例如，研究人员可以使用记录/查询来获取所有gallery banner：
但这不是漏洞，因为它们已经在应用程序中列出来了。
研究人员调查了订阅情况，它并没有像预期的那样在公共作用域发挥作用。
如上所述，每个作用域都有区域，默认区域被称为 _defaultZone。 公共作用域的有趣之处在于 CloudKit 开发人员门户的 UX 实际上告诉研究人员它不支持向公共作用域添加新区域：
但是，如果研究人员调用 com.apple.shortcuts 来列出所有区域，我可以看到它们在公共作用域内确实有更多区域，而不仅仅是默认区域：
我还可以添加新区域：
回应如下：
目前仅仅能做到删除研究人员自己的区域，其他任何人都不会使用或与这些区域进行交互。
区域的文档是有限的：
除了创建或删除，没有其他调用。
接下来，研究人员使用第二个 Apple ID 登录到 CloudKit 开发人员门户网站。然后尝试对第一个用户的容器执行相同的调用。
因此，如果我按预期尝试将不同的用户用于我自己的容器，则删除会失败。无法删除任何容器的默认区域。
研究人员现在的假设是删除尝试会导致上述漏洞。
尝试删除 metadata_zone：
会反馈一个漏洞：
这让研究人员确信创建区域并不是真正的漏洞，因为删除调用对现有调用不起作用，并且对创建新调用没有影响。研究人员还尝试了对 _defaultZone 的删除调用，因为他们确信会看到上面的漏洞即无法从公共默认区域中删除所有记录。
回应如下：
研究人员又做了一个区域/列表：
看来以上的假设是正确的，它并没有真正被删除。
突然，一个共享Shortcuts显示出了 404：
研究人员立马退出了Shortcuts应用程序并再次启动它：
于是，研究人员访问了一个共享一堆Shortcuts的网站，并用手机进行了测试：
这意味着删除确实以某种方式起作用，但 _defaultZone 从未消失。当研究人员尝试共享一个新的Shortcuts时，它也不起作用，至少一开始没有，很可能是因为记录类型也被删除了。
还没有评论，来说两句吧...