先为我们的同学@dwj1210鼓鼓掌👏。作为围观了整个漏洞从发现到最终形成本篇文章的同学。小编前面先说一句：本次漏洞发现非常巧合，前些天给WMCTF出题的时候，dwj同学突然小声念叨好像挖到了一个RCE。于是在出完题后，我们开始了给Apple提交漏洞帮助Apple修复的漫长之路，也就有了dwj这篇文章。以下就是dwj同学的自述：

该漏洞由 Safari 浏览器 中的一个恶意页面引入，当你点击一个 URL Schemes 或 Universal Links 的链接时，可以通过这个特殊的 URL 调起指定 App 并传入攻击荷载。如果在 Safari浏览器中输入sms://可以调起信息 App，此时会有一个弹框询问是否允许打开。

但是一些内置的 Apple 应用程序是被 Safari 浏览器信任的，不会询问用户直接拉起，这些应用程序被硬编码在系统代码中：

早在 Pwn2Own 2014 年韩国黑客 lokihardt 通过一个特殊的 URL 在 iTunes Store 打开了任意的网页：

而 itms:// 就是 iTunes Store 注册的 URL Scheme，由于应用程序白名单的缘故不需要向用户询问就可以直接在 iTunes Store 中打开恶意的网页。

后面苹果加入了域名限制，只有域名后缀满足 trustedDomains 域名列表时才会打开，但是 lokihardt 又找到了一个信任域的 DOM xss 又打了一次。

之后沉寂多年，在 2020 年天府杯上，cc 师傅凭借完整的 full chain exploit 远程破解了搭载 iOS14.2 的 iPhone11 设备。

而该漏洞利用链的第一步依然是从 Safari 到 iTunes Store，不利用内存破坏，不执行 shellcode，通过一个特殊的 URL 可以绕过域名白名单的校验执行任意的 javascript 代码，触发 xss 弹计算器。

感兴趣的朋友可以直接研读 cc 师傅的文章：《CVE-2021-1748：从客户端 XSS 到弹计算器》 https://codecolor.ist/2021/08/04/mistuned-part-i/

iTunes Store 中有一段逻辑，当传入的 URL Scheme 中有一个特殊的参数时，应用就会忽略 URL 的 host，直接加载 URL Scheme 参数中的 URL 进行加载，比如：

iTunes Store 在启动的时候会从这个URL拉取一个 XML 文件，XML 文件中的 trustedDomains 字段中预置了 Apple 的可信域名：

只有页面的主机名和 trustedDomains 字段的后缀匹配，该页面才会被允许在 iTunes Store 中打开。

域名校验在-[ISURLBag urlIsTrusted:]函数中，但是该函数的域名校验存在缺陷。当你传入的 URL 为http://@www.apple.com:@www.hacker.com 时，iOS 系统在通过 -[NSURL host]函数取 host 时会取到www.apple.com，但是实际打开的页面却是 www.hacker.com。据了解在 Android 平台同样存在类似的问题。

iTunes Store 打开网页使用的 SUWebView 通过  JavaScript bridge 注入了许多功能；SUWebView 将 SUScriptInterface 类的方法导出到 js 上下文中。这些 API 被放在全局作用域的 iTunes 命名空间里。

另外在这个 WebView 中向任意域名发送请求，都会带上部分 iTunes Store cookie 信息: