0x00 前期
拿到測試范圍清單后，首先用腳本獲取了下各個子站的標題，基本都是XXX管理系統(tǒng)。瀏覽器查看后，各個子站也大同小異，純登錄系統(tǒng)，帶驗證碼。這些系統(tǒng)基本都是jsp寫的，逮到了兩個沒有驗證碼的小寶貝，一番暴力破解，小寶貝對我說：別愛我，沒結(jié)果。又看到了兩個站返回的Set-Cookie頭：rememberMe=deleteMe; 很明顯，這是Apache Shiro。打了一波exp，沒有反應，放棄。搞了三天啥都沒搞出來，和女朋友出去玩散散心，還是很高興。
0x01 初顯進展
測試范圍內(nèi)有六個門戶網(wǎng)站，其中四個靜態(tài)站（也不知道是不是偽靜態(tài)，沒拿下來），還有兩個動態(tài)站。一個是Java寫的，一個是PHP寫的。出于對Java的敬畏之心，我對PHP下了手。是個偽靜態(tài)站，URL是這樣的：http://www.xxx.cn/index.php/lists/68.html，可是暴露的很明顯。嘗試還原為參數(shù)值，失敗，顯示下圖頁面：
很典型的MVC架構(gòu)站，嘗試指紋識別、瀏覽robots.txt，一無所獲?？戳讼虑芭_功能，除了瀏覽新聞就是下載文件，下載的文件名經(jīng)過了MD5 hash，放棄任意文件下載。沒有什么其他的功能點了，啥都不用考慮了，掃Web目錄。
掃到了composer.json、composer.lock、.htaccess以及readme.md。前兩個是composer包管理器的文件，.htaccess是Apache的配置文件，能夠直接下載有點奇怪。重頭戲就在readme.md了，查看得知此CMS名為PCCMS，基于ThinkPHP 5.1開發(fā)。百度了一下，并沒有發(fā)現(xiàn)PCCMS的源代碼，也沒有相關(guān)漏洞信息，太小眾了吧。以前也見過很多識別不出來的CMS，可能有的人就是喜歡用小眾CMS？百度啥也沒找到，谷歌也不用說了，中國人自己都用的不多，哪有外國人去關(guān)注這小CMS。
又去仔仔細細地瀏覽了下載下來的文件，composer.json里都是些開源組件的信息，又臭又長，又去看了下readme.md。里面給了后臺管理頁面截圖的地址，我進不去后臺，看看后臺長什么樣子不過分吧哈哈。復制截圖地址在瀏覽器打開，UI挺好看的，仔細再看看，看到了YZNCMS幾個字。百度了一下，找到了gitee的項目地址。好家伙，readme里提到是基于ThinkPHP 5.1開發(fā)的，其實是基于YZNCMS三次開發(fā)的。
直接去找TP 5.1的RCE payload，沒有什么反應，估計是被修復了?？戳讼耏ZNCMS的目錄結(jié)構(gòu)，和TP沒有什么不一樣，通過閱讀源代碼確認RCE被修復了。但是我發(fā)現(xiàn)了一個有趣的文件——yzncms.sql，這是MySQL的備份文件。試著在網(wǎng)站上訪問yzncms.sql，404。改名為pccms.sql，彈出了下載框，28M，有戲。
0x02?登錄旁站
本來以為這單純是建站時用于創(chuàng)建表結(jié)構(gòu)用的，打開后發(fā)現(xiàn)，居然還有文章信息?？雌饋聿辉俸唵瘟?，直接搜索password，在pccms_admin表找到了兩個賬戶密碼。密碼都有鹽，admin的密碼解出來是admin，登錄不上后臺，意料之中。根據(jù)賬戶的最后登錄時間戳來看，這CMS最晚的備份時間是去年7月，一個站用admin做密碼，很難保證一年不被日。另一個賬戶的密碼沒解出來，思路這時候又斷掉了。去看了測試范圍外的一個子站，也是相同cms，ping一下IP，是個旁站。直搗黃龍，下載pccms.sql，發(fā)現(xiàn)兩個站管理員賬號密碼居然一樣？嘗試去登錄，依舊失敗。去對比了兩個sql文件的sha1哈希值，一模一樣，操……又看了一下用戶名，另一個用戶名和子域名有相同之處，這個備份文件無疑是從旁站復制過來的了，可能是去年7月遷移了服務器。
admin沒搞定，只能打剩下的那個賬戶的主意了。雖然cmd5解不開，但是我有hashcat呀。把哈希值和鹽都復制出來，用hashcat配上我的辣雞1050ti顯卡，幾秒鐘不到居然跑出了密碼，123456操……
登錄網(wǎng)站，失??；登錄旁站，成功。操，旁站在測試清單之外。去向老師傅請示了一下，老師傅說先別測。我也累了，休息了。
第二天，老師傅說，旁站也在測試范圍之內(nèi)。
0x03 自助提權(quán)
此時已經(jīng)是項目第六天，也就是昨天。登進了旁站的后臺，當前用戶是編輯權(quán)限。編輯也好， 比之前的普通會員權(quán)限大多了，還能編輯文章。
我的目標只有一個，拿shell。一波操作猛如虎，附件管理、圖片上傳、廣告位上傳，都試了一遍，一共兩個上傳接口，CMS自帶的和Ueditor的，文件后綴限制的死死的，文件名md5哈希過，看樣子是沒辦法繞過去了。
這時，一處不應出現(xiàn)的邏輯漏洞出現(xiàn)了。在管理員管理功能點，我發(fā)現(xiàn)了這個
操作之后，系統(tǒng)提示修改成功
絕了，此功能堪稱自助提權(quán)，邏輯漏洞中的黑洞。
0x04 getshell
刷新頁面，加載超管的功能模塊，主要增加了會員管理、角色管理、模型管理模塊。三個模塊沒有一處上傳點，這時候我在“其他”模塊里找到了插件管理功能，顯眼的本地安裝吸引了我的注意力。
結(jié)合我對應用開發(fā)的認知，以及之前日Empire CMS、WordPress的經(jīng)驗，Web應用的功能基本都是由腳本實現(xiàn)。那么，這個插件也會是php寫的，想拿到shell，需要構(gòu)造一個惡意插件安裝包。在gitee項目頁面搜羅了一番，找到了一個手冊，手冊里什么都有，唯獨插件開發(fā)那欄是空的。那么只剩一條路了，代碼審計?？戳讼耡ddons.php的代碼，船頭調(diào)用API到船尾，我沒造過船，看不懂，放棄。其實還有一條路，黑盒測試嘛，憑感覺。
按照其他插件的目錄結(jié)構(gòu)，我創(chuàng)建了一個config.php，其內(nèi)容是：
<?php
? ? return null;
?>
又創(chuàng)建了一個info.php，調(diào)用phpinfo()函數(shù)，為了防止觸發(fā)WAF規(guī)則，我習慣先上一段正常代碼。將兩個文件壓縮后，直接上傳，系統(tǒng)彈出這樣的提示：
看來也就是個普通壓縮包，根據(jù)gitee項目的目錄結(jié)構(gòu)，我確定插件解壓在addons目錄下，路徑格式為： /addons/插件安裝包名/文件名。訪問了下插件目錄，因為沒有默認索引頁，服務端響應403，表示目錄存在。又訪問了info.php，還是403，這就不正常了。根據(jù)之前的TP環(huán)境搭建經(jīng)驗，可能是.htaccess中的url重寫功能影響了對shell的直接訪問。那么，可以在目錄下重寫一個.htaccess，覆蓋apache的配置。于是我寫了這樣一段.htaccess：
<FilesMatch "info">
? ? SetHandler application/x-httpd-php
</Filesmatch>
這個配置文件的作用是，把文件名包含info的文件，都當作php腳本解析。重新訪問info.php后，我發(fā)現(xiàn)配置并沒有生效。因為…這個Web容器根本不是Apache！??！看了下響應頭，是openresty。我對這玩意非常陌生，一直認為只有CDN服務器才會用它。
換個思路，php不能解析，是不是整個addons目錄都被配置為不可訪問。我又傳了txt純文本，發(fā)現(xiàn)可以訪問到文本內(nèi)容。此目錄有訪問權(quán)限，只是不能訪問PHP。我試著將php1-php7所有的后綴都打包成一個插件安裝包，然而還是403。試著轉(zhuǎn)換大小寫，訪問pHP，還是失敗。可能使無視大小寫，而且php1-php7都在黑名單里吧。最后，第七次上傳安裝包時，我用了php12345的后綴，通過訪問pHP12345，成功看到藍色的phpinfo，解析了，shell穩(wěn)了。前前后后七次，終于要拿到shell了，我又有出息了=_=。直接上冰蝎馬：
給冰蝎設置好測試用的代理，連接shell。然而，冰蝎一直在轉(zhuǎn)圈圈，加載信息。看了看burp的http記錄，發(fā)現(xiàn)只發(fā)了兩個包，獲取了兩次密鑰。兩次都沒被攔截，冰蝎也沒有發(fā)第三個包，問題可能不在服務端。排查了一下，恍然大悟。我用畸形后綴解析了shell，冰蝎不能根據(jù)擴展名識別腳本類型，手動設置為php后，成功連接。
整個過程梳理起來，發(fā)現(xiàn)并不是很難。不輕易放棄，關(guān)注細節(jié)，總是能挖到洞的。
