渗透测试技术之另类Windows提权

前言

如果你获得了一台机器的低权限Meterpreter会话，并且当你尝试了一些常用方法，仍然提权失败时，是不是就意味着没法提权呢？不必着急，你仍然可以试试很多其它的技术。下面我们就来列举出几种提权方法。

一、Windows服务路径没加双引号

通常，如果一个服务的可执行文件的路径没有用双引号封闭，并且包含空格，那么这个服务就是有漏洞的。

如果你想验证这个漏洞，你可以在你的试验环境中增加一个有漏洞的服务，自己测试一下，下面咱们添加名为“Vulnerable Service”的服务，可执行文件放在“C:Program Files (x86)Program FolderA Subfolder”目录中。

为了识别出没有加双引号的服务，你可以在Windows命令行中运行以下命令：

运行上面的命令后，所有没有加双引号的服务将会被列出来：

如果你从注册表中查看注册的服务，你会看到“ImagePath”的值是：

安全的值应该是：

当Windows尝试启动这个服务时，它会按照下面的顺序寻找可执行文件，并运行第一个找到的：

这个漏洞是由系统中的“CreateProcess”函数引起的，更多信息请看这里。

如果我们能成功的把恶意EXE程序放在这些路径下，当服务重新启动时，Windows就会以SYSTEM权限运行我们的EXE。当然，我们需要有进入其中一个目录的权限。

为了检查一个目录的权限，我们可以使用Windows内建的一个工具，icals，下面我们用这个工具检查“C:Program Files (x86)Program Folder”目录的权限。

好幸运呐，你可以看到，“Everyone”用户对这个文件有完全控制权。

“F”代表完全控制。“CI”代表从属容器将继承访问控制项。“OI”代表从属文件将继承访问控制项。

这意味着我们可以随意将文件写入这个文件夹。

从现在开始，你要做什么取决于你的想象力。我比较倾向于生成一个反弹shell载荷，并用SYSTEM权限运行。

这个工作可以使用msfvenom来完成：

然后将生成的载荷放到“C:Program Files (x86)Program Folder”文件夹：

然后，在下一步启动这个服务时，A.exe就会以SYSTEM权限运行，下面我们试着停止，并重启这个服务：

访问被拒绝了，因为我们没有停止或启动服务的权限。不过，这不是一个大问题，我们可以等，直到有人重启机器，或者我们自己用“shutdown”命令重启：

正如你看到的，低权限的会话中断了，说明命令执行了。

我们的机器正在重启，现在，我们的载荷将会以SYSTEM权限运行，我们需要立即在本地建立监听：

现在，我们获得了一个SYSTEM权限的meterpreter shell。

但是，我们新得到的会话很快就中断了，为什么呢？

不必担心，当一个服务在Windows系统中启动后，它必须和服务控制管理器通信。如果没有通信，服务控制管理器会认为出现了错误，并会终止这个进程。

我们所有需要做的就是在终止载荷进程之前，将它迁移到其它进程，你也可以使用自动迁移。

顺便说一句，有一个检查和利用这个漏洞的Metasploit模块：exploit/windows/local/trusted_service_path。

在运行这个模块前，需要将它和一个已经存在的meterpreter会话(实际上就是你的低权限会话)关联起来，如下图：

具体过程可以看这里。

二、Windows服务带有易受攻击的权限

大家知道，Windows服务是以SYSTEM权限运行的。因此，它们的文件夹、文件和注册的键值，必须受到强访问控制保护。在某些情况下，我们能遇到没有受到有效保护的服务。

不安全的注册表权限

在Windows中，和Windows服务有关的信息存储在“HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices”注册表项中，根据我们上面的测试实例，我们可以找到“HKEY_LOCAL_MACHINESYSTEMControlSet001ServicesVulnerable Service”键值。

当然，我们建的“Vulnerable Service”服务存在漏洞。

但问题是，我们怎样才能从命令行检查这些权限？让我们从头开始演示。

你已经得到了一个低权限的Meterpreter会话，并且你想检查一个服务的权限。

你可以使用SubInACL工具去检查注册表项的权限。你可以从这里下载它，但是你要意识到这个程序是一个msi文件。如果目标机器上的AlwaysInstallElevated策略设置没有启用，那么你没法以低权限安装msi文件，当然，您可能也不想在目标机器上安装新的软件。

