这是一篇“不一样”的真实渗透测试案例分析文章

这是一篇“不一样”的真实渗透测试案例分析文章
2020-03-18 19:34:06 Author: www.secpulse.com(查看原文) 阅读量:371 收藏

作者：cheery@QAX-ATEAM && n0thing@QAX-ATEAM

校对：L.N.

同时感谢n1nty、pr0mise、2月30日对本文提出的宝贵建议。

本文是由一次真实的授权渗透案例引申而出的技术分析和总结文章。在文章中我们会首先简单介绍这次案例的整体渗透流程并进行部分演绎，但不会进行详细的截图和描述，一是怕“有心人”发现端倪去目标复现漏洞和破坏，二是作为一线攻击人员，大家都明白渗透过程也是一个试错过程，针对某一个点我们可能尝试了无数种方法，最后写入文章的只有成功的一种，而这种方法很有可能也是众所周知的方法。因此我们只会简单介绍渗透流程，然后提取整个渗透过程中比较精华的点，以点及面来进行技术分析和探讨，望不同的人有不同的收获。

在接到项目以后，由“前端”小组（初步技术分析小组）进行项目分析和信息收集以及整理，整理出了一批域名和一些关键站点，其中有一个phpmyadmin 和 discuz的组合建站，且均暴露在外网，这也是很常见的一种情况。由于网站某个web端口的解析配置问题导致了php不被解析而形成任意文件下载漏洞，通过这个漏洞我们拿到了mysql的root账户密码。由于linux服务器权限设置比较严格的问题没法直接使用phpmyadmin登录mysql而提权拿到discuz的webshell。经过多种尝试我们利用phpmyadmin替换管理员hash而登录discuz后台，在discuz后台利用修改ucenter配置文件的漏洞写入了webshell。

在进入内网以后，通过简单的80、443探测内网的web时候发现了一个含有java webdav的服务器（域内windows，后文中以A服务器称呼），利用java webdav的xxe去执行NTLM Relay。同时收集discuz数据库中用户名利用kerberos AS_REQ和密码喷射(一个密码和不同用户名的组合去KDC枚举)幸运的获得了一组域内用户的账户和密码，利用这个用户增加了一个机器账户。结合NTLM Relay和这个机器账户利用基于资源的约束委派，成功的使这个机器账户具有了控制A服务器的权限。登录A服务器绕过卡巴斯基抓取到了域管理密码，这次攻坚任务也因此而结束。图示如下：

在这次渗透流程中我们认为Discuz x3系列和xxe到域控这两个点是值得拿出来分析和探讨的。

本节分为3部分，首先将对Discuz X3以后的版本出现的主要漏洞做一个简单总结，然后针对discuz的几种密钥做一些分析，最后发布一个discuz最新的后台getshell。

Discuz X3以后漏洞总结

目前市面上基本都是x3以上的Discuz程序了，x3以下的网站占比已经非常低了，因此在此只总结x3以上的漏洞。总结并不是对每个漏洞进行重新分析，这是没有必要的，网上已经有很多优秀的分析文章了。那我们为什么还要总结呢？如果你是在一线做渗透测试或者红队评估的同学，应该会经常遇到discuz，往往大部分同学一看程序版本再搜搜漏洞或者群里问问就放弃了。在大家的印象中discuz是一块硬骨头，没必要耗太多时间在它身上，但事实上discuz并不是你所想象的那么安全。本小节将通过总结discuz的各种小漏洞，再结合我们自己的几次对discuz目标的突破，提出一些利用思路和利用可能。

总结：

针对于discuz的ssrf漏洞，在补丁中限制了对内网ip的访问，导致了很难被利用。
在后台getshell中，建议使用uc_center rce比较方便，并且通杀包括最新版本，后文有分析。
UC_KEY 直接getshell已在x3以上的最新版本被修复，但在一些老的3.2以前的版本可能被利用。

