SIP和信任提供者劫持

对手可能会篡改SIP和信任提供者组件，以在进行签名验证检查时误导操作系统和应用程序控制工具。在用户模式下，Windows Authenticode(引用: Microsoft Authenticode)数字签名用于验证文件的来源和完整性，这些变量可能用于建立对签名代码的信任（例如，具有有效Microsoft签名的驱动程序可能被视为安全）。签名验证过程由WinVerifyTrust应用程序编程接口（API）函数处理，(引用: Microsoft WinVerifyTrust)该函数接受查询并与适当的信任提供者协调，信任提供者负责验证签名的参数。(引用: SpectorOps Subverting Trust Sept 2017) 由于可执行文件类型和相应签名格式的多样性，Microsoft创建了称为主题接口包（SIP）的软件组件(引用: EduardosBlog SIPs July 2008)，以在API函数和文件之间提供抽象层。SIP负责启用API函数创建、检索、计算和验证签名。大多数文件格式（可执行文件、PowerShell、安装程序等）都有唯一的SIP，目录签名提供了一个通用的解决方案(引用: Microsoft Catalog Files and Signatures April 2017)，并由全局唯一标识符（GUID）标识。(引用: SpectorOps Subverting Trust Sept 2017) 类似于代码签名，对手可能会滥用此架构来颠覆信任控制并绕过仅允许合法签名代码在系统上执行的安全策略。对手可能会劫持SIP和信任提供者组件，以误导操作系统和应用程序控制工具将恶意（或任何）代码分类为签名代码：(引用: SpectorOps Subverting Trust Sept 2017) * 修改HKLM\SOFTWARE[\WOW6432Node]Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllGetSignedDataMsg{SIP_GUID}中的Dll和FuncName注册表值，这些值指向提供SIP的CryptSIPDllGetSignedDataMsg函数的动态链接库（DLL），该函数从签名文件中检索编码的数字证书。通过指向恶意制作的DLL，该DLL导出的函数始终返回已知的良好签名值（例如，Microsoft签名的便携式可执行文件），而不是文件的真实签名，对手可以将可接受的签名值应用于使用该SIP的所有文件(引用: GitHub SIP POC Sept 2017)（尽管可能会发生哈希不匹配，从而使签名无效，因为函数返回的哈希与从文件计算的值不匹配）。 * 修改HKLM\SOFTWARE[WOW6432Node]Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData{SIP_GUID}中的Dll和FuncName注册表值，这些值指向提供SIP的CryptSIPDllVerifyIndirectData函数的DLL，该函数验证文件的计算哈希与签名哈希值是否匹配。通过指向恶意制作的DLL，该DLL导出的函数始终返回TRUE（表示验证成功），对手可以成功验证使用该SIP的任何文件（具有合法签名）(引用: GitHub SIP POC Sept 2017)（无论是否劫持前面提到的CryptSIPDllGetSignedDataMsg函数）。此注册表值也可以重定向到现有DLL中的适当导出函数，从而避免在磁盘上放置和执行新文件的要求。 * 修改HKLM\SOFTWARE[WOW6432Node]Microsoft\Cryptography\Providers\Trust\FinalPolicy{trust provider GUID}中的DLL和Function注册表值，这些值指向提供信任提供者FinalPolicy函数的DLL，该函数是解码和解析签名并进行大多数信任决策的地方。类似于劫持SIP的CryptSIPDllVerifyIndirectData函数，此值可以重定向到现有DLL中的适当导出函数或恶意制作的DLL（尽管信任提供者的实现很复杂）。 * 注意： 通过DLL搜索顺序劫持也可以在不修改注册表的情况下进行上述劫持。劫持SIP或信任提供者组件还可以启用持久代码执行，因为这些恶意组件可能会被任何执行代码签名或签名验证的应用程序调用。(引用: SpectorOps Subverting Trust Sept 2017)