FreeBuf|任意文件移动导致的Windows提权攻击分析( 四 )

从任意文件写入到权限升级。在特权进程的上下文中，通过任意写入文件来获得代码执行的两种常用技术是：

DLL劫持：在一个特权进程将加载它的位置创建一个DLL(在应用程序的目录中，在System32、Windows或SYSTEM的%PATH%上的其他目录中) 。它需要一个方法来（重新）启动那个特权进程来加载这个DLL 。
覆盖：替换现有的二进制文件/脚本/配置文件/等，会给我们代码执行的权限。除了需要(重新)启动进程外，还需要文件写入操作来允许覆盖现有的文件(另外目标文件不应该被锁定) ，并且通常对特定的服务/应用程序要求的非常具体。

本文插图

至少有两种不太知名的技术。
C:\Windows/System32/Wow64Log.dll在32位特权进程中加载64位DLL 。这个DLL在默认情况下并不存在（Windows10 消费者版本上），它在所有32位进程中加载。然而，这个DLL不能直接通过Kernel32导入，所以如果想导入它必须只使用NTDLL APIs ，当然这只有在你有一个32位进程要注入的时候才有效(同样也是一种启动它的方法) 。 AFAIK这个技巧是由George Nicolaou发现的(我可以找到的第一个参考资料)和由Walied Assar记录的。使用 “Diagnostics Hub Standard Collector Service”：这项技术是由 - 你猜对了 - James Forshaw发现的，在GPZ的一篇博客文章中详细解释，并在example exploit中公布了作为案例研究的bug 。这篇文章非常值得一读，其要点是：DiagHub服务（以 “SYSTEM “的形式运行）可以从 “System32 “加载任何扩展名的文件作为DLL 。因此，如果你能在System32中创建一个带有有效载荷的文件test.log(当然文件内容必须是DLL) ，只需使用该技术在特权服务中加载该DLL 。然而，这种技术正在在即将到来的Windows 10版本中得到缓解。

本文插图

控制内容这些技术需要对创建的文件内容进行控制：如果你可以劫持创建一个文件到任意位置，但无法控制该文件中的内容，那么它的作用就非常有限。在我们的例子bug中，我们有一个很好的ACL ，由特权程序对生成的文件进行设置，但如果我们没有这个奢侈条件呢？
我们可以尝试针对其他操作。在我们的日志记录例子中，假设日志记录功能在日志达到一定大小的时候对文件进行移动，一个特权进程可能会移动或重命名日志文件（例如从abc.log到abc.old.log）。那么我们就可以利用符号链接来滥用这个操作。在重命名/移动操作中，用指向我们的有效载荷(sh.dll)的伪链接替换源文件。
将目标文件替换为我们要创建或替换的文件的伪链接(这里是target.dll)
所以，当重命名操作发生时的布局是这样的。

本文插图

当特权进程试图将移动或重命名为abc.old.log时，它实际上会将用户拥有的文件sh.dll移动/重命名为target.dll ，将我们的有效载荷放在我们想要他在的位置。可以控制的特权文件移动/重命名/复制的情况如下：
一个受控的移动或重命名给我们提供了任意的文件写的能力
如果能够控制复制的源地址和目的地址也是一样的
复制操作，我们控制源头，而不是目的地，给了我们一个任意的文件读取（如果目的地的位置是用户可读的）