以上这些漏洞应该并不全面，且看似都比较鸡肋，但往往千里之堤毁于蚁穴，几个不起眼的小漏洞组合一下会发现威力巨大。仔细的读者应该发现以上漏洞大部分能够造成的最大危害是信息泄露，信息泄露有什么用呢？下面我们将接着分析Discuz的几种密钥，看到这儿你应该已经明白了，通过信息泄露，获得相关密钥，突破discuz的加密体系，进而获取更高的权限。

Discuz的几种密钥分析

通过分析，在discuz中,主要有下面的几种密钥, 这些密钥共同构成了discuz的加密解密体系，这里的命名有重复，我已经标记了对应key值以及key所在的位置。如下表所示：

主要探讨的其实就只有 authkey,UC_KEY(dz),UC_KEY(uc_server),UC_MYKEY,authkey(uc_server) 5种,我们首先来看着几个密钥是怎么来的最后又到了哪儿去。

密钥的产生

authkey,UC_KEY(dz),UC_KEY(uc_server),UC_MYKEY 都是在安装的时候产生。authkey(uc_server)的产生是和UC_MYKEY息息相关的，在后文中详细讲述。生成代码如下所示：

我们看见key的产生都依赖于discuz 自定义的random函数，出现过的authkey爆破问题也因此产生。在安装时由于处于同一个cgi进程，导致mt_rand() 只播种了一次种子，所以产生了随机数种子爆破和推测key的问题，在3.4版本中，authkey的产生已经是拼接了完整的32位字符串，导致了无法进行爆破推算出authkey的前半部，因此这个问题已经被修复，但这个漏洞原理值得学习。代码最后可以看出authkey产生后还放入了数据库中，最终authkey存在于数据库pre_common_setting表和/config/config_global.php配置文件。代码中的 instal_uc_server()函数实现了UC_KEY(dz),UC_KEY(uc_server)的产生，使用了同一个生成函数_generate_key()，代码如下：

产生的算法牵扯到安装环境和安装过程的http header信息，导致爆破基本失效，从而无法预测，最后UC_KEY(dz)保存到了/config/config_ucenter.php中，UC_KEY(uc_server)保存到了/uc_server/data/config.inc.php中。

Discuz Key的相关思考

我们通过查看源码，去分析每个key影响的功能，通过这些功能点，我们可以去获得更多的信息。信息的整合和利用往往是我们渗透的关键。下面我们将做一些抛砖引玉的思考并举一些例子，但不会面面俱到一一分析，这样也没有意义，具体的代码还是需要读者自己亲自去读才能印象深刻。

1. authkey

authkey的使用在discuz主程序中占比很重，主要用户数据的加密存储和解密使用，比如alipay相关支付数据的存储和使用、FTP密码的存储等等；还用于一些功能的校验，比如验证码的校验、上传hash的校验等等；用户权限的校验也用到了authkey，比如source/class/discuz/discuz_application.php 中_init_user() 利用authkey解码了cookie中的auth字段，并利用解开的uid和pw进行权限校验，但是光知道authkey并不能完成权限校验，我们还需要知道用户的”密码hash“(数据库pre_common_member表中的password字段，此处存储的只是一个随机值的md5，真正的用户密码hash在pre_ucenter_members中)，当我们通过其他方法可以读取数据库数据时，我们就可以伪造登陆信息进行登陆，再比如source/include/misc/misc_emailcheck.php中authkey的参与了校验hash的生成，当我们知道了authkey后，通过伪造hash，我们可以修改用户的注册邮箱，然后利用密码找回来登陆前台用户(管理员不能使用密码找回功能)。

2. UC_KEY(dz)

UC_KEY(dz)也是经常提到的UC_KEY GetWebShell的主角。它主要在2个地方被使用：一个是数据库备份api/db/dbbak.php；一个是针对用户以及登录和缓存文件相关的操作，主要函数位于api/uc.php中的uc_note类。

关于UC_KEY(dz)的利用，网上基本都是通过uc.php来GetWebShell，但这个漏洞在新版本已经被修复了。UC_KEY(dz)的利用并不局限与此，你去阅读dbbak.php代码就会发现，有了UC_KEY(dz)我们可以直接备份数据库，下载数据库，从数据库中找到相关信息进行进一步渗透。

