利用dns特性把普通域用户提升到域管理员权限

翻译自：https://medium.com/@esnesenon/feature-not-bug-dnsadmin-to-dc-compromise-in-one-line-a0f779b8dc83
翻译人：聂心明

背景

除了使用自己开发的DNS服务器以外，微软还给这个服务器开发了管理协议，用这个协议可以更方便和更集中的管理域控服务器。默认情况下，域控服务器也是DNS服务器；DNS服务器几乎可访问和使用几乎每一个域用户。这就导致在域控服务器上暴露了很多的攻击面—一方面是dns协议本身，还有基于RPC的管理协议。

我们讲浅显的揭示这个协议的功能还有一些比较有趣的功能（确定不是漏洞！），这个功能允许我们在某些情况下在域控服务器中以SYSTEM权限执行任意代码，而这个操作不需要用到域管理员权限。所以这个确定不是一个安全问题（所以不要恐慌），经过微软的确认，红队经常用这个有趣的功能来提升域权限。
要想获取所有的信息可以去看协议说明书：([MS-DNSP], https://msdn.microsoft.com/en-us/library/cc448821.aspx) ，也可以用IDA逆向dns.exe

DNS管理协议基础

管理协议是基于RPC协议层的，这个协议也可以基于tcp协议或者命名通道。如果你对这个复杂的协议或者它的实现感兴趣，你能在域控服务器中的c:\windows\system32\dns.exe 找到它。这个RPC的接口UUID是50ABC2A4–574D-40B3–9D66-EE4FD5FBA076并且它使用\PIPE\DNSSERVER 这个命名空间来传输数据。

dns作为一个服务运行在域控服务器中。可以通过运行dnsmgmt.msc来访问这个管理接口，并且它也可以连接到AD DNS服务器中（通常这个也是域控服务器）。它允许用户去配置诸如：DNS搜索域，查询域，缓存，转发和日志。在某个‘层级’的对象是安全的–DNS服务对象（这个不是一个计算机帐户），区域对象和记录对象。在这种情况下，我们感兴趣的是服务器对象，它的ACL在全新服务器中的样子如下图：

默认情况下，这个对象就有DnsAdmins, Domain Admins, Enterprise Admins, Administrators 和 ENTERPRISE DOMAIN CONTROLLERS这些权限。很明显，从攻击者的角度来看，如果我们是除了DnsAdmins之外的其他组的成员，那么我们就已经拥有了这个域。所以，让我们看看，如果我们自己是DNSAdmin的话，我们能做什么。

获取文档的PDF

这个协议说明书中的3.1.4节对我们很有帮助：
消息处理事件和排序规则，基本上详细描述了服务器需要支持的所有操作。首先第一点是R_DnssrvOperation，它包括一个pszOperation参数，这个参数决定了服务器所执行的操作。当你查看pszOperation 这个参数列表时，你会看到下面这个：

现在，我们仅仅告诉服务器我们将要加载的dll！太好了！通过搜索ServerLevelPluginDll的文档，我们发现下面一段有用的信息：

看起来在这次操作中服务器没有验证dll的路径。在我挖到这个漏洞之前，我想肯定有前人已经挖到这个漏洞了。用谷歌寻找"ServerLevelPluginDll" 这个插件，没有类似的结果，无论怎么样，我以前从来不知道，dnscmd是这么的有用。
幸运的是，dnscmd已经被广泛的运用了。快速的看一眼帮助信息： https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/dnscmd，可以发现下面的选项

dnscmd.exe /config /serverlevelplugindll \\path\to\dll

首先，在DNS服务器对象上用一个普通的没有特殊权限的域用户（除了读取权限，还要获得所有Pre-Windows 2000兼容访问组成员的权限，还要被包含在域用户组里面）运行这个命令，如果这个命令执行失败，那么将返回“访问被阻止”。如果这个普通域用户具有这个服务器对象的写权限，那么这个命令就会成功的执行。这就意味着，DnsAdmins的成员能够成功的执行这个命令。
现在还用不着IDA，试者在拥有DnsAdmins成员的域控计算机上运行这个指令，同时，我们的域控上要运行process monitor和process explorer，我们看到没有我们希望的dll被加载到dns.exe的地址空间中。但是，我们传入的路径已经被填充到注册表的健值里面了：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters\ServerLevelPluginDll

很好。现在我们出于测试的目的重启DNS服务。但是很不妙，我们的dns服务重启失败了，我们必须清理相关的注册表项才能启动dns服务。显然，我们的dll中还缺少一些东西，这个时候我们要打开IDA看看了。
在这种情况下，有几种可能性可以快速的达到我们的目的–快速和简单方法是寻找相关的字符串或者相关的APIs。我们搜索LoadLibraryW或者GetProcAddress的交叉引用（xref）即可，也就是说，我们要寻找一个函数，这个函数使用LoadLibraryW加载我们的dll文件还有这个函数的父函数，我们发现提供给ServerLevelPluginDll的参数路径没有任何限制。
我们遇到的障碍只有一个–如果dll加载失败，或者导出函数中没有包含DnsPluginInitialize，DnsPluginInitialize或者DnsPluginQuery，我们的服务也会启动失败。我们也要确保这些导出函数全部返回0（成功执行的返回值），否则他们也会导致服务启动失败。
负责加载dll的伪代码如下所示：

HMODULE hLib;
if (g_pluginPath && *g_pluginPath) {
  hLib = LoadLibraryW(g_pluginPath);
  g_hndPlugin = hLib;
  if (!hLib) {...log and return error...}
  g_dllDnsPluginInitialize = GetProcAddress(hLib, "DnsPluginInitialize");
  if (!g_dllDnsPluginInitialize) {...log and return error...}
  g_dllDnsPluginQuery = GetProcAddress(hLib, "DnsPluginQuery")
  if (!g_dllDnsPluginQuery) {...log and return error...}
  g_dllDnsPluginCleanup = GetProcAddress(hLib, "DnsPluginCleanup")
  if (!g_dllDnsPluginCleanup) {...log and return error...}
  if (g_dllDnsPluginInitialize){
    g_dllDnsPluginInitialize(pCallback1, pCallback2);
  }
}

我们可以构造一段简单的PoC代码。在Visual Studio 2015中，满足利用条件的DLL文件代码如下所示：

插件的示例代码
编译指示用于将默认导出名称修改为我们想要的名称。我们使用下面的指令来验证我们的导出函数是否是有效的

dumpbin /exports path\to\dll

现在我们用我们的新dll来运行dnscmd，它成功了。现在我们只需要把dll房子域控主机用户可达的位置即可（dns.exe要运行在SYSTEM权限下)( Everyone SID对这个路径有读的权限)，之后我们就可以在域控服务器上以SYSTEM的权限运行代码了，这样我们就控制了域控服务器。
如果你是DnsAdmin组中的成员，那么你就可以通过上面提到的方法控制域控服务器，但是条件不仅限于此，我们成功的技巧是，仅仅是需要一个对dns服务对象有写权限的账户。从我的经验来看，对象的ACLs控制通常不像域管理员那样严格（或者类似于被AdminSDHolder保护的用户组），所以我们可以利用这个小技巧来达到提权的目的。
正如文档所示，这个小技巧可以应用于大多数的windows服务器版本：

我已经将这个问题报告给了微软的MSRC，他们表示可以通过：只允许域控管理员去修改ServerLevelPluginDll的键值，来修复这个漏洞。并且在未来将会移除这样的功能。
但是，dns.exe依然运行在SYSTEM权限下，这样还是会暴露很多攻击面。因此我们可以从DNS实现角度以及管理接口入手，分析其脆弱性并加以应用。

时间线

3月31日，首次向secure@microsoft.com披露此问题

4月1日，问题确认，已转发审查

4月8日，MSRC将该问题标为38121案例

5月2日，微软认为这不是一个漏洞，将来会在安全更新之外修复这个问题

5月5日，讨论如何进一步加固DNS服务器所在的服务

5月8日，研究结果公布。非常感谢MSRC的Daniel处理这个问题，与他合作非常荣幸

最后，阅读微软的协议说明书是非常有用的，当你在里面搜索’DLL’时更是如此。

小小的更新（五月十日）：Nikhil Mittal详细阐述了在他的实验室中利用此功能的过程 http://www.labofapenetrationtester.com/2017/05/abusing-dnsadmins-privilege-for-escalation-in-active-directory.html
谢谢你