tp钱包app官方下载安卓：Windows App 运行控制机制 Smart App Control 的内部安全架构分析（下）

下面的伪代码或多或少地展示了 SmartLocker 非继承属性的最后一部分是如何工作的。 注意 : 根据稍后如何使用此函数中的值来填充 TraceLogging 字符串，我们知道防御措施将评估过程的所有这一部分视为 : Is 防御措施 Shell。 这或多或少就是我们通过在调用之后立即双击从资源管理器启动的进程所需要的： CipCheckSmartlockerEAandProcessToTokenPocket官方appken 的情况就这样了，现在再说说 CipExternalAuthorizationCallback。 现在，让我们说说 Intelligent Security Graph 所使用的代码段，它现在已被扩展以添加一些 SAC 功能。首先，将再次检查策略选项 Intelligent Security Graph Authorization（智能安全图授权），如果未设置，函数将使用从 CipCheckSmartlockerEAandProcessToken 获取的值退出。如果该值在策略中处于活动状态（SAC 策略就是这种情况），该函数将使用前面讨论的 IsTrustedSigning 来确定它是否应该继续。如果映像可信，将执行以下检查： 如果 ValidatedSigningLevel 等于 " 由使用 AMPPL ( 7 ) 的产品的 AV 签名 "，并且策略的值为 VerifiedAndReputableAllowAntiMalware，则分数将用值 AllowAnti Malware（0x100000）进行异或运算，函数将返回。 如果映像不可信，则函数将继续查询防御措施。如上所述，向防御措施发出查询的函数是 CiCatDbSmartlockerDefenderCheck。此函数将接收两个 MPFILE_TRUST_EXTRA_INFO 结构，一个填充请求数据，另一个接收回复数据。代码还将从 FileObject 传递 FileName。MPFILE_TRUST_EXTRA_INFO 结构如下所示。 双方之间的通信是使用 RPC 实现的，CI.dll 将实现客户端，服务器将在 cryptcatsvc.dll 中实现。为了记录，RPC 存根的 IID 是 f50aac00-c7f3-428e-a022a6b71bfb9d43。 cryptcatsvc 在服务 CryptSvc 中运行。在用于 RPC 服务器的发送函数中，我们重点关注以下函数： s_SSCatDBSmartlockerDefenderCheck   ( Already   present   in   22H1 ) ；s_SSCatDBSmartlockerDefenderCheck2   ( New   to   22H2 ) ；s_SSCatDBSendSmartAppControlBlockToast；s_SSCatDBSendSmartAppControlSwitchEnforceToast； SmartLockerDefenderCheck 函数的 v1 和 v2 之间的最大区别在于，在 v2 中，该函数接受请求和回复 MPFILE_TRUST_EXTRA_INFO 作为其参数的一部分。这两个函数最终都调用了助手函数 CatDBSmartlockerDefenderCheckHelper。 CI 将从这些函数调用 s_SSCatDBSmartlockerDefenderCheck2，它将首先加载 MpClient.dll。 注意：在第一次执行时，将在防御措施配置中启用 SmartLocker。该函数将调用 MpClient 导出的函数 MpSmartLockerEnable。此函数只需注册 Defender ELAM 证书信息（打开 Wdboot.sys 的句柄并调用 InstallELAMCertificateInfo），然后使用 RPC 从 MpSvc.dll 调用方法 ServerMpEnableSmartLocker，它将检查防御措施配置中是否设置了 SmartLockerMode，如果没有，它将写入。 打开库的句柄后，该函数将使用 CI.dll 提供的文件名来打开一个文件句柄，该句柄将被传递给 MpClient 导出的函数 MpQueryFileTrustByHandle2，该函数只在来自于 DefenderCheck2 时被调用，如果是旧版本的 DefenderCheck，则将调用 MpQueryFileTrustByHandle。 在 MpQueryFileTrustByHandle2 内部，代码将使用该文件的句柄来创建文件映射，该文件映射将被防御程序用于对其进行内存扫描。下面的 InSequence 函数将通过从 MpClient ( 客户端 ) 到 MpSvc ( 服务器 ) 发出 RPC 调用来执行。显然，我们刚才看到的所有函数调用都接受 CI.dll 设置的 MPFILE_TRUST_EXTRA_INFO 作为参数的一部分。 ServerMpRpcMemoryScanStart：设置 CMpMemScanContext 和 CMpMemScanEngineVfz（使用 GetAttributeTrustCheck 作为 GetAttributions 函数），并进行异步扫描； ServerMpRpcMemoryScanQueryNotification：检索扫描信息； ServerMpRpcMemoryScanClose：关闭并清除 CMpMemScanContext。 这些函数的内部结构不在本文所讲的范围，我想强调的是，当启用 SAC 时，防御措施将主动扫描文件并进行云查询。 从扫描检索到的信息中有三个可能的信号： 0x31001：检索到的 MPTRUST_INFO（IGS）； 0x31002：检索到的 MPFILE_TRUST_EXTRA_INFO（SAC）； 0x4005：与 RSIG_VIRINFO 相关； 最后完成防御措施通信，下图显示了代码到达防御措施时客户端（CI）和服务器（cryptcatsvc）堆栈。 需要注意的是，如果我们的 SAC 处于强制状态，并且设备中没有互联网连接，则默认操作是TokenPocket官方网站阻止该进程，并且将显示一条通知，提示 " 智能应用程序控制无法验证此应用程序，请检查您的互联网连接，然后重试 "。 返回外部授权回调，如果 RPC 调用失败，则未设置策略设置 VerifiedAndReputableAllowUnknown，并且 ValidateSigningLevel 不是以下任何一项： Microsoft   Store   signed   app   PPL   ( Protected   Process   Light ) Microsoft   Store-signedMicrosoft   signedWindows   signedOnly   used   for   signing   of   the   .NET   NGEN   compilerWindows   Trusted   Computing   Base   signed 然后将验证分数与值 Unattainable（0x40000）进行异或运算，函数将返回。如果 RPC 调用成功，则将调用函数 CiHandleDefenderSignals。顾名思义，此函数将处理防御措施发送回的消息。它将遍历返回的元素数，其中每个元素的类型为 MPFILE_TRUST_EXTRA_INFO。根据 ReplyType 字段，它将执行不同的操作。更有趣的两种情况是：首先，当返回信任结果时。在该示例中，信息将指向 MP_INFO_RESULT，其中的值将复制到验证上下文： 第二个有趣的示例是信息指向 MP_NW_CONTROL 枚举。在该示例中，根据控制命令，该功能将被禁用或切换到强制模式。这基本上将更新 VerifiedAndReputablePolicyState RegKey，并更新 WorkItem 中的策略。 在我们从学习模式更改为强制模式的情况下，将发出对函数 s_SSCatDBSendSmartAppControlSwitchEnforceToast 的 RPC 调用。在此函数中，DLL wldap . DLL 将被加载，然后调用函数 WldpSendSmartAppControlSwitchEnforceToast。 从信号处理程序回来后，有一些细微差别。如果 NW 控制命令设置了标志 IsUnfriendlyFile，则 Score 将更新为值 UnfriendalyFile（0x80000），函数将返回。如果未设置标志，则 TrustInfo 和 FileObject 将被传递到带有标志 0x82 的函数 CipSetFileCache 中，这意味着 EA   $Kernel.Purge.CIpCache 将用于存储此信息。 最后，需要根据防御程序返回的信任调整分数，有 5 个选项： Trust == 1：分数将使用值 0x202 进行异或运算，不过我对这个值不太了解； Trust == -1 ( 0xFFFFFFFF ) ：如果策略设置 VerifiedAndReputableAllowUnknown 被设置，则分数将使用值 AllowUnderknown（0x20000）进行异或运算； Trust == -2 ( 0xFFFFFFFE ) ：分数将使用值 Malicious ( 0x80 ) 进行异或运算； Trust == -3 ( 0xFFFFFFFD ) ：分数将用 PUA（0x100）值进行异或运算； 任何其他情况下，分数将用值 0x42 进行异或运算。 这几乎就是外部授权回调的全部内容，现在我们回到调用外部授权回调时的 SIPolicyValidateImageInternal！ SIPolicyValidateImageInternal 在进入外部授权回调之前，我们将讨论 SIPolicyObjectValidationEngine 函数如何遍历策略并调用内部 SIPolicy ValidateImageInternal，后者稍后将调用外部 auth 回调。现在，调用回调后，我们返回到 SIPolicyValidateImageInternal，并返回验证分数。如果启用了 SAC，则该函数将继续评估分数，并将此分数传播到验证引擎分数，并根据该得分设置相应的 NTSTATUS。 如上图所示，在大多数分支中，它会将相应的 NTSTATUS 设置为验证状态，然后跳转到我所称为 ProcessDbgAndReprieve 的状态。这只不过是一种检查内核调试器是否附加到调试器控制台中以记录策略冲突的方法。 如果未遵循前一个映像中的任何分支，或者分数为 Unattainable 但设置了 AllowUnknown，则函数将继续根据策略规范评估对象。首先检查文件规范，这将在函数 SIPolicyMatchFileRules 内完成。此函数将接收以下参数： 具有要评估的文件规范的策略； OriginalFileName；InternalName；FileDescription；ProductName； 我强烈建议阅读 MSDN 的 " 理解 Windows 防御应用程序控制 ( WDAC ) 策略规范和文件规范 " 一节，以了解更多关于策略规范和可用于它们的不同选项的内容。 与我们在第 1 部分中看到的 Policy Secure Settings 类似，该函数将使用作为 key 传递到函数 bsearch 的数据建立一个结构。关键结构具有以下原型： bsearch 函数的 base 和 num 将取自 SToken Pocket钱包I_POLICY 结构。将策略解析为 SI_policy 结构时，将设置一个包含两个场景的数组。每个场景都包含其特定的文件规范、允许的签名者、拒绝的签名者和异常规范。如上所述，当调用 SIPolicyMatchFileRules 时，要评估的场景的特定数量被传递给函数。此数字将用作函数的索引，以了解要选取 Scenarios 数组的哪个元素。每个场景都由以下结构表示： 如果没有 FileName 级别的文件规范匹配，则函数将继续计算哈希级别的文件规范： 如果 FileName 或 Hash 匹配，则 SIPolicyMatchFileRules 返回 TRUE，验证状态将设置为 status_SYSTEM_INTEGRITY_POLICY_VIOLATION。 如果对 SAC 策略使用的哈希和文件名感兴趣，可以查看策略的 FileRule 标签下的整个列表。 如果没有匹配的文件规范，则下一步（如果映像已签名）是根据 " 拒绝 " 和 " 允许 " 签名者验证签名链信息。首先，将检查被拒绝的签名者。如果与前面相同的规范在此匹配，该函数将把验证状态设置为 status_system_integrity_policy_violate。如果没有拒绝签名者规范匹配，代码将继续检查允许的签名者规范。在该示例中，如果存在匹配，则会清除以前的任何状态 / 分数。根据策略签名验证映像签名的过程主要在函数 SIPolicyValidateChainAgainstSigner 中完成。此函数将作为第一个参数接收映像的 SI_CHAIN_INFO，并在 @r8 中接收 POLICY_SIGNERS_DATA。 关于这个 POLICY_SIGNERS_DATA 结构，基本上 SI_POLICY 结构保留一个 POLICY-SIGNERS_DATA 数组。这些代表两种方案的所有 Allow 和 Deny 签名。代码知道哪些规范适用于哪个场景的方式，这意味着要使用 POLICY_SIGNERS_DATA 数组的哪个索引是非常聪明的。这是我之前在文件规范中没有解释的事情，所以现在是检查它的好时机。如果你返回并检查 SI_POLICY_SCENARIO 结构，将看到对于每个规范类型结构 ( file, Allow, Deny ) ，都有一个 SI_RULES 结构，其中包含一个我称为 IndexArray 的字段。基本上，这是一个索引数组，用于指示该特定场景和规则必须使用包含数据的数组中的哪个索引。让我们看一个快速的伪代码片段，以便更好地理解这一点。 这可能不是百分之百准确的，因为我省略了很多在中间进行的检查。 为了更好地了解签名是如何验证的，接下来你可以找到 POLICY_SIGNERS_DATA 的原型，注意，这将适用于允许签名者和拒绝签名者。 通过查看 SI_CHAIN_INFO 和 POLICY_SIGNERS_DATA，你可以或多或少地了解如何在 SIPolicyValidateChainAgainstSigner 函数中进行比较。最后，为了总结 Signer 规范的验证，下面是在 SIPolicyValidateChainAgainstSigner 条目处使用 SAC 强制策略验证 ProcessHacker 时记录的映像。 老实说，为了达到这张图片的目的，我不得不稍微修改代码流。因为在第一次签名检查时，Type 将匹配，然后它将退出循环。之所以会实现这一点，是因为这个 POLICY_SIGNERS_DATA 中的信息比第一个检查的要多。在第一次选中时，唯一的填充值是 Type（设置为 0x14）。我已尝试查找有关此 Type 值的信息，但找不到任何信息。 因此，在为每个活动策略和补充策略运行整个过程之后，我们将返回函数 CipApplySiPolicyEx，为每个 BasePolicy 提供一个 CI_VALIDATION_RESULT。补充策略的结果将写入与 BasePolicy 相同的 CI_VALIDATION_RESULT 中。此时，该函数只会遍历验证结果，将这些结果存储在 validation Context 中。此外，此时 SmartLocker 事件将记录在函数 CiLogSIPolicySmartlockerEvent 中。此处可以记录四种类型的事件： SmartlockerOperationalAudit   ( EventId:   3091 ) SmartlockerOperationalFailure   ( EventId:   3092 ) SmartlockerVerbose   ( EventId:   3088 ) SmartlockerOperationalSuccess   ( EventId:   3090 ) 我们几乎完成了，现在将进入调用堆栈，将验证状态传递到上面的函数。最后，我们将回到 CI 入口点 CiValidateImageHeader，与之前一样，我们不会对这个函数进行过多讨论。关于 SAC 唯一有趣的一点是，如果 SigningLevel 匹配以下任何一项： 尚未检查签名级别； 文件未签名； 受 Windows 防御措施应用程序控制策略信任； 开发者签名代码； SAC 结果是允许执行，然后将使用函数 CipInstrumentNightsWatchAllow 记录操作。此函数可以为提供程序 CodeIntegrity 编写四个基于 TraceLogging 的事件。具有以下名称的 NWActivityVerbose & CodeIntegrity.NWActivity。 执行此函数时，将记录 QuestionableAllow 或 Allow。如果采用了记录 QuestionableAllow 的路径，那么如果所需数据可用，还将写入 QuestionaleAllowSignatureInfo&OriginClaimData。 由于这些是基于跟踪日志记录的事件，我们需要使用一些特殊办法来捕获跟踪。值得庆幸的是，Matt 已经做了所有艰苦的工作来研究和记录这类事件的过程。看了他的文章《Windows RE 使用 WPP 和 TraceLogging》后，我们可以使用 powershell 中的以下 4 行代码来启动 ETW 会话，该会话将捕获 NWActivity 和 NWActovityVerbose 提供程序。 开始跟踪并使用一些应用程序 / 安装程序后，你应该有一个可以用 EventViewer 打开的 EventLog，你可以发现防御措施最终信任 ProcessHacker 之类的事情。 总结 就个人而言，我认为微软为提高操作系统的安全性而采取的措施是很好的，其最终目标是让用户更加安全。另一方面，我确实看到了 SAC 和 Windows 10 S 之间的一些相似之处。对于 SAC，当设置为强制时，限制由具有数字签名的应用程序设置，如果没有签名，则由防御措施云认为可信的应用程序进行设置。 第一种选择，即使你知道数字签名可以很好地验证应用程序，许多开源项目或自由开发者负担不起，不幸的是，这给开发者带来了一些限制。 第二个选项，即对 " 智能云安全服务 " 的查询，这也是我希望微软提供更多信息的地方，因为基本上应用程序能否运行的决定将完全取决于微软。