利用USO服务将特权文件写入武器化 _利用USO服务

James Forshaw发现的DiagHub DLL loading技术已经非常有名了。每当你在windows或一些第三方软件中发现SYSTEM权限的任意文件写漏洞时，你就可以用这一招来造成任意代码执行，而且不用重启。不幸的是这种方法在Windows 10 build 1903年被微软禁止。Andrea Pierini在Twitter上简单地提到了这一点。在这里，我想和大家分享一下我在最新版本的Windows上寻找DLL劫持弱点时发现的另一种加载dll的方法。

前言在本文的开头，我想澄清一下：
这不算是一个漏洞。正如我们所看到的，为了能够使用这个技巧，必须先将一个专门制作的DLL植入C:WindowsSystem32文件夹，当然只有 “SYSTEM” 权限的用户才能做到这一点。

写在开始作为出发点，我决定寻找一些简单的例子，例如在以NT AUTHORITY/System运行的服务中的DLL劫持。我的想法是监控那些可以被普通用户启动或至少是 “影响 “的服务。为此，我做了一个非常简单的PowerShell脚本，每秒钟检查一个服务是否被启动或停止。

文章插图

在Windows操作系统的后台，运行Process Monitor来记录文件系统操作。我简单地配置了一个过滤器，只显示涉及*.dll文件的操作，如果找不到的话就返回NAME NOT FOUND错误代码。然后，我试着在没有管理员权限的情况下，一次一次地启动所有能启动的服务。不幸的是，我没有用这个方法发现任何东西。不过我发现了以下内容。
当 “Process Monitor “在后台运行时，它捕捉到一些定期打开 “windowscoredeviceinfo.dll “文件的操作。频率不一，可能每小时发生一次，也可能每30分钟发生一次。事件的属性显示了该进程的命令行。通过查看事件的属性能够发现这个操作是由命令行”C:WINDOWS/System32/svchost.exe -k utcsvc -p”造成的。
知道了这一点，就可以很容易地通过以下PowerShell命令找到相应的服务，例如。在这种情况下，可以用DiagTrack命令。

注：我也可以使用进程的PID ，例如在任务管理器中查找它。这种方法的缺点是，你不知道它什么时候启动，在你检查的时候，进程可能并不在运行。

我们的第一个目标“Process Monitor “中的事件属性显示了一些关于DLL如何被加载的信息。Stack选项卡显示了导致这次操作的调用列表。在这里，我们可以看到，初始调用是从diagtrack.dll进行的。DiagTrack服务加载了FlightSettings.dll文件，它又使用了dcntel.dll中的GetCensusRegistryLocation()方法，最后，使用标准的LoadLibraryEx()WinApi调用加载了windowscoredeviceinfo.dll 。

文章插图

为了确定我的方向是正确的，我在IDA中打开最后一个DLL ，并查找windowscoredeviceinfo.dll的出现。Strings标签页中能够清楚的找到这个dll的名字。

注意：你必须配置视图以包含unicode字符串，这不是IDA的默认设置…… 。

文章插图

然后，我们可以直接到它在.rdata部分的位置，寻找Xrefs 。在这种情况下，只有一个。这个字符串确实是在QueryWCOSDeviceInformation()方法中使用的。好吧，说明我们的路线是对的!

文章插图

IDA生成的伪代码非常清晰。我们发现前面看到的Process Monitor的LoadLibraryEx("windowscoredeviceinfo.dll")调用。然后，如果库被成功加载，就会进行下面的调用。GetProcAddress("QueryDeviceInformation") ，也就是说这个函数应该是windowscoredeviceinfo.dll的导出函数。