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 抓包，然后篡改报文，查询某账户情况。

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

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