公开披露Apple代码签名第三方漏洞
与以前的某些作品不同，此漏洞不需要管理员权限，不需要JIT代码或内存损坏即可绕过代码签名验证。 您所需要的只是格式正确的Fat / Universal文件，验证代码签名将显示有效的结果。
总结
- 发现第三方API用于签名代码的绕道而行，可以让您呈现Apple签名的任何代码。
- 通知所有知名的开源供应商和项目（请参阅下面的列表）。 修补程序可供他们使用。
- 该问题有可能会影响使用Apple官方代码签名API的其他第三方程序。
- 开发人员负责正确使用代码签名API。 有用于测试的演示黑客工具（PoC）。
- 仅适用于macOS和旧版本的OSX。
受影响的供应商
- 病毒总计-CVE-2018-10408
- Google-圣诞老人，molcodesignchecker-CVE-2018-10405
- Facebook-OSQuery-CVE-2018-6336
- 目标开发-LittleSnitch-CVE-2018-10470
- F-Secure-xFence（也是LittleFlocker）CVE-2018-10403
- 目标-请参阅-WhatsYourSign，ProcInfo，KnockKnock，LuLu，TaskExplorer（和其他）-CVE-2018-10404
- Yelp-OSXCollector-CVE-2018-10406
- 炭黑-Cb响应-CVE-2018-10407
代码签名的重要性及其在macOS / iOS上的工作方式
代码签名是一种安全结构，使用公钥基础结构（PKI）对已编译的代码甚至脚本进行数字签名，以确保它是受信任的并且代码是真实的。 在Windows上，几乎可以对所有内容进行加密签名：从.NET二进制文件到PowerShell脚本。 在macOS / iOS上，代码签名主要是指Mach-O二进制文件和应用程序包，以仅在内存中执行受信任的代码。
防病毒软件，安全系统和事件响应以及取证工具会分析签名，以在不可信的代码中识别出可信的代码。 签名验证可加快分析速度。 各种工具使用代码签名信息来实施安全措施：白名单，防病毒，事件响应和威胁搜索系统。 在一种流行的操作系统中破坏代码签名意味着破坏许多常规信息安全操作所依赖的基本安全性结构。
在代码签名（
1,2,3,4,5）中已经发现问题。 与以前的某些作品不同，此漏洞不需要管理员权限，不需要JIT代码或内存损坏即可绕过代码签名验证。 您所需要的只是格式正确的Fat / Universal文件，验证代码签名将显示有效的结果。
漏洞详情
该漏洞的本质是未使用Mach-O加载程序和代码签名API来错误地验证代码签名。 可以使用特制的Universal / Fat二进制文件来利用这种差异。
什么是Fat /通用文件？Fat / Universal是一种二进制格式，包含几个Mach-O文件（可执行文件，Dyld或程序包），每个文件都针对特定的CPU体系结构（例如i386，x86_64或PPC）。
先决条件
- Fat / Universal文件中的第一个Mach-O必须由Apple签名，它可以是i386，x86_64文件，甚至是PPC。
- 对于MacOS x86_64，必须在i386下编译自签名的恶意二进制或无关代码。
- 必须将Apple二进制文件的Fat头中的CPU_TYPE设置为无效的处理器类型或不是主机芯片组固有的类型。
在不传递相关
SecRequirementRef和
SecCSFlags的情况下 ，代码签名API（
SecCodeCheckValidity ）程序接口将检查Fat / Universal文件中的第一个二进制文件以查找签名的来源（例如Apple），并确保签名是真实的。 然后，API将检查Fat / Universal文件中的所有其他二进制文件，以确保团队标识符合规性和签名真实性，但
不检查证书颁发机构的信任根 。 恶意代码或“未签名”代码必须为i386的原因是，默认情况下将代码签名API配置为检查本机CPU体系结构（x86_64）的代码签名。
自签名代码成功通过测试的原因之一是因为即使在主要的Apple二进制文件中，TeamIdentifier字段也设置为
not set 。 下图显示了由Apple（python.x64）签名的有效Mach-O二进制文件，位于自签名Mach-O（ncat.i386）的旁边。 两者都有`TeamIdentifier = not set`。
例如，我使用开发人员ID对二进制文件进行签名，并尝试在lipo中将其与Apple二进制文件合并为一个Fat / Universal文件。 这种类型的代码签名失败。
我最初的PoC是ncat（来自nmap），我将其称为ncat.frankenstein。 在这里，生成的Fat文件包含Apple签名的python x86_64二进制文件和ncat i386自签名（即席）二进制文件。 使用
codesign -s - target_mach-o_or_fat_binary可以轻松创建自签名二进制文件。 这是MachOView中的样子：
如果运行此文件，则python x86_64将启动：
并且代码签名正在验证中：
我如何运行ncat自签名二进制文件？
通过设置无效的CPU_Type类型或非本地CPU（例如，PPC）来完成此操作。 然后，Mach-O加载程序会跳过带有有效签名的Mach-O二进制文件，并执行恶意代码（未由Apple签名）：
然后执行ncat.frankenstein，验证结果将
valid ：
我们
发布了 ncat.frankenstein和其他四个示例，以便开发人员可以检查其产品中的漏洞。
推荐建议
在命令行取决于您如何验证签名的代码。 如果您使用codesign，则您可能熟悉以下命令：
codesign –dvvvv证书颁发机构转储和TeamIdentifier（开发人员ID）codesign –vv –严格验证所有架构
但是要正确检查这种类型的滥用，您需要使用以下
命令添加锚证书要求：
codesign -vv -R='anchor apple' ./some_application_or_mach-o ＃用于Apple签名的代码codesign -vv -R='anchor apple generic' ./some_application_or_mach-o ＃用于Apple和Apple签名的代码
当检查带有他人签名的代码时，这样的命令将显示错误：
您可以使用
spctl命令，但是它需要仔细分析命令的输出。 例如，带有Apple（/ bin / ls）和Safari签名的Mach-O二进制返回以下内容：
这是Apple签名的应用程序的结果：
注意/ bin / ls的“（该代码有效，但似乎不是应用程序）”行，该行未通过测试。 为了进行比较，这是Fat / Universal ncat.frankenstein文件的结果：
ncat.frankenstein Fat / Universal文件未显示该代码有效。 因此，我不建议使用
spctl手动检查脱机Mach-O二进制文件。 只需使用带有适当标志的codesign。
对于开发人员通常，开发人员使用带有以下标志的
SecStaticCodeCheckValidityWithErrors（）或
SecStaticCodeCheckValidity（）API检查Mach-O或Fat / Universal二进制文件：
这些标志应确保对加载到Mach-O或Fat / Universal文件中的内存中的所有代码进行加密签名。 但是，默认情况下，这些API不会提供适当的验证，因此第三方开发人员需要隔离Fat / Universal文件中的每种体系结构，并验证身份是否匹配并且在密码上是否可靠。
测试Fat / Universal文件中每个嵌套体系结构的最佳方法是，首先使用需求“ anchor apple”调用
SecRequirementCreateWithString ，然后使用
kSecCSDefaultFlags | SecStaticCodeCheckValidity | kSecCSCheckNestedCode | kSecCSCheckAllArchitectures | 参照要求进行的
kSecCSEnforceRevocationChecks ; 如修补的
WhatsYourSign源代码中
所示 。
将“ anchor apple”传递给SecRequirmentCreateWithString函数，此调用的工作方式类似于codesign
codesign -vv -R='anchor apple'命令，要求Fat / Universal文件中所有嵌套二进制文件都具有Apple Software Signing信任链。 另外，通过传递标志和SecStaticCodeCheckValidity的要求，将检查所有体系结构的此要求，并应用吊销检查。
示威
苹果公司的
codesign工具和需要使用
-R标志。
LittleSnitch-检查磁盘上的Fat / Universal文件不起作用，但是LittleSnitch可以正确检查内存中的进程。
LittleFlocker-F-Secure购买了LittleFlocker，现在将其称为xFence。
F-Secure xFence（以前为LittleFlocker）
物镜工具
任务浏览器
你的星座
Facebook OSquery是恶意软件样本和/ bin / ls的有效示例。
Google Santa发行-Fileinfo显示ncat.frankenstein已列入白名单：
拒绝ncat（无符号）执行和ncat.frankenstein执行权限：
Santa.log日志显示了先前示例中的事件：
炭黑反应
VirusTotal-在VirusTotal中安装补丁之前的bash_ppc_adhoc示例：
披露日期
2018年2月22日：报告和PoC已发送给Apple以绕过第三方安全系统。
2018年3月1日：Apple答复说第三方开发人员应将kSecCSCheckAllArchitectures和kSecCSStrictValidate与SecStaticCodeCheckValidity API一起使用，并且开发人员文档将相应更新。
2018年3月6日：已将报告和PoC发送给Apple以绕过标志并严格检查
codesign 。
2018年3月16日：已将其他信息发送给Apple。
2018年3月20日：苹果表示，它不认为这是应直接解决的安全问题。
2018年3月29日：苹果表示可以更新文档，但是“ [...]第三方开发人员应该做更多的工作，以验证通用二进制文件中的所有身份是否相同，如果他们想提供有意义的结果。”
2018年4月2日：首次与CERT / CC联系并随后进行合作以阐明漏洞的范围和影响。
2018年4月9日：与CERT / CC协调通知所有受此漏洞影响的知名第三方开发人员。
2018年4月18日：最后与CERT / CC联系，建议在博客上公开披露信息最适合通知其他私下使用Apple的代码签名API的第三方开发人员。
2018年6月5日：发布前与开发人员进行最终联系。
2018年6月12日：信息披露。
总结
感谢所有第三方开发人员在解决此问题方面的辛勤工作和专业精神。 代码签名漏洞尤其会使人沮丧，尤其是对于那些试图提供比操作系统默认值更好的安全性的公司。
GMO GlobalSign俄罗斯针对Habr订户的行动
您可以通过致电+7（499）678 2210与GlobalSign经理联系来获取更多信息，或
在网站上填写促销代码CS002HBFR的表格。