刚才搞到一台机器，虽然没用多长时间，但是过程也还算比较精彩，就寻思着发出来给大家分享，由于没什么特殊的部分，文章也是成功之后才写的，截图就不上了（其实主要原因是排版插入图片太费事），读者请自行脑补截图。

描述事情经过之前先大概描述一下处境吧

目标机器：

外网地址：211.211.211.11（前三段无情打码）

内网地址：10.10.10.67

已经获取到权限的一台机器A：

外网地址：211.211.211.228

内网地址：202.xx.xx.xx（下边会提到）

事件背景交代完毕！

author：adwin

blog：http://www.okadwin.com

首先目标机器有外网WEB，但是直接入手机会不大，几乎不太可能，所以选择先进其内网查探一番，看看有什么收获没有（一般来说，对内部网络的安全重视程度普遍不足，可能潜意识会认为内部网络是安全的），so，几天前我也忘记了怎么拿到了一台内网机器A，其配置很诡异，很多系统该有的程序都没有（比如ping就没有），只能通过ipconfig命令查看到被配置了一个202.xx.xx.xx的网络地址，显然这个地址和其内网地址不同，但却又完全可以访问10.10.10.0这个网段，而在这台机器上又没有发现任何蛛丝马迹，想要在这台机器上嗅探也是不可能，所以只好想办法日掉内网的另外一台配置正常的机器。

通过外网的踩点，发现其外网IP为211.211.211.249的机器B存在一个dedecms，版本号是2012年的，有戏。然后很自然的，送给cmd5一毛钱就拿到了一个webshell，至于这个过程就不写了，虽然中间遇到一点小插曲，但是也很快就结束了。

通过webshell发现处于IIS6.0环境下，有MySQL的root，MySQL版本是5.1，select @basedir看到了数据库的目录，不过很遗憾，没有浏览这个目录的权限，更别说创建plugin目录了，不过这个PHP webshell可以执行命令，发现是network_service权限，可以浏览的目录似乎只有当前的web目录，这种情况很常见，一般来说上个asp的webshell有可能会浏览到一些其他的目录，而IIS6一般来说不会不解析asp，so，传了个asp的webshell。

通过asp的webshell确实可以浏览的目录多了一些，不过查探一圈之后似乎也没有什么发现，马上就要死心了，这台机器估计很难提下来了，不过习惯性点了几下webshell自带的目录，肯定要是要先看看C:\Program Files\这个目录有没有权限的，这一点很关键。

果然，一个名称为Apache Software Foundation的目录映入眼帘，看到Apache立马想到权限肯定会比IIS高（国内大环境你懂的），so，点进去发现有两个目录，一个是tomcat6.0一个是tomcat7.0。一台机器装了两个tomcat？算了，先看一下里边的内容。

翻遍了这两个tomcat的目录和配置文件，发现7.0里边是默认的示例站点，运行在8009端口，似乎没有其他站点，6.0里边倒是有几个站点，运行在8080端口，有strust2。

别闹，这样真的不好，于是赶紧看一下8080端口，却发现访问不到？telnet也连不到，于是想到可能是因为在内网的原因，可能是内网只映射了80端口出来，8080端口的站或许只允许内部网络访问。

嗯哼？我好想似乎是发现了什么？对啊，前几天不是搞到一个可以访问内网的机器么（虽然严格上来说IP不在内网），于是登陆肉鸡，操起远控，端口转发到肉鸡上，远程连接，又一次看到这个2B桌面，打开浏览器，tracert了一下，发现webshell所在的内网机器B的内网IP地址是10.10.10.249，OK，迫不及待的访问了一下http://10.10.10.249:8080，很容易找到了login!login.action，满心欢喜的以为这下可好了，赶紧去机器A上下载了一个strust2的利用工具。

就像看AV刚到高潮，正脱下裤子准备撸一发的时候，突然断电了，辣种赶脚！啥也不说了，strust2没起作用啊！心一下凉了大半截。不过还好我们有MySQL的root，这个jsp的web也是有后台的吗，我们从数据库中找到管理员的密码，然后从jsp的网站登录后台，说不定可以上传呢？这就像断电之后准备把车上的电瓶拆下来接在电脑上继续看差不多，死马当活马医了。

不过遗憾的是，jsp有两个站，其中一个用的是SQL Server数据库，显然我没找到数据库的连接字符串在哪，另外一个在MySQL中的确找到管理员账户了，但是尼玛后台登陆地址竟然500错误了！啥也不说了，这根本行不通。这个时候看起来好像是真的没什么希望了，不过既然我们asp的webshell可以读文件，就再转哟转哟吧。转了几圈，别的地方更没有希望，还不如这个tomcat呢。

在机器A上访问B的jsp站，手贱看了一眼8009端口（显然是tomcat的默认界面，不用想都知道），不过这个时候的确有一个新的想法诞生了：tomcat不是有管理界面可以部署war嘛！于是在asp的webshell下看了看tomcat7.0的tomcat-users.xml，显然用户那部分被注释掉了，也就是说，在tomcat anager的401验证那里，不管你输入什么都是错误的，所以这个管理界面是永远也进不去的（tomcat7.0默认是把那部分注释掉的），这一点其实之前也料到大半，不过可喜的是我们还有一个tomcat6.0啊，于是找了tomcat6.0下的conf目录下的tomcat-users.xml，看到内容后顿时感动哭了！

<tomcat-users>
  <role rolename="manager"/>
  <role rolename="admin"/>
  <user username="admin" password="！@#￥%……&……*（*）（）" roles="admin,manager"/>
</tomcat-users>

密码被无情的打了个码，原密码那叫一个复杂。。。这尼玛啥也不说了，真心是天无绝人之路，往后就不说了，直接从机器A访问机器B的tomcat manager界面，部署一个war上去，直接获得webshell，果然不出所料，执行whoami得知获取system权限，去尼玛，赶紧添加用户，远程桌面走起，上远控！

然后呢？这台机器B就好多了，方方面面都不错，扫了一下内网存活的机器，还真不少，尝试嗅探成功，十分钟之内搞到了几个HTTP上的账户，啥也不说了，赶脚离目标已经只有一步之遥了，似乎胜利就在眼前了！