我建议你在一个虚拟机中安装这个软件，并在它的安装目录中找到“subinacl.exe”文件。它能顺利工作，并且无需安装msi文件。然后将SubInACL上传到目标机器。

现在SubInACL工具可以用了，下面我们来检查“HKEY_LOCAL_MACHINESYSTEMControlSet001ServicesVulnerable Service”的权限。

请看第22、23行，“Everyone”在这个注册表项上有完全的控制权。意味着我们可以通过编辑ImagePath的值，更改该服务的可执行文件路径。这是一个巨大的安全漏洞。

我们生成一个反弹shell载荷，并将它上传到目标机器中，然后把服务的可执行文件路径修改为反弹shell载荷的路径。

首先，生成一个载荷：

上传到目标机器中：

将ImagePath的值改成我们载荷的路径：

在下一次启动该服务时，payload.exe将会以SYSTEM权限运行。但是请记住，我们必须重新启动电脑才能做到这一点。

如上图，我们的目标机正在重启，请将监听进程准备好，我们的载荷将会以SYSTEM权限运行。

但是不是忘了，我们利用服务的方式和前面讲的方式(服务路径没加双引号)原理上实际是一样的,返回的高权限很快会断掉(可以使用自动迁移，如AutoRunScript)。

不安全的服务权限

这和前面讲的不安全的注册表权限很相似，只是这次我们没有修改ImagePath的值，我们直接修改了服务的属性。

为了检查哪个服务有易受攻击的权限，我们可以使用AccessChk工具，它来源于SysInternals Suite工具集。

将AccessChk工具上传到目标机器中：

为了检查易受攻击的服务，我们运行以下命令：

如图，通过上面的命令，所有“testuser”用户可以修改的服务都被列出来了。SERVICE_ALL_ACCESS的意思是我们对“Vulnerable Service”的属性拥有完全控制权。

让我们看一下“Vulnerable Service”服务的属性：

BINARY_PATH_NAME参数指向了该服务的可执行程序(Executable.exe)路径。如果我们将这个值修改成任何命令，那意味着这个命令在该服务下一次启动时，将会以SYSTEM权限运行。如果我们愿意，我们可以添加一个本地管理员。

首先要做的是添加一个用户：

在修改了binpath的值后，用“sc stop”和“sc start”命令重启服务：

当你尝试启动服务时，它会返回一个错误。这一点我们之前已经讨论过了，在Windows系统中，当一个服务在Windows系统中启动后，它必须和服务控制管理器通信。如果没有通信，服务控制管理器会认为出现了错误，并会终止这个进程。上面的“net user”肯定是无法和服务管理器通信的，但是不用担心，我们的命令已经以SYSTEM权限运行了，并且成功添加了一个用户。

现在我们以同样的方式，再将刚才添加的用户，添加到本地管理员组(需要再次停止服务，不过此时服务不在运行状态，因为刚才发生了错误，进程被终止了)。

下面可以享受你的新本地管理帐户了！

同样，你也可以将一个反弹shell载荷上传到目标机器中，并将binpath的值改成载荷的路径。

只是这次不用再手动使用这个方法了，有现成的metasploit模块：exploit/windows/local/service_permissions。

你需要将这个模块和一个已经存在的Meterpreter会话(已经得到的低权限会话)关联起来：

三、不安全的文件/文件夹权限

和前面我们讲过的“服务路径没加双引号”很相似，“服务路径没加双引号”利用了“CreateProcess”函数的弱点，结合了文件夹权限与服务可执行文件路径。但是在这部分，我们转换思路，试着直接替换可执行文件本身。

例如，如果对测试环境中“Vulnerable Service”服务的可执行文件路径的权限进行检查，我们可以看到它没有被保护好：

仅仅需要将“Executable.exe”文件替换成一个反弹shell载荷，并且当服务重启时，会给我们返回一个SYSTEM权限的meterpreter 会话。

四、AlwaysInstallElevated设置

AlwaysInstallElevated是一个策略设置，当在系统中使用Windows Installer安装任何程序时，该参数允许非特权用户以system权限运行MSI文件。如果启用此策略设置，会将权限扩展到所有程序。

实际上，启用这个值，就相当于给非特权用户授予了管理员权限。但是有一点我理解不了，有时候系统管理员会启用这个设置：

你需要检查下面这两个注册表键值，来了解这个策略是否被启用：

如果你获得了一个低权限的Meterpreter会话，reg内建命令可以帮你检查这些值：

