Leave a comment (3) 作者:adwin

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

 

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

 

目标机器:

外网地址:211.211.211.11(前三段无情打码)

内网地址:10.10.10.67

 

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

外网地址:211.211.211.228

内网地址:202.xx.xx.xx(下边会提到)

 

事件背景交代完毕!

 

author:adwin

blog:http://www.okadwin.com

from:Silic http://silic.org

 

首先目标机器有外网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上的账户,啥也不说了,赶脚离目标已经只有一步之遥了,似乎胜利就在眼前了!

分享到:

评论列表:

屠龙
2014-05-24 09:03
高手啊
李若蟾
2014-08-24 22:10
很有用的知识啊
不记得了
2018-11-10 10:48
骚年,以前的基友都去哪了,貌似被暴风雨袭击了,

我也说两句 »