另外一个地方就是uc_note类，比如里面的synlogin()函数可以伪造登陆任意前台用户。当然还有其他的函数，在这里就不一一分析。

3. UC_KEY(uc_server)

UC_KEY(uc_server)往往是被大家忽视的一个key，它其实比UC_KEY(dz)的使用更多。首先他同样可以备份数据库，对discuz代码比较熟悉的同学应该知道dbbak.php这个文件有2个，一个是上面提到的api/db/dbbak.php；另外一个是uc_server/api/dbbak.php，他们的代码可以说几乎相同。唯一的区别是api/db/dbbak.php中多了2个常量的定义，基本没有太大影响。这个2个文件都能被UC_KEY(dz)和UC_KEY(uc_server)操控。

UC_KEY(uc_server)几乎管控了Ucenter的所有和权限认证相关的功能。例如权限验证函数 sid_decode() ，在该函数中UC_KEY(uc_server)和用户可控的http header共同产生了用于权限认证的sid，因此我们可以伪造sid绕过一些权限检测。还有seccode的相关利用，在这里就不一一介绍。

整个discuz的程序其实是包含了discuz主程序和Ucenter，Ucenter更依赖于固定密钥体系，个人感觉Ucenter的漏洞可能要比discuz主程序好挖些，你可以去试试。

4. UC_MYKEY

UC_MYKEY主要用来加密和解密UC_KEY(discuz)，如下所示：

authkey(uc_server)存储在数据库的pre_ucenter_applications中的authkey字段，authkey(uc_server)生成的代码如下:

现在我们就可以知道其实UC_KEY(dz)是可以从2个地方获取到的，一个是配置文件，一个是数据库。对discuz比较熟悉的同学这里会发现一个问题，通过注入获得的authkey (uc_server)，有时候可以直接当UC_KEY(dz)用，但有时候发现是一个大于64位的字符串或小于64位的字符串。这个是因为，如果你是默认discuz主程序和Ucenter安装，这个时候数据库pre_ucenter_applications中的authkey字段存储的就是UC_KEY(dz)，如果你通过ucenter后台修改过UC_KEY(dz)，数据库pre_ucenter_applications中的authkey字段存储的就是通过上面提到的算法计算出来的结果了，这个结果的长度是变化的，是一个大于等于40位的字符串。

总结

针对于getshell来说，在x3以前的低版本和部分未更新的x3.2以前版本，我们可以直接利用discuz的uc_key(dz)结合api/uc.php前台getshell,获得uc_key(dz)的方法有:

数据库中的authkey(uc_server)结合UC_MYKEY，这个在UCenter后台也能看见，没有使用*显示。
文件泄露等问题获得uc_key(dz)

在x3版本以后，对于key的利用主要集中在操作数据库和UCenter功能上，利用各种办法进入discuz后台，结合接下来讲到的后台GetWebShell的方法获取最终权限。

后台GetWebShell的补丁绕过

在小于x3.4的版本中，网上已经公布的利用方法是：后台修改Ucenter数据库连接信息，由于写入未转义，一句话木马直接写入config/config_ucenter.php文件中，导致代码执行。

但是在新版本的x3.4中已经修复了这个漏洞，代码如下：

补丁对 $ucdbpassnew 进行了转义，而且if(function_exists("mysql_connect") && ini_get("mysql.allow_local_infile")=="1" && constant("UC_DBHOST") != $settingnew['uc']['dbhost']), 该补丁还解决了恶意mysql文件读取的问题。

绕过补丁

通过补丁，我们知道了所有的Ucenter配置参数都会进行转义，但是我发现discuz的配置文件更改，都是利用字符替换完成的，在替换字符中，很容易出现问题，所以在源码中寻找配置修改的相关代码，最后在 api/uc.php 中找到了利用点。

