By：wooden，From：http://t00ls.net/viewthread.php?tid=17312。
转载请注明出处。
考虑到站点的影响力过大，全文不截图，怕漏点，大家担待
编辑:文章得到热烈响应，在下非常高兴，感谢皇子的提醒net view打成net share了 一时手快，不好意思
另有朋友提醒说webservice上出现的漏洞web上也会有，强调下，这是不可能的，webservice不同于web,他是一个独立的交互式平台，如果web上也有，那我也不会写此文了
另外，webservice的漏洞其实不算新鲜，根web上的利用方式也算一致，不过，国内目前貌似没有什么工具可以直接利用，所以只能自己构造数据包来检测了，相信这是难不倒广大黑阔的:)
国内的web安全一直在进步，大家是有目共睹的，但是对于内网方面的安全却一直停滞不前，早在08年时，有幸应邀检测了国内的一家游戏公司，在web方面的安全的确做的不错，但是偶然的一个漏洞突破进内网时，发现内部的安全架构，以及管理员的安全意识等，惨不忍睹，最终导致旗下多款热门网游沦陷....而此次的渗透，再次告诉大家，2年多来，内网安全至今仍是不尽人意...
具体过程如下：
Host:http://www.xx.com
习惯性的加个index.hTml，返回正常，看来是windows服务器的可能性很高了(IIS默认支持大小写)
经检测发现，站点采用的是.net脚本，多年的渗透经验告诉我，面对大型站，直接检测主站是不靠谱的
Ok，看看他的分站：
Member server:member.xx.com
User server(商家)：user.xx.com
Images Server:pics.xx.com
Shop server:shop.xx.com
....
以及各类分站若干，部分重要站点采用Dns解析集群
可以看出，站点的分布紧紧有条，并且全站采用静态生成，由此推断内网架构应该比较复杂，并且很有可能各站的数据库是分别存放的...
开始尝试绕开重要站点 对一些比较偏僻的分站进行检测...
先前已经探测过,站点大部分采用.net脚本,对于.net 我个人比较喜欢检测一些特殊文件,比如.asmx,asmx一般用于站点的webservices服务,而国内大部分管理员在部署这个接口的时候,都没有对它做安全设置,这样就导致大堆的漏洞产生,曾经就是通过webservices拿下国内的快递公司宅x送
而对于一般的大型.net站点,管理员几乎都会配置一些webservice服务的...
通过google引擎 提交关键字:site:xx.com filetype:asmx inurl:webservices|webservice|service|services
经过一系列的搜索,筛选,再搜索
最后将目标锁定在user.xx.com/userservices
利用扫描器构造了一些字典开始扫描.asmx文件
运气不错,发现userservice.asmx,在地址后添加?wsdl,一个标准的webservices 接口出现了...
测试了几个参数,发现userid存在sqlinjection,过程就不说了,顺利拿到后台账号
那么,接下来就是寻找后台了
由于每个分站都是独立的,所以排除掉后台统一管理的可能,开始针对user.xx.com 进行后台扫描....
结果可想而知...
于是开始各种方法尝试找到后台登陆地址
最后在一次burpsuite抓包中发现页面调用了一个js/query.js文件,host为useradmin.xx.com
一个商家登陆的后台，顺利登陆之...
进去后发现后台很简陋，主要是处理一些商家旗下的产品以及推销管理等，在产品管理处，可以上传产品附件，禁用js后尝试上传xx.aspx,没想到竟然上传成功，查看附件，发现文件被强制改成201108042251_wooden.doc
看来是做了后缀处理了，但是仔细看发现文件尾部竟然有个wooden（商家名字)，看来在生成文件时，取值商家的用户名了
继续回到webservices,提交;update [admin] set username='test.asp;' where username='wooden'
接着进后台上传一个.doc后缀的小马，再看附件:201108042367_test.asp;.doc
iis的解析成功，小马顺利执行,至此，拿下webshell
进入webshell后，发现是台windows2003的服务器，尝试提权：
whoami 发现是.net默认用户，继承的自然是users组了
列了下服务,发现服务器开启了apache,要知道,win下的apache默认继承的是system权限,很好,立即copy个php马到apache,hosts目录
system到手,能做的事就很多了,ipconfig /all 发现服务器处于内网
net view发现若干服务器
net time /domain 返回
找不到域 WORKGROUP 的域控制器。
请键入 NET HELPMSG 3913 以获得更多的帮助。
看来目前所处的网段里并没有域存在
依次ping了下 net view里的服务器,
存在
10.10.2.*
10.10.4.*
10.10.10.*
等若干网段,看来内网构造还是比较复杂
而自己所处的网段ip为 10.10.10.106
为了方便操作,反弹了个终端回来,并且开启aspnet用户,提升为administrators组
登上终端的第一件事就是查看系统日志...
在渗透中,系统日志可以告诉入侵者很多事情,例如管理员的日常操作以及如何管理员服务器等,通过分析日志发现10.10.2.13 这台服务器经常连接此服务器,并且使用的是super_user用户
在无域控制,仅仅是内网的情况下,管理员为了方便管理终端,一般会用几种方法:
1,为每个终端设置不同的用户,然后用文件记录起来
2,设置一个通用管理软件,例如(remote desktop),里面会存储着各个终端的账号密码
3,设置一个通用用户,账号密码一致以方便管理
对的,从net user返回的情况来看super_user分别处于administrators users组
那么很有可能这个super_user就是第三种情况,抓取hash后破解出了super_user的密码,接着尝试登陆2.13
输入账号密码后,发现是台windows2008服务器,并且已经存在2个会话...
从这里可以看出先前第三种情况的可靠性比较高,而且管理员活动频率较大...
尝试点开一个会话进入桌面,结果 提示:请等候 System Event Notification Service
一开始以为是event service在响应,于是挂着等他进入,结果2跟烟下来,仍然如此,猜测有可能是system event服务崩溃了,导致无法响应...
解决的办法有很多,例如停止event service,重启计算机,但是,就目前的情况来看,要实现这些比较麻烦...
而event service应该是由于super_user保持会话而产生的括机现象,那么,只要注销了当前用户的会话,自然的，event service就不会捣乱了
提交net use \\10.10.2.13\ipc$ "xxxxxxx" /user:super_user
接着net view \\10.10.2.13
共享了sql目录
net use z: \\10.10.2.13\sql
在z:盘 创建一个.bat文件 内容为 command>z:\1.txt,再通过at命令来让脚本执行,这样一个基本的cmdshell 就有了...
鄙人更推荐以上方法来执行cmd,当然,也可以用opentelnet来执行cmdshell,但是,在ipc$中,以上方法继承的是system权限,而通过opentelnet等工具来连接的,继承的仅仅是administrators组,在一些高端策略部署的服务器中,前种就突出了他的优势
在query user后 尝试logoff注销super_user
可是,意外的情况发生了,a.bat执行logoff 2>z:\1.txt 发现1.txt并没有被创建,那么也就是说语句并没有执行？按道理，logoff 执行后，命令返回空值，1.txt内容为空，可是1.txt并没有创建，那么，有可能的情况只有logoff 执行失败，或拒绝访问。。。
看来管理员做了安全策略了，接着尝试tsdiscon命令，tsdiscon 2>z:\1.txt, 执行后，1.txt创建，看来命令执行成功了，mstsc /z:10.10.2.13 /console
顺利登陆...
在桌面发现一个服务器管理员软件，xxxx云管理，里面详细记载了整个内网的结构,各服务对应的ip,例如web对应10.10.10.x data对应10.10.2.x等等，以及一些应用的监控，可惜无法直接控制服务器，不过已经确认了主站和数据库等一些重要服务器的ip地址了...
写了个net use的bat脚本 用户为super_user，开始批量确认用户，结果发现，极大部分服务器都可以正常登陆，其中包括了:
member.xx.com
user.xx.com
shop.xx.com
以及几台数据库服务器...
已经没有继续渗透的必要了，删日至闪人，给管理员丢了封email
至此，渗透完毕..
留言评论（旧系统）：