testfire.net 网站渗透记录

testfire网站由IBM公司发布,旨在证明IBM产品在检测Web应用程序漏洞和网站缺陷方面的有效性,网站不是真正的银行网站,所以可用来做渗透测试练手的地方,也就是咱们俗称的“靶场”。但前提是必须把握测试范围,像DNS服务器、C段主机等这类就必须剔除在外,只能针对靶场所涉及的直接资产范围内进行练习。下面将此次渗透的过程记录如下:

一、信息收集

1、IP地址

2、子域名

3、后台搜索

通过 搜索引擎、御剑 找到了几个网站路径,包括 /pr、/docs、/bank、/admin、/manager 其中比较有价值的是:发现了/bank 能跳转到用户登录页面、/manager能跳转到后台登录页面。

4、服务器信息

a、操作系统

通过 PING-TTL法 来判断服务器操作系统,其原理简单来说:每个操作系统对TTL值的定义都不同,比如:

WINDOWS NT/2000 TTL:128、UNIX TTL:255 ……

操作系统的TTL值一般不会去修改,这就有了这样的方法,通过ping的回显TTL值,来判断对方是什么操作系统。

本地 Ping测 发现回显TTL是105,也许会有这样的疑问,从128或者255降到105都是可以的,这时该如何判定?此时就可以使用 tracert 工具,来确定损耗值,因此也确定了是从128降到105。另外,结合上面 多地Ping 的结果,大体可以判定是 Windows系统。

b、中间件

获取中间件的信息,最基本的思路是通过抓服务器的回包来判定,但此时只能看到 Server: Apache-Coyote/1.1 ,无法得到具体的版本信息。

另一种方法是通过报错的方式,如果服务器没有做相应的加固工作,此时将会暴露中间件版本信息,可以从下图看到服务器用的是Apache Tomcat/7.0.92

另外,demo.testfire.net 这几年经历了很多,通过情报网站的历史数据得知,这几年从 Windows-IIS 6.0 --> Debian-Apache 2.2.22 --> Windows-IIS 8.0 --> Windows-Tomcat 7.0.92

5、端口服务

使用 nmap 探测到服务器只开启了 80、443 两个端口,另外还结合了各种探测工具,后来证实了这个事实,看来只能从Web应用渗透入手了。

小结:目标 demo.testfire.net 服务器地址:65.61.137.117,开启了80 HTTP、443 HTTPS服务,服务器信息:windows-Apache Tomcat/7.0.92。

二、Web应用渗透

1、弱密码

顺着刚才上面的思路,进入用户登陆界面,发现没有验证码机制,那么此处可以用弱密码库来爆破管理员账号密码。但随手手测几次之后,发现 admin/admin 能直接登录。

管理员用户功能不是很多,主要包括可以管理用户(更改管理员密码、创建用户)、信息查询(可以尝试进行SQL注入)、转账功能(此处无二次验证功能,在实际网站中,敏感业务操作设计应引入二次鉴权机制)。

接下来,尝试爆破一下后台登录账户密码......

2、XSS

回到用户主页面,浏览网站过程中,首先测试了几个输入框入口,其中 搜索、用户反馈 均没有对输入进行限制,因此发现了XSS漏洞。

通过XSS漏洞,可以获取用户 Cookie 等信息,以实现进一步渗透。

如果是存储型XSS,那么还可以通过设置钓鱼登录框,将用户填写的账号、密码表单信息发送到攻击者所指定的网络位置。

当然,XSS的运用多种多样,还记得早期新浪微博爆过XSS漏洞,攻击者利用存储型XSS漏洞和社会工程方法,吸引用户进入漏洞页面,一旦进来就会触发脚本,自动给攻击者指定的微博点赞,瞬间将微博刷到榜单前列。

3、任意文件读取

继续浏览网站,发现进入每个页面前其实都是通过

这种直接嵌接资源文件名的方式提交数据,那么猜想此处可能存在 任意文件读取 漏洞。简单测试之后,爆出了网站 web.xml 配置文件。如果文件目录下有更多的敏感信息,那么危害会更大。

如果能读取网页源码,那么通过代码审计应该能发现更多问题,尝试读取网页源码,比如login.jsp,成功定位到 ../login.jsp 就在根目录。由于是Tomcat JSP架构,文件访问对大小写敏感,曾爆过文件读取漏洞,如果访问 ../login.JSp ,系统将不会直接解析login.jsp文件内容 ,而是以文件下载的方式提示下载源码,但这里多次尝试无果。

4、不安全HTTP方法

顺便提一下,在用 Burp 测试过程中,发现服务器允许 PUT、DELETE 等不安全的HTTP方法,Tomcat 7 可是爆过相关的任意文件上传漏洞的,因此如果能直接 PUT jsp文件,那么能直接拿到 webshell,不过多次尝试发现服务器对不安全方法还是禁止状态,显然管理员做了相关的加固工作。

5、文件上传

在反馈信息页面抓了个包,发现所提交的数据将会保存到 comments.txt 文件内,如果没有对输入内容进行有效的限制,那么这里将会是个高风险的文件上传漏洞。

尝试修改文件内容为一句话 JSP webshell ,文件名为 evil.jsp,发现能成功提交,但比较遗憾的是未能定位到文件访问路径,由于是测试网站,甚至怀疑这里并没有做实际的保存工作,而只是返回了结果信息。

6、SQL注入

防止SQL注入,最有效的方法就是限制输入、参数化传递 用户提交的数据,显然这里并没有进行有效防护,测试发现登录页面存在SQL注入漏洞

这里没有回显,也不是报错型注入,尝试使用DNSlog的方式回显我们需要的信息,但可能权限不够,导致无法将数据打到DNS服务器,但可以采用效率较低的盲注。

7、CSRF

CSRF造成的越权问题,也是不可忽视的,测试过程中发现此系统存在CSRF漏洞,能使得低权限的 Test 用户能像管理员查阅其它用户账户历史,甚至发起转账操作。稍演示一下,首先利用SQL注入漏洞登录 Test 用户,可以发现此时不能查询用户账户功能。

使用 Burp 抓包,然后篡改报文,查询某账户情况。

将篡改后的报文提交到服务器,可以发现已能成功返回查询的账户信息。

大概记录下来的就是这么多,如果有发现更多坑或者文章问题的朋友,还请不吝赐教,谢谢。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190121G0M8UQ00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券