JSP网站服务器被入侵后的追踪溯源方法与步骤

如今，很多电商网站都采用JSP技术搭建，数量庞大。但坦诚地说，这类网站的安全性真的足够可靠吗？面对层出不穷的黑客攻击与病毒威胁，JSP服务器究竟比其它服务器更坚固，还是更容易成为攻击目标？不久前，我受朋友委托，对他们托管的三台服务器进行了渗透测试，结果发现了一些JSP网站常见的薄弱环节。

入侵测试第一步：信息收集与端口扫描

扫描是渗透测试的起点——它能帮你快速摸清目标系统的资产状况，运气好的话，还能直接发现一些现成的安全漏洞，为后续攻击指明方向。

朋友的三台服务器中，两台运行Linux系统，一台是Windows系统。路由器后面还部署了一台Cisco PIX 525防火墙，只对外暴露了80、25、110等常规端口。从检测结果来看，PIX的过滤规则配置得相当严密，基本没有留下多余的服务端口。进一步观察发现，目标网络中的主机都通过地址转换对外提供服务，内部使用的全是192.168.*.*这样的私有地址段。

先别想太多，找一款扫描工具探探虚实。我用X-Scan对这几台主机进行了外部端口扫描，分析生成的报表后，发现其中有一台运行着Tomcat服务器——毫无疑问，它就是负责解析JSP文件的核心设备。

小知识：

Tomcat是一款开源的Web服务器，支持Servlet和JSP，跨平台且免费。像eBay、Dell这样的知名网站，都曾经（或正在）使用Tomcat来执行Java相关的服务。

既然直接攻击端口行不通，那就只能从Web服务入手了。我检查了TCP 80端口对应的服务，发现新闻搜索功能居然挂在8080端口上。输入http://202.103.*.168:8080/，直接弹出了系统管理登录页面。试着用“test/test”作为用户名/密码提交，页面显示认证成功，但无法跳转到下一个页面——显然，这个账号的权限不足。

专家支招： 扫描是攻击者的第一步，也是防守方最容易暴露自身弱点的环节。应对方法之一是架设蜜罐——让系统看起来漏洞百出，吸引攻击者上钩；或者反过来，伪装成毫无破绽，让对方无从下手。

入侵测试第二步：漏洞试探与利用

扫描没有挖出有价值的信息，那就只能靠硬试各种已知漏洞了。这种方法虽然略显笨拙，但有时能撞上大运，让攻击意外地向前推进。

首先尝试JSP大小写问题。JSP对大小写非常敏感：Tomcat只认小写后缀“.jsp”，如果你把文件名写成“.JSP”，Tomcat就会把它当成普通文件直接提供下载。我试了几次，没有成功——管理员大概已经打过补丁了。

接着，我注意到大多数JSP应用在根目录下都会有一个WEB-INF目录，里面通常存放着JavaBeans编译后的class文件。如果这个目录的权限设置不当，所有class文件就相当于公开了。更关键的是，使用JAD这类反编译工具，能把class文件还原成几乎原样的Java源码，连变量名都不会改变。要是当初程序员直接把数据库用户名和密码硬编码在代码里，那反编译后就能直接拿到数据库的访问凭证。问题是——怎么才能获取这些class文件？

Tomcat默认在/admin目录下提供了一个管理后台，访问权限很宽松。我试着输入http://202.103.*.168/admin/，管理目录立刻展现在眼前。默认用户名是admin，密码为空——登录失败。又换了几个常见密码，还是不行。

另一个容易被忽略的问题是：Tomcat默认开启了目录浏览功能。当请求的资源对应到一个缺少默认首页（如index.jsp）的目录时，Tomcat不会返回404错误，反而会返回一个HTML格式的文件列表，把整个目录的目录结构完全暴露出来。

想到这一点后，我立刻翻出X-Scan生成的报表，在“安全漏洞及解决方案”一栏里找到了几个可能有CGI漏洞的目录。把其中一个目录路径输入浏览器地址栏，结果如图1所示——果然，文件列表出来了！

500)this.width=500" title="点击这里用新窗口浏览图片" />

目录里列着一堆典型的JSP文件和JS文件。大喜之下，随便点一个文件，右键选择“用FlashGet下载全部链接”，整个目录的文件就全部被拖到了本地。

上一页12 下一页 阅读全文