在 updateapps 函数中完成了对 uc_api 的更新，这里的正则在匹配时是非贪婪的，这里就会存在一个问题，当uc_api为 define('UC_API', 'http://127.0.0.1/discuz34/uc_server');phpinfo();//'); 时，我们执行updateapps函数来更新uc_api时就会将phpinfo();释放出来。要使用updateapps函数来更新uc_api，我们需要知道UC_KEY(dz)的值，而UC_KEY(dz)的值，恰好是我们后台可以设置的。

利用分析

进入后台站长-Ucenter设置，设置UC_KEY=随意(一定要记住，后面要用), UC_API= http://127.0.0.1/discuz34/uc_server');phpinfo();//

成功写进配置文件，这里单引号被转移了，我们接下来使用UC_KEY(dz)去调用api/uc.php中的updateapps函数更新UC_API。

利用UC_KEY(dz) 生成code参数，使用过UC_KEY(dz) GetWebShell的同学肯定不陌生，这里使用的UC_KEY(dz)就是上面我们设置的。
将生成的数据带入GET请求中的code 参数，发送数据包
访问http://127.0.0.1/discuz34/config/config_ucenter.php 代码执行成功

到此成功GetWebShell，在这个过程中，有一点需要注意的是，我们修改了程序原有的UC_KEY(dz)，成功GetWebShell以后一定要修复，有2中方法：

从数据库中读取authkey(uc_server)，通过UC_MYKEY解密获得UC_KEY(dz)，当然也有可能authkey(uc_server)就是UC_KEY(dz)。
直接进入Ucenter后台修改UC_KEY，修改成我们GetWebShell过程中所设置的值。

在本节中我们会讲到WEBDAV XXE（JAVA）利用NTLM Relay和一个机器账户去设置基于资源的约束委派来RCE的故事。当然绕过卡巴斯基dump lsass也是非常的精彩。流程图示如下：

WEBDAV XXE

前文中已经提到了我们进入内网后发现一台部署着java应用的web服务器，并探测出该网站存在/webdav目录。

在一个国外安全研究员的ppt(What should a hacker know about WebDav? )中这样提到： 一般webdav支持多种http方法，而PROPPATCH、PROPFIND、 LOCK等方法接受XML作为输入时会形成xxe。

我们探测下支持的http方法：

我们在测试PROPFIND方法时成功收到了xxe请求：

常规的xxe一般会想到任意文件读取、以及网上提到的利用gopher打redis等。在《Ghidra 从 XXE 到 RCE》中提到利用java xxe做ntlm relay操作。由于sun.net.www.protocol.http.HttpURLConnection 发送HTTP请求遇到状态码为401的HTTP返回头时，会判断该页面要求使用哪种认证方式，若攻击者回复要求采用NTLM认证则会自动使用当前用户凭据进行认证。

现在我们成功获取到了NTLM认证请求，接下来就是NTLM中继了。

NTLM中继和域机器账户添加

什么是NTLM中继

相信大家都不陌生，要理解什么是NTLM中继首先要知道NTLM认证的大致流程，这里做个简单讲述，详细请参考The NTLM Authentication Protocol and Security Support Provider。

NTLM身份验证协议中包含3个步骤：

协商：NTLM身份验证的第一步是协议的协商，以及客户端支持哪些功能。在此阶段，客户端将身份验证请求发送到服务器，其中包括客户端接受的NTLM版本。
质询：服务器以自己的消息作为响应，指示其接受的NTLM版本以及要使用的功能。该消息还包括challenge值。
响应：收到challenge后客户端用hash将challenge加密，作为NTLM Response字段发送给服务器。

NTLM身份验证是基于质询响应的协议，服务器发送一个质询，客户端对这个质询进行回复。如果质询与服务器计算的质询匹配，则接受身份验证。

知道了NTLM身份认证的大致流程，我们再来说NTLM中继，如下图所示，如果我们可以让Client A 向我们的Evil Server X，发起NTLM认证，那么我们就可以拿Client A的身份验证信息去向Server B进行认证，这便是ntlm中继。看到这里你会觉得说了那么多不就是中间人攻击么，对就是中间人攻击。

