国内某大型购物网站的沦陷

编辑:文章得到热烈响应,在下非常高兴,感谢皇子的提醒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

至此,渗透完毕..

本文摘自雪域博客由网络安全攻防研究室(www.91ri.org) 信息安全小组收集整理.