详解Bypass UAC过程中踩过的坑（第一部分）

本文讲的是 详解Bypass UAC过程中踩过的坑（第一部分）， 我目前正在尝试对Chrome沙盒进行一些改进。而作为其中的一部分，我现在正在对我的沙盒攻击Surface 分析工具进行更新，因为我想衡量我对Chrome做的事情是否具有实际的安全性。但事实上当我在进行这一切时，我一直躲不开绕过UAC的麻烦，这就导致进程出现了问题。所以为了顺便演示下我以前在UAC绕过的博文中所讲的，我决定将这一切再来一次。当我完成这一切的时候，我将使用最新版本的NtObjectManager  Powershell模块来显示一些演示文稿。

在我开始之前，我必须解决/讨论关于UAC绕过的“fileless”标记。我以前的博客文章说这是一个fileless绕过，但是我仍然需要写入注册表（由文件支持），当然还有一些可执行文件仍然需要运行（这在某些时候被页面支持）文件）等。基本上所有的fileless绕过都意味着它将不依赖于旧的IFileOperation技巧来劫持一个DLL。但这并不意味着某个文件不会在某个地方停在磁盘上，我想这更像是DFIR这样的术语。

一个奇怪的设计决策

当微软正在设计UAC时，可能就有窥探者利用不同的攻击向导来减少普通用户升级到管理员的机会。例如，使用UIPI减轻了Shatter攻击（和一般UI驱动）。通过使管理员进程仅使用HKLM进行COM注册（不是特别成功地添加）来缓解COM DLL种植。使用强制性完整性标签来减轻用户资源的滥用，以防止从低到高的写访问。

也许UAC有一个超级安全版UAC开发，但麻烦的是它可能已经不可用了。所以无疑其中许多安全观念放松了。特别令人感兴趣的是，非管理员用户可以在同一台桌面中查询有关管理员进程的一些不可否认的有限的进程信息。这可能会导致我们将看到非常令人惊讶的影响。

那么普通应用程序获得多少访问权限？通过运行以下PS脚本作为正常的分割令牌管理用户，我们可以很容易地回答。

这应该会导致MMC升高，并将以下打印到PS控制台：

所以它显示我们有3个访问权限，Terminate，QueryLimitedInformation 和Synchronize。这样做是有道理的，毕竟如果你无法在桌面上杀死进程，或者等待他们完成，或者获得他们的名字，那么这将是一种痛苦。正是在这一点上，第一个UAC设计决策发挥作用，存在一个正常的QueryInformation进程访问权限，但是使用该访问权限存在一个问题，而这违反了强制性标签策略（我将引用它）作为IL政策从现在开始）以及它如何在流程上实施。IL策略 的目的是指定哪个通用访问权限，读取，写入和执行低IL用户可以获取资源。这是允许的最大访问权限，IL策略本身不会授予访问权限。用户仍然需要在DACL中获得适当的访问权限。因此，例如，如果策略允许较低的IL进程获取读取和执行但不写入（这是大多数资源的默认值），那么如果用户要求写访问权限，内核访问检查将在甚至查看之前返回访问被拒绝在DACL。所以我们来看一下进程对象的IL策略和通用访问权限：

这样将会导致以下输出：

进程的默认策略是不允许较低的IL用户读或写，所以他们可以拥有的是执行访问，我们可以看到，我们拥有这一点。但是请注意，QueryInformation是一个读访问权限，将被默认的IL策略阻止。因此，我们无法给予读取访问权限，因为我们不希望让读者轻松读取特定进程的内存，所以让我们创建一个新的访问权限，QueryLimitedInformation将被分配给执行和只是将一些信息查询转移到新的权限“。

在Vista及以上版本上也值得一提的是，您无法获取QueryInformation访问权限，也不会隐式地拥有QueryLimitedInformation，所以MS认为足够的话可以欺骗而不是别的东西。（为读者思想：为什么我们不能获得ReadControl访问权限？） 当然，您仍然需要能够在DACL中访问这些访问权限，特权进程如何才能实现这些访问？进程的默认安全性来自访问令牌内的默认DACL，用作新进程的主令牌，我们在普通用户PS控制台和升级的PS控制台中使用以下脚本转储默认DACL：

普通用户的输出如下：

管理员的输出如下：

一旦这个重要的点被突出显示，而管理DACL却不允许正常的用户访问，这个好奇的LogonSessionId用户就可以读取和执行访问。因此，这似乎可能是给我们执行访问权限（因为读取将被IL策略过滤）。我们可以通过转储正常用户在其令牌中具有的组来证明这一点：

是的，我们有该组，并且启用了。而这样显然就解决了为什么我们可以得到执行访问的谜底。这是一个明确的设计决定，微软是希望能够使得这样一个普通用户可以获得一定程度的访问升级过程。当然在这一点上，你还会想什么呢？你可以从一个进程中读取一些基本信息，怎么读出是个问题？详见这个系列的第2部分。

原文发布时间为：2017年6月12日

本文作者：Change

本文来自云栖社区合作伙伴嘶吼，了解相关信息可以关注嘶吼网站。

原文链接