使用漏洞组合拳拿下服务器SYSTEM

    话说几日前，渗透人员说想要提权一台服务器。背景是在内网有一台很重要的服务器需要提权。目标为server 2008 R2 x64，服务器上部署的应用类似于堡垒机（讲真对堡垒机概念一直很模糊），可以通过一个内网部署的网页直接点击应用图标直接登录目标服务器的RDP而启动应用，但账号密码也是那应该自己输入的，我们并不知道密码，whoami看了一下账号为:appzhangsan.xxxx，这个zhangsan是个名字的拼音，xxxx是每次登录都不一样的一个数字，整体看起来格式符合域的情形，但后续操作怎么看都不像真的域内。跟渗透大佬对了下，他要求如下：

    1 不能影响服务器正常工作，不能重启，不可接受蓝屏。这个要求限制了我们不能使用操作系统内核漏洞，内存损坏类漏洞都多多少少涉及pool fengshui，比如UAF、double free，占位再精妙也总有意外的概率，而这个服务器很重要，直接有很多用户正在使用。意外不可接受。

    2 在服务器上运行几个命令简单收集了一下信息，显示如下（截图来自命令输出到的txt文档）：

    上图中用户的token只有两个权限，没有SeImpersonatePrivilege权限--不是network service，这导致基于令牌模拟的漏洞均不可用，比如烂蔬菜家族。

    3 操作系统为windows server 2008 R2，这意味着漏洞日期不能太新，但也不能太老。最近一两年的漏洞是针对windows server 2019系列的，跟目标上很多情况都不一样了。但好在适用于2008R2的漏洞也不少。

    基于以上综合考虑，基于条件竞争（reparse+symblic）的逻辑漏洞成为我们的最优也是必然选择。

    现在开始了正式的提权过程。既然方向明确了，脑子里搜索一遍经历的漏洞。我们知道，这种类型的漏洞很多都是一个功能点，并不成套直接拿到权限，往往是漏洞本身只具有一个任意读、任意写、任意删除这类的文件操作能力，想要完成真正利用拿到权限还是要组合一下，比如去年比较火的spooler服务。思考了一下，最先想到的是BITS服务，过去几年这个服务时不时冒出个漏洞，在itm4n博客上找了一个利用--【CVE-2020-0787-Windows BITS - An EoP Bug Hidden in an Undocumented RPC Function】（文章链接在文后）。直接在服务器上运行一下（这种类型漏洞大可放心，失败了也不会有什么问题），显示的结果来看，最后一个操作显示Failed，看了一眼整体输出信息，发现写了一个名为WindowsCoreDeviceInfo.dll的DLL到system32目录，到这里显示都是success，dir看了下WindowsCoreDeviceInfo.dll文件，也确实存在并且日期也是刚才的，而唯独最后显示了Fail。

    回来翻看代码，这里失败的地方是调用USO的COM接口去加载WindowsCoreDeviceInfo.dll。此时手头上没有2008R2的虚拟机，由于同属一个系列，用WIN7看了一下，在WIN7时代，还没有USO服务，所以最后加载失败是必然的，这导致从实用角度来说，提权就是失败的。上面说过WindowsCoreDeviceInfo.dll文件确实是放在了C:windowssystem32目录下，可见漏洞利用是成功的--即CVE-2020-0787利用成功了！也就是说，这个漏洞给了我们任意目录写任意文件的能力。现在我们需要一个能把DLL加载起来的方法。大脑中过了一遍，在往常看漏洞的时候都是只关心漏洞本身，像这种加载起来的方法还真是没注意，只能搜索下找找看。在一顿搜索后，无意间看到了itm4n博客里的另一篇文章：【Windows Server 2008R2-2019 NetMan DLL Hijacking】，首先看到的“DLL Hijacking”，我们有任意写能力，不是正好配合“DLL Hijacking”么？然后再看目标版本恰巧是2008R2-2019，点进文章里面说了，这个BUG（我不认为这个是漏洞）只在SERVER版本上才有，比如WIN7是直接存在这个wlanhlp.dll的，而目标上的netman服务也是运行状态。无论如何，似乎我们有了一个完美配合的DLL加载方案！在目标上dir C:windowssysmte32wlanhlp.dll，果然不存在！于是赶紧复制代码编译，在本地WIN7上测试，“利用程序”显示success，procmon也显示成功加载了wlanhlp.dll，只不过这是在WIN7上测试的，加载的是系统真正的wlanhlp.dll。于是赶紧拿到目标上测试，使用0787的EXP成功写入wlanhlp.dll，调用netman服务的COM接口加载DLL，很遗憾，显示失败，CoCreateInstance返回了失败，说实话我有点不想不明白，在图1中我们也可以看到，当前用户也是属于NT AUTHORITYINTERACTIVE组的，在WIN7系统上（后来换到2008R2上）也多次确认这个服务的COM接口NT AUTHORITYINTERACTIVE组是有权限的：

    上面这图截图自后来的2008R2，最初是在WIN7上测试。但不管哪个系统，NT AUTHORITYINTERACTIVE是有权限的，对于目标上为什么会失败，我只能认为是环境配置问题，但具体是哪个配置导致的，我到现在都没有想明白。总之，加载DLL还是失败了！- -！

    仔细看截图2，我们注意到，除了文章提到及用到的NT AUTHORITYINTERACTIVE组，NT AUTHORITYLOCAL SERVICE组的也是可以调用这个服务的COM接口的。所以此时，我们有两个选择：

      1 我们可以分析目标上运行的进程，看看是否操作系统之外的进程，这些进程路径中如果能有DLL劫持就可以完成提权。

      2 想办法搞到NT AUTHORITYLOCAL SERVICE或者NT AUTHORITYNETWORK SERVICE账户，而这两个账户都是服务账户，差异只在于是否提供网络的服务。

    想了想，方法1从漏洞角度来说确实可以，但即便DLL放到安装目录了，我们还是需要重新启动进程才会加载我们劫持的DLL，而这意味着我们要有结束进程的权限，此路不同，另外一个途径就是需要找到一个不结束进程但可以让进程运行到动态加载DLL(Lloadlibrary)的代码，而这意味着我们需要分析这些软件。相比之下，还是选择方法2更合适，毕竟跟操作系统服务打交道网上还是有很多漏洞文章可以参考--我们只需要找到一个拿到服务账户的方法即可。于是继续用OleViewdotnet挨个查看提供了COM接口的服务，主要是查看调用权限。

    在WIN7中找了一会儿，来到了UPNP服务，印象中，有一篇漏洞文章就是关于UPNP服务的，并且那文章里也有提到NETWORK SERVICE.于是简单搜索了一下翻回那文章：【Windows本地提权漏洞分析（CVE-2019-1405及CVE-2019-1322）】，这篇文章中，其实是通过两个漏洞组合拿到了SYSTEM权限，有兴趣的可以全看完。但这里我们只关心前一个漏洞：CVE-2019-1405，通过文章我们知道这个漏洞主要是任意用户可以通过这个服务得到LOCAL SERVICE身份：

    Bingo! 我们可以得到LOCAL SERVICE身份就可以完成方法2了！下载了源码之后改了一下，创建wscript.shell实例后调用run方法运行一个bat，这个bat中写了nc反弹的命令，然后本地监听端口用CVE-2019-1405来完成反弹拿到LOCAL SERVICE。在WIN7中测试一下确认可以成功拿到Local Service身份后，搬到目标上运行，但并没有监听到会话，CVE-2019-1405 EXP显示CoCreateInstance失败。总之，在WIN7上测试可以使用的方法在目标上失败了！

    经过慎重考虑（主要是我想搞明白为何失败）后，提权事还是要继续。于是严肃对待问题，下载了win server 2008R2 ISO后虚拟机装上。换到2008R2后，我的焦点还是在COM上，仔细看了很多服务。后来无意中注意到，UPNP服务在2008R2中是默认禁用的！甚至连UPNP依赖的SSDP Discovery服务也是禁用的！

    目标上net start，果然UPnP并没有运行！这真是吃了不认真的亏，没有严格模拟目标系统造成的错误！

    至此，算是知道了CVE-2019-1405失败的原因了，只能继续找其他的方法。这时时间晚了，就直接锁屏下班回家了，而此时2008R2中的Procmon还在运行着，过滤着netman服务进程的加载DLL事件。

    第二天上班，打开虚拟机注意到Procmon中有一堆DLL加载的事件，其中就有加载wlanhlp.dll，看了下时间是昨天我下班之后。所以，很可能是操作系统其他地方也用到了netman服务本身的INetConnection接口的GetProperties方法！也就是说即使我们不主动调用COM接口完成DLL加载，系统本身其他地方也会用到这个功能从而触发加载wlanhlp.dll！于是，我们只需要利用CVE-2020-0787把DLL放到system32目录下即可，然后就是等待最多一晚上第二天就可以拿到SYSTEM！于是在2008R2虚拟机上测试一下，发现最多15分钟就会DLL加载起来完成添加系统账户。测试成功后跟渗透人员说了一下并付诸实施，时间20分钟、注销登录2次后，在目标上成功提权添加了系统账户！

    过了一段时间渗透人员说目标其实有两个服务器，这俩服务器情况一样，可以理解为分担负载，操作系统和配置都完全一样，他也想用这个方法提权另一台服务器。但是等了半小时都没有成功，再次操作一遍发现确实没有成功。这时候想到之前的主动调用netman中COM对象的方法加载DLL，于是抱着试一试的心态，居然在这个完全配置一样的服务器上可以成功加载DLL。

    至此，此次提权之旅算是结束了。而留下的为何第一目标netman主动加载DLL的方法调用失败，留给日后分析了...

原文始发于微信公众号（漏洞分析自留地）：使用漏洞组合拳拿下服务器SYSTEM