花式注入Windows explorer -HQY 一个和谐有爱的空间

05

2024
07
11:46:36

花式注入Windows explorer

还记得粉碎攻击吗？

我认为创造Gapz的目的是为了绕过用户界面特权隔离（UIPI）。接下来我要介绍一个更简单的技巧——它甚至不需要任何ROP。

有一类窗口始终存在于使用窗口子类的系统上。窗口子类化只是挂钩的别称之一，因为在子类化过程中，旧窗口过程被保留，而新的窗口过程被分配给窗口。

然后一个新的窗口将拦截所有消息，完成它的任务后再然后调用旧的窗口。

“本机”窗口子类使用SetWindowSubclass API完成。

当一个窗口被子类化时，会有一个新属性储存在其内部结构中，并根据comctl32.dll的版本命名：

UxSubclassInfo - 版本6.x
CC32SubclassInfo - 版本5.x

查看Windows资源管理器子窗口的属性，我们可以发现它们中有很多都使用了这个特定的子类属性：

几乎所有利用标准窗口的程序都有该属性，包括OllyDbg：

当调用SetWindowSubclass时，它使用SetProp API将这两个属性（UxSubclassInfo或CC32SubclassInfo）中的一个指向内存中的某个区域，其中旧的函数指针会被存储在内存中。

当调用新的消息例程时，它将调用给定窗口的GetProp API，一旦被检索，它被执行。

考虑到上的破灭性攻击，我们不能再使用SetWindowLong或SetClassLong（或它们较新的SetWindowLongPtr和SetClassLongPtr替代）来设置属于其他进程（通过GWL_WNDPROC或GCL_WNDPROC）窗口的窗口过程地址。

但是，SetProp功能不受此限制的影响。当涉及到相同完整性级别较低的过程时，Microsoft文档提示：

SetProp受限于用户界面特权隔离（UIPI）。进程只能在属于较小或相同完整性级别的进程窗口上调用此函数。当UIPI阻止属性更改时，GetLastError将返回5。

所以，如果我们在同一个会话中讨论其他用户应用程序，我们可以自由修改他们的窗口属性！

现在标题已经很明显了：

我们可以自由修改属于另一个进程的窗口属性。
我们还知道一些属性指向内存区域，存储子类窗口过程的旧地址。
地址点的例程将处于某个阶段。

我们需要的是一个使用了UxSubclassInfo / CC32SubclassInfo属性的结构。这实际上很简单，在检查SetProp在这些子类窗口中的行为之后，你很快就会发现，旧的程序储存在距离开头偏移量为0x18的区域内（结构有点复杂，因为它可能包含多个回调，但第一个在0x18）。

因此，将一个小的缓冲区注入到目标进程中，确保预期的结构被正确地填充并且指向有效负载，然后改变相应的窗口属性将确保下一次窗口接收到消息时执行有效载荷（这个可以通过发送消息来强制执行）。

在我发现它之后，我写了一个简陋的POC，枚举所有的窗口与上述属性（有很多他们几乎每个GUI应用程序都受到影响）。

对于发现的每个子类属性，我将其更改为随机值 ——因此Windows资源管理器，Total Commander，Process Hacker，Ollydbg和其他一些应用程序立即崩溃。然后，我创建了一个非常小的shellcode，在桌面窗口上显示一个消息框，并在Windows 10（正常帐户下）进行测试。

在第一个随机目标（Total Commander）中调用shellcode的时刻：

当然，它也适用于Windows资源管理器：

如果我们检查Process Explorer，就可以发现该窗口属于explorer.exe：

在Windows XP系统上测试它，并向Windows资源管理器中注入shell代码，显示出每个窗口暴露出子类化属性(就特殊效果而言，XP总是胜过Windows 10——在第一个消息框出现之后，XP系统会冻结;如果您想知道为什么它会冻结——这是因为我的shell代码很简单，而且一旦执行，它就会破坏运行中的应用程序）：