如果，你得到了一个错误，就像是“ERROR: The system was unable to find the specified registry key or value.”，它的意思是这个注册表值没有被创建，也就是说这个策略没有启用。但是如果你看到了下面的输出结果，那意味着该策略设置是启用的，你可以利用它。

正如我前面说过的，在这种情况下，Windows Installer会使用高权限来安装任何程序。因此，我们需要生成一个恶意的“.msi”文件，并运行它。Msfvenom工具可以完成这个工作。

如果你想生成一个“.msi”文件，并向目标机器中添加一个本地管理帐户，你可以使用“windows/adduser”作为载荷:

但是在这个例子中，我要生成一个反弹shell载荷(Payload.exe)，并使用一个msi文件执行这个载荷，首先，产生Payload.exe：

然后使用“windows/exec”生成一个malicious.msi。请确定你填写了Payload.exe的正确路径：

然后我们将这两个可执行文件上传到目标机器中。

在执行“.msi”文件前，在另一个窗口中开启一个新的监听，等待高权限的shell连接：

现在，我们准备执行！

“/quiet”表示安静模式，无用户交互。“/qn”表示没有GUI。“/i”表示安装或配置产品。

如下图，成功返回：

除了手动使用这个技术，你也可以使用现成的metasploit模块：exploit/windows/local/always_install_elevated。

该模块SESSION参数需要设置为一个已经存在的Meterpreter会话：

五、DLL劫持

假如上面的方法都没成功，不要放弃。我们开始研究一下正在运行的进程。

如上图，如果我们的shell是以低权限运行的，我们不会看到进程的详细信息(运行在高权限上的进程)，如用户、路径、结构。但是我们可以了解到有哪些进程运行在高权限上。如果其中的一个进程存在漏洞，我们就可以利用它来提升我们的权限。

在对进程研究过程中，Vulnerable.exe进程引起了我的注意，让我们来找一找它的位置，并下载它：

当我对它进行检查后，我意识到它试图加载一个名为“hijackable.dll”的DLL。

在这个例子中，Vulnerable.exe进程存在DLL劫持漏洞。当然，实际上这个Vulnerable.exe只是一段简单的代码，在没有做检查的情况下加载了一个DLL：

回到我们的话题，什么是DLL劫持呢？微软的一篇文章是这样解释的：

当应用程序动态加载动态链接库而不指定完整的路径名时，Windows会尝试通过一个特定的目录顺序，来搜索定位DLL，在这里有目录的搜索顺序。如果攻击者得到了其中一个目录的控制权限，他可以用一个恶意软件来替代DLL。这种方法有时被称为DLL预加载攻击或二进制移植攻击。如果系统在搜索到受感染的目录前，没有找到合法的DLL，那它将会加载恶意的DLL。如果这个应用程序是以管理员权限运行的，那么攻击者就可以成功的得到本地权限提升。

当一个进程尝试加载DLL时，系统会按以下顺序搜索目录：

1.应用程序加载的目录。

2.系统目录。

3.16比特系统目录。

4.Windows目录。

5.当前目录。

6.PATH 环境变量中列出的目录。

因此，为利用这个漏洞，我们按以下步骤：

1.检查进程加载的DLL是否存在于磁盘中。

2.如果不存在，将恶意DLL放在我刚才提到的其中一个目录中。当进程执行时，它可能会找到该DLL，并加载DLL。

3.如果DLL在上述其中一个目录中存在，那么将恶意DLL放在比当前目录的搜索优先级更高的目录中，例如，如果源DLL在Windows目录中，并且我们获得了应用程序加载目录的权限时，我们可以将恶意DLL放到应用程序加载目录，当应用程序加载DLL时，它会首先加载该目录的DLL。最终，我们的恶意代码会以高权限执行。

下面，让我们在目标机器中搜索一下hijackable.dll的位置：

貌似在机器上不存在，但是我们实际上无法确定这一点，也许它被放在了一个我们没有权限查看的目录中，不要忘了，我们目前的权限仍然是低权限。

下一步是检查可能的弱权限文件夹。我通常检查一个软件是否被安装在根目录中，如Python。因为如果一个文件夹被创建在根目录中，通常对于所有认证的用户(authenticated users:Windows系统中所有使用用户名、密码登录并通过身份验证的账户，不包括来宾账户Guest)，默认情况下它是可写的。像Python、Ruby、Perl等等。通常会添加到PATH环境变量中。

记着，Windows会检查PATH环境变量中的目录。