使用Process Monitor在Windows中查找特权升级漏洞

2021-06-10 23:12:43

跳到元数据结束转到元数据的开始,这篇文章将解释如何在Windows上找到任何似乎无法寻找的Windows上的特权升级Vuls,因为它' S一直很容易找到一堆。解释如何找到它们,我' LL介绍一些可以以不同方式减轻问题的一些防御。但是,我喜欢看到改变是为了开发人员在我描述的方式开始寻找这些VULS,以便他们停止首先引入它们。

回到我们第一次发布CERT BFF时,将概念验证泄漏的常用流程用于内存损坏漏洞的常规过程是:

了解哪些字节可用于存储shellcode,使用BFF字符串最小化。

必要时使用ROP来修改程序流程,以便它执行ShellCode。

从START到POC与CERT BFF开始往往相对简单。随着时间的推移,筹集了用于利用内存损坏漏洞的酒吧。这可能归因于多年来发生的两件事:

在软件和他们运行的平台上增加了利用缓解的存在。

我最近曾在漏洞发现技术上,提醒我早期的BFF天。两个都是为了找到漏洞的容易以及如何利用它们是多么容易。事实上,这个概念如此琐碎,我对发现漏洞的成功感到惊讶。就像直接与BFF直接从模糊到模糊的想法,因为时间继续下去,因为时间越来越少,我喜欢那里的低悬垂的水果,可以用这种技术很容易地发现。

在这篇文章中,我将分享我的一些发现以及过滤器本身,用于查找使用Sysinternals进程监视器(Procmon)的特权升级漏洞。

当程序安装在Windows平台上时,它的某些组件可能会使用权限运行,无论该用户当前登录到系统。这些特权组件通常采取两种形式:

我们如何在Windows系统上实现特权升级?任何时候特权进程与未经特权用户可能能够影响的资源交互,这会使特权升级漏洞的可能性打开。

检查可能能够受非特权用户影响的特权进程的最简单方法是使用基于以下属性显示操作的进程监视器过滤器:

检查1和2可以在过程监视器中进行琐碎。检查3有点复杂,如果我们将工具限制为严格,可以使用流程监视器过滤器完成操作,可能会导致某些误报。但是,我创造了一个过滤器,似乎做了一个非常好的工作,使特权升级脆弱性很明显。

Let&#39

即使在我们的VM中几乎没有安装软件,我们也可以看到可疑的东西:C:\ Program%20files \

Windows用户可能熟悉路径C:\ Program Files \,但是' s为%20?为什么可能发生这种文件操作?我们' ll涵盖下面的部分的原因。

有许多错误,即开发人员可能会使这可以导致能够受到非特权用户的特权进程。我在Windows应用程序中对简单的特权升级漏洞感到注意到的错误分为两个主要类别:

在某些情况下,在执行程序期间访问意外路径。也就是说,如果他们意识到被访问的路径,开发人员可能会感到惊讶。这些意外的路径访问可能是由许多原因引起的:

正如我们在上面的屏幕截图中注意到,VMware Tools过程vgauthservice.exe尝试访问路径c:\ program%20files \ vmware \ vmware%20tools \ vmware%20vgauth \ schemas \ xmldsig-core-schema.xsd。这可能怎么发生?如果包含空格的路径是编码的HTML,那么这些空间将被替换为%20。

这种转变的后果是什么?这条新路径最重要的方面是,而不是作为C:\ Program Files \的子目录,默认情况下具有适当的ACL,而此请求的路径现在开始查看根目录。 Windows系统上的未经特权用户可以从系统根目录中创建子目录。这将是一个反复出现的主题,所以请记住这一点。

通过选择文件访问,然后按Ctrl-k来获取呼叫堆栈,我们可以在流程资源管理器中深入挖掘

在这里,我们可以看到文件访问由vgauthservice.exe + 0x110d9触发,沿着呼叫xmlloadexternalentity()。

将所有部分放在这里,我们有一个特权进程,试图加载不存在的文件,因为路径是HTML编码的。由于一个未经特权的用户可以创建此路径,因此它现在变成了一个非特权用户可以影响特权进程的情况。在这种特殊情况下,后果仅是XML外部实体(XXE)漏洞。但我们' re也只是被加热了。

如果应用程序在Windows计算机上使用POSIX样式路径,则此路径将归一化为Windows样式路径。例如,如果Windows应用程序尝试访问/ usr / local /目录,则路径将被解释为c:\ usr \ local \。如上所述,这是一个路径,即未特权的用户可以在Windows上创建。

以下是安装完全修补的安全产品的系统的流程监视器日志:

使用公知的技术来实现通过openssl.cnf实现代码执行的技术,我们现在可以通过运行Calc.exe与有限用户帐户的系统权限一起演示代码执行:

在某些情况下,开发人员可能已经做错了,除了使用可能从可能受到未经特权的Windows用户影响的位置的库中遇到加载的库,更为错误。例如,这里'' s一个进程监视器日志,该应用程序尝试访问路径c:\ cmu \ bin \ sasl2:

如果我们查看调用堆栈,我们可以看到此访问可能是libsasl.dll库触发的:

并确保如果我们查看libsasl的代码,我们可以看到对路径c:\ cmu \ bin \ sasl2的硬编码引用。

作为一个未经特权的用户,我们可以创建目录并将我们想要的任何代码放在那里。我们再一次,使用System权限执行Calc.exe。来自无特势率的用户帐户。

有时程序可能包含对开发人员和#39; S系统上只存在的路径的引用。只要软件在没有这样一个目录的系统上正常运行,那么除非有人在寻找,否则可能无法识别此属性。例如,此软件在C:\ QT \目录中查找插件子目录:

我' ll跳过一些步骤,以便简洁起见,但经过一点调查,我们看到我们可以通过在相应目录中放置特殊库来实现代码执行:

进一步进入Qt开发平台,这种类型的漏洞是一个已知的问题。该漏洞在5年前修补,但它从未收到过CVE。如果在介绍此修补程序之前使用Qt版本构建或未使用WindeployQt修补存储在Qt5core.dll中的Qt_prfxpath值,则软件可能很容易受到Qt版本的特权升级。

由于简单的事实,可以利用应用程序访问的大多数情况下的意外路径:未经特权用户可以从Windows系统根目录中创建子目录。发现和利用无法正确设置ACL的软件需要更多调查。

与Windows软件相关的大多数ACL问题与一个概念有关:从C:\ Program Files \或C:\ Program Files(x86)的子目录中执行的软件默认情况下通过继承来保护ACL。例如,考虑我将软件安装到C:\ Program Files \ WD \的情况。未经特权的用户无法修改WD子目录的内容,因为C:\ Program Files \的父目录无法写入未经特权的进程,而WD子目录默认将继承其父父母权限。

可以将设计的ProgramData目录写入,而无需提高。因此,默认情况下,在ProgramData目录中创建的任何子目录都将被非特权用户可写入。根据应用程序如何使用其ProgramData子目录,如果未明确设置子目录的ACL,则可能是特权升级。

在这里,我们有一个流行的应用程序,它具有从C:\ programdata \目录运行的计划更新组件:

这是DLL劫持的直接潜在案例,这是由于软件运行的目录中的LAX ACL可能成为可能。让' s植物在那里制作一个制作的msi.dll,看看我们可以完成什么:

我们的calc.exe有关系统权限。这些问题看起来有点普遍。而且很容易剥削。

它值得注意的是,DLL劫持ISN' T我们唯一的特权升级选择。特权进程使用的任何用户可写文件介绍了引入权限升级漏洞的可能性。例如,这里' s一种受欢迎的程序,检查用户可创建的文本文件,以指导其特权自动更新机制。正如我们在这里看到的那样,构造的文本文件的存在可能导致任意命令执行。在我们的情况下,我们有它启动Calc.exe:

将应用程序默认为OFF系统root的目录置于默认情况下的安装程序必须设置适当的ACL以保持安全。例如,Python 2.7默认安装到C:\ Python27 \

此目录的默认ACL允许未经特权的用户修改此目录的内容。我们可以用这个问题做些什么?我们可以尝试标准DLL劫持技术:

但我们甚至不需要那个聪明。我们可以简单地将C:\ Python27 \目录中的任何文件替换为非特权用户:

由于C:\ Program Files \的安全ACL的继承,许多安装人员是安全的。但是,任何允许用户选择自己的安装目录的安装程序都必须在目标位置明确设置ACL。遗憾的是,在我的测试中,我发现安装人员明确设置ACL是非常罕见的。让'请查看Microsoft SQL Server 2019安装程序,例如:

Microsoft SQL Server 2019以及允许您选择安装它的位置的任何Windows应用程序,可能只需基于它安装到的目录即可易受权限升级。

以上概述的许多攻击的最简单防御是删除从系统根目录中创建文件夹的权限:

如果软件安装到C:\ Program Files \或C:\ Program Files(x86)之外的任何位置(x86)\,则依靠安装程序,显式设置ACL以确保安全。只需将软件安装到推荐的程序位置即可避免使用这种信仰的飞跃。

您可以使用上述过程监视器过滤器和技术测试您自己的特权升级漏洞的平台。对于确定为不安全的任何文件位置,您可以手动锁定这些目录,以便未经特权的用户无法修改这些位置。对于您发现的任何漏洞,我们建议您与受影响的供应商联系以通知他们漏洞,以便它们可以为每个人修复。在供应商通信是不生产的情况下,证书/ CC可能能够提供援助。