知道了NTLM中继，结合Java WEBDAV XXE的作用，利用HTTP 401的认证，我们可以直接利用WEBDAV服务器的凭据向域控发起认证，让域控以为我们是WEBDAV服务器。

在域中增加机器账户

在这里可能有同学有疑问了，前面不是提了中继么？为什么不用《Ghidra 从 XXE 到 RCE》和《Ghost Potato》里提到的方式去Relay回自身调用RPC进行相关操作，还要增加机器账户呢？因为这个WEBDAV服务是system权限运行的，而system账户做Relay时是用机器账户去请求的，没有办法去调高权限RPC接口，所有这里不能直接Relay回自身调用RPC。

既然不能直接Relay回自身调用RPC，我们换一种思路，用基于资源约束委派一样可以获取权限。

在通过基于资源约束委派进行利用时，需要有一个机器账户来配合（这里说法其实不太准确，应该是需要一个具有SPN的账户，更详细的说是需要一个账户的TGT，而一个机器账户来代替前面的说法，是因为机器账户默认具有一些SPN，这些SPN包含了我们后面会用到的cifs等，这里就不细说了，不然又是一篇文章了，后面统一用机器账户来描述），而默认域控的ms-DS-MachineAccountQuota属性设置允许所有域用户向一个域添加多达10个计算机帐户，就是说只要有一个域凭据就可以在域内任意添加机器账户。这个凭据可以是域内的用户账户、服务账户、机器账户。

那么问题又来了，既然需要一个机器账户，前面提到的

system账户做Relay时是用机器账户去请求

这个地方说的机器账户，也就是我们文中的WEBDAV服务器的机器账户，为什么不用这个机器账户，要自己去增加一个呢？了解基于资源约束委派的同学应该知道，我们需要用机器账户去申请TGT票据，但是我们如果用WEBDAV服务器的机器账户，我们不知道这个机器账户的密码或者hash。没有办法去申请TGT。如果是我们创建的机器账户，我们是知道密码的，这样才能去申请TGT了，这里就不在深入继续分析了，里面涉及到的过程极其复杂，有兴趣的同学可以自行学习。

回归正题，我们怎么在域中去创建一个机器账户。

我们把在之前的discuz数据库中的用户名整理成字典，并通过kerberos AS_REQ返回包来判断用户名是否存在。

接下来将discuz的密码拿到cmd5上批量解密，解密后发现大部分用户的登录密码都是P@ssw0rd，于是使用密码喷射(一个密码和不同用户名的组合去KDC枚举) ，成功获取到了一个域凭据[email protected]:P@ssw0rd

有了域凭据后就能连接域控ldap添加机器账户了，不得不说.net真是个好语言，用System.DirectoryServices.Protocols这个东西很轻松就能实现该功能。

有细心的同学看到这里可能会想: "用xxe中继到域控的ldap然后添加一个机器账户不是美滋滋? 哪需要这么花里胡哨的！"。但是域控不允许在未加密的连接上创建计算机帐户，这里关于加密涉及到tls/ssl和sasl，又是一堆的知识，这里就不细聊了。

用.net写的小工具很轻松地添加上了一个机器账户。

现在我们有了机器账户，接下来就利用基于资源的约束委派。

基于资源的约束委派

Windows Server 2012中新加入了基于kerberos资源的约束委派(rbcd)，与传统的约束委派相比，它不再需要域管理员对其进行配置，可以直接在机器账户上配置msDS-AllowedToActOnBehalfOfOtherIdentity属性来设置基于资源的约束委派。此属性的作用是控制哪些用户可以模拟成域内任意用户，然后向该计算机(dev2)进行身份验证。简而言之：如果我们可以修改该属性那么我们就能拿到一张域管理员的票据，但该票据只对这台机器(dev2)生效，然后拿这张票据去对这台机器(dev2)进行认证（这里只是简单描述，可能不太准确，还是那句话基于资源的约束委派整个过程细节及其复杂，笔者也不敢说掌握全部细节）。

现在我们开始实际操作，首先在我们的VPS上利用impacket工具包中的ntlmrelayx.py工具监听。