信息安全专家David Wells发布了一种绕过Windows 10中的UAC用户帐户控制的方法
大家好！
在研究用户帐户控制（UAC）的一些新解决方法时，在撰写本文时，我发现了UAC的全新方法。 值得注意的是，Microsoft并不将UAC视为安全边界，但是，我们仍然报告Microsoft的各种错误，我想分享在此发现的漏洞的详细信息。 此方法已在Windows 10 Build 17134上成功测试。在深入了解我的发现之前，我将首先为您提供有关UAC服务如何工作的一些解释。
Uac底漆当属于Administrators组成员的用户要运行需要提升特权的应用程序时，UAC将显示一个相应的请求，而作为Administrators组成员的用户需要确认该操作，但是，对于Windows上的所有管理可执行文件，都不会发生此UAC请求。 有一些例外情况会“自动”提升可执行文件的特权，而不会引起UAC请求，从而绕开了UAC（这真让人惊讶！）。 特定的一组选定的受信任可执行文件将由系统进行其他安全检查，以确保这些文件实际上是可靠的，因此，信息攻击者通常不会滥用此功能。 此方法在以前的UAC旁路方法中使用过，并将成为我新的旁路方法的基础。 但是，为了使攻击成功，我们需要采取一些漏洞。 让我们看看如果希望我们的可执行文件“自动提升为特权”必须满足的要求。 为此，我将显示appinfo.dll反汇编库的一些图片（处理特权提升请求的AIS服务是UAC的主要组件之一）。
要求1：配置为自动提升特权的文件
当出现程序特权升级请求时，AIS服务（appinfo.dll）会进行RPC调用，并将目标可执行路径作为参数传递。 然后，该服务将映射文件的目标可执行文件内容以进行读取。 在可执行文件的清单中，尝试读取该值以获得键“ autoElevate”（如果存在）。
图1-读取可执行文件的清单以获取键值“ autoElevate”。
如果接收到该值且该值为True，则该文件将被视为“自动”提升特权的可执行文件，该文件将以特权提升运行，并且不会调用UAC服务对话框（前提是它满足以下提到的以下要求）。
图2 –调用“ bsearch”以检查“自动提升”的可执行文件列表中的可执行文件的名称
这些在系统中经过严格编程的文件已列入白名单：
'cttunesvr.exe'，'inetmgr.exe'，'migsetup.exe'，'mmc.exe'，'oobe.exe'，'pkgmgr.exe'，'provisionshare.exe'，'provisionstorage.exe'，'spinstall .exe'，'winsat.exe'
要求2：正确签名
假定在向UAC发送请求后“自动”增加特权的第二个条件是使用“ wintrust！”执行签名检查。 WTGetSignatureInfo”。
这意味着，攻击者将无法简单地创建自己的清单文件或可执行文件来自动“提升”特权并成功，因为攻击者的二进制文件很可能被错误地签名，并且最后一个要求（执行）也将失败。从受信任的目录。
要求3：从受信任目录执行
获得“自动”特权提升的最终要求是目标可执行文件位于“可信目录”中，例如，“ C：\ Windows \ System32”。 图3显示AIS对带有升级请求的路径执行此检查，在这种情况下，被认为“受信任”的路径之一是“ C：\ Windows \ System32”。
图3
本文的标题是“通过模仿受信任的目录来绕过用户帐户控制（UAC）”，因此您很可能可以轻松猜测接下来会发生什么。
UAC绕过如前面的“ UAC入门”部分所述，将对以下可执行文件执行自动特权（UAC绕过）：
- 配置为接收“自动”特权升级
- 正确签名
- 从受信任的目录运行（“ C：\ Windows \ System32”）
Appinfo.dll（AIS）使用RtlPrefixUnicodeString API检查可执行文件路径是否与“ C：\ Windows \ System32 \”匹配，以检查受信任的目录之一。 考虑到它与规范文件位置的比较，这是一个相当钢筋混凝土的测试。
因此，要绕过此检查，我创建了一个名为“ C：\ Windows \”的目录（注意“ Windows”之后的空格）。 当然，使用此操作您仍然无法通过RtlPrefixUnicodeString检查，并且我还将提到这是一个有点无效（或至少“不友好”）的目录名，因为Windows不允许在创建目录时在名称末尾添加空格（尝试）
但是，使用CreateDirectory API并添加“ \\？ \“对于我要创建的目录名称，我们可以绕过其中一些名称过滤规则，并直接向文件系统发送创建目录的请求。
这导致创建一个不方便的目录，该目录与真正的“ C：\ Windows \”一起愉快地共存于文件系统中（除非您尝试在Windows资源管理器中对其进行处理）。
现在我们有了“ C：\ Windows \”目录，我们可以在其中创建“ System32”目录，并从真实目录“ C：”中复制一个已签名的可执行文件（系统允许该文件“自动”提升特权）： \ Windows \ System32“。
为此，我复制了“ winSAT.exe”（Windows可执行文件白名单中的文件之一，具有系统允许的“自动”特权提升）。
当我们尝试从新目录“ C：\ Windows \ System32 \ winSAT.exe”运行此文件时，它将在执行受信任的目录检查之前，通过appinfo.dll中的以下API（请参见图6）。 这很重要，也是解决此问题的原因的基础。
图6
当将此带有空格的不便路径发送到AIS以请求特权升级时，该路径将传递到GetLongPathNameW，后者将其转换回“ C：\ Windows \ System32 \ winSAT.exe”（已删除空间）。
太好了！
现在，这是其余部分通过有效目录检查（使用RtlPrefixUnicodeString）通过的行。
我的解决方案的优点在于，在检查了受信任的目录之后，将执行此转换的路径，然后将其释放，然后使用可执行目录的原始名称（带有额外的空间）执行其余检查（以及特权升级的最终请求）。
这使我可以进行所有其他检查，并使appinfo.dll接受我的winSAT.exe副本具有“自动”特权提升（因为它已正确签名并添加到“自动”特权提升的白名单中）。
为了真正使用恶意代码，我只是在当前目录“ C：\ Windows \ System32 \”中复制了伪造的WINMM.dll（导入的winSAT.exe），以欺骗本地dll。 完整的概念可以在下图中看到。
图7
→
链接到Github