TOMCAT安全测试概要

一、前言

Web安全中很重要的一个部分就是中间件的安全问题,而中间件的安全问题主要来源于两部分,一个是中间件本身由于设计缺陷而导致的安全问题,另一个就是默认配置或错误配置导致的安全风险。
本文作为逢魔安全团队中间件安全风险系列对外公开文章将详细对Tomcat的常见安全风险进行分析归纳。

二、版本管理

类似于Tomcat这种软件项目官方一般都维护了多个版本分支,一般新的产品特性会被更新在最新的大版本当中,而类似于修复bug及漏洞这种就会在旧版本的分支当中得以更新。这就允许开发人员在不破坏生产环境的情况下软件更新。

比如你正在使用的是Tomcat
5.5.26,那么你应该在5.5分支中寻找新的版本(例如5.5.27),升级到这个bug修复版本。当然如果在性能或功能特性上没有新需求时,也是不用升级到tomcat6.0的。

因此,对于Tomcat的使用者来说应该密切关注Apache
Tomcat官方的安全漏洞和新版本的发布通知并进行及时升级更新。

http://tomcat.apache.org/security.html

三、运行环境

首先我们必须保证Tomcat不能以高系统权限去运行,比如Linux下的root用户和Windows下的Administrator用户或用户组。我们需要为Tomcat进程创建一个专用的用户,并为该用户提供运行所需的最低系统权限,包括我们需要根据业务需求去详细分配Tomcat涉及的安装目录和应用目录文件夹的读、写及执行的权限。这样一来我们就能极大提高攻击者的攻击成本,比如攻击者通过其他漏洞或缺陷所获得的权限只能是tomcat权限而不是系统最高权限,若想要进一步攻击则只能进行提权操作。

另外我们还需要保证tomcat系统用户的密码口令符合一定的复杂度要求甚至是禁止远程登录。

四、安全配置

4.1 Example Applications

Tomcat安装后需要删除CATALINA_HOME/webapps下的所有文件 (ROOT, balancer,
jsp-examples, servlet-examples, tomcat-docs,
webdav),以免信息泄露和其他的安全风险。比如示例servlet和JSP的“/
examples”目录,会话session servlet(安装在/ examples / servlets / servlet /
SessionExample)允许进行session操作,因为session是全局的,所以这个servlet会带来很大的安全风险,因为攻击者可能通过操纵会话来强制成为应用系统的管理员。但这种基本上只有在一些很老的不安全的系统中才有可能出现。

4.2 Manager Console

从CATALINA_HOME/webapps中删除host-manager和manager后台管理程序。但如果需要在不重新启动Tomcat的情况下重新部署或部署新的web应用时可以选择保留,但需要一个足够强的管理口令,在tomcat-user.xml中配置。

Tomcat Manager 4种角色的大致介绍(下面URL中的*为通配符):

  • manager-gui:允许访问html接口(即URL路径为/manager/html/*)
  • manager-script:允许访问纯文本接口(即URL路径为/manager/text/*)
  • manager-jmx:允许访问JMX代理接口(即URL路径为/manager/jmxproxy/*)
  • manager-status:允许访问Tomcat只读状态页面(即URL路径为/manager/status/*)

Tomcat管理后台使用BASIC认证,在http请求头中有一个Authorization字段,账号密码为“账号:密码”的方式经过base64编码。

常见的弱口令:

4.2.1 manager-gui

Tomcat管理控制模块中最常见的就是manager-gui,访问路径为/manager/html,具有部署应用的功能,恶意攻击者常使用该功能部署war文件的webshell后门程序

选择需要部署的war文件点击deploy后即可完成部署,可以在应用列表中点击相应的应用名完成webshell访问

另外在某些场景下也可能用到服务器的本地部署,若一个web应用结构为\WebApp\AppName\WEB-INF\*,利用控制台进行部署的方式如下:进入tomcat的manager控制台的Deploy
directory or WAR file located on server区域——在Context
path中键入”XXX”(可任意取名)——在WAR or Directory URL:键入\WebApp\AppName(表示去寻找此路径下的web应用)——点击deploy按钮。

然后在%Tomcat_Home%\webapps路径下将会自动出现一个名为XXX的文件夹,其内容即是\WebApp\AppName的内容,只是名字是XXX而已(这和tomcat的自动部署方式一致)

4.2.2 manager-script

Tomcat manager-script的远程部署应用的功能也可以被恶意攻击者利用,通过以下命令请求即可完成应用后门部署

通过/list可以查看已成功部署的应用

另外也有大量敏感信息泄露的风险

攻击者关注的其他页面还有:

http://localhost:8080/manager/text/resources[?type=xxxxx]

http://localhost:8080/manager/text/sessions?path=/examples

http://localhost:8080/manager/text/expire?path=/examples&idle=num

http://localhost:8080/manager/text/findleaks[?statusLine=[true\|false]]

http://localhost:8080/manager/text/sslConnectorCiphers

4.2.3 manager-status

manager-status主要是一些只读的tomcat运行状态信息,除了信息泄露外五其他可操作行的风险。

4.2.4 manager-jmx

manager-jmx为Tomcat JMX代理接口,是一个小型的servlet,它可以按以下列格式接收JMX
Query、Get、Set和Invoke命令:

  • HTTP://{host}:{port}/manager/jmxproxy/qry= YOURQUERY
  • HTTP://{host}:{port}/manager/jmxproxy/set = YOURCOMMAND

当我们默认直接访问tomcat提供的JMX接口时(http://localhost:8080/manager/jmxproxy/?qry=)会出现所有的MBeans

如果想要具体的MBeans只需要将其name后面的值放在url的后面实际的命令是使用特殊字符的URL编码以标准JMX语法编写的,恶意攻击者可以通过该接口读取tomcat用户密码甚至添加用户

危害最大的是攻击者可以通过jmxproxy执行任意jsp代码导致远程代码执行,方法如本文JMX
Service小节中所讲的方法一致,通过invoke命令调用rotate函数将访问日志备份到指定文件的方法,最终执行任意代码。

4.3 admin Manager

Tomcat
5及之前版本存在admin模块,提供了类似于Weblogic、Websphere等商用应用中间件的管理功能,可以方便的实现对Tomcat服务、部署的应用程序、连接池以及其他资源的管理,但不能用来部署应用程序,Tomcat
Admin功能作为一个独立的模块,从5.5版本开始作为一个可选模块,在默认情况下是不安装的,需要进行手工安装,通过/admin路径访问控制台

在admin后台恶意攻击者除了获取服务器信息外,主要利用的两个恶意操作是磁盘文件读取和添加tomcat管理账号。首先磁盘文件读取是通过Service->host->actions->Create
New Context建立虚拟目录,Document
Base填你想浏览的目录,比如c:\,Path可以自定义,例如/formsec,然后直接http://ip/formsec
就可以看到c盘内容。

另外在User Definition中可以对Tomcat的用户进行管理,比如添加账号及权限等。

4.4 JMX Service

Java Management Extension
(JMX)服务用来远程监视和管理的Tomcat服务器,如果对外开放并且是空口令或者弱口令的话会产生很多安全问题,通过Java
Remote Method Invocation
(RMI)进行交互。该服务在Tocmat中默认是不开启的,需要对Catalina.bat/Catalina.sh做一些简单更改

此JMX服务可以配置为支持身份验证,但默认情况下未启用。启用身份验证时(如始终建议的那样),其授权模型允许访问属于只读或读写角色的两个不同用户。

如果您需要授权,添加并更改此项:

  • Dcom.sun.management.jmxremote.authenticate=true
  • Dcom.sun.management.jmxremote.password.file=../conf/jmxremote.password
  • Dcom.sun.management.jmxremote.access.file=../conf/jmxremote.access

编辑访问授权文件\$ CATALINA_BASE / conf / jmxremote.access:

编辑密码文件\$ CATALINA_BASE / conf / jmxremote.password:

从上面可以看出,jmxremote.access文件包含两个用户名(monitorRole和controlRole)及其相关角色。然后,jmxremote.password将这些用户的密码设置为tomcat。

始终建议对此服务启用身份验证,并且使用复杂口令。

具体请查考:

http://tomcat.apache.org/tomcat-8.0-doc/monitoring.html\#Enabling_JMX_Remote

测试方法

可以通过nmap来发现开启JMX服务的端口,但nmap无法确认是否开启认证

远程访问该端口服务可以使用jdk自带的jconsole或者1.6出来的jvisualvm,

选择远程进程输入jmx服务的ip地址和端口进行连接,其中涉及大量的tomcat服务器敏感信息,包括管理控制台弱口令

当然也可以进行一些控制操作,比如在MBeans–>Catalina—>WebModule—>应用程序名称—>Operations—>stop
关闭指定的应用程序(start启动)

如果有写权限的tomcat用户可以写入后门恶意代码等,其中的
Catalina->Valve->localhost->AccessLogValve->Operations表明rotate函数用于将Tomcat访问日志的副本保存到服务器上的文件中。

但是这里有个缺陷,newFileName定义的文件名可以使用任意目录和文件名后缀,利用日志备份拿webshell的思路,我们可以将含有恶意代码的请求日志备份在web应用目录下获取webshell

首先看一下如何获取应用路径,VM概要中存在tomcat的所在路径,配合webapp列表就可以构造出来

因此在此例中我们可以将日志备份在/usr/local/tomcat/webapps/100/formsec.jsp,拿到webshell。

注意在调用rotate时是不能创建目录的,如果文件存在不会覆盖原文件内容,也不会新建文件。

如果tomcat运行在windows服务器中,并且tomcat是以域用户账号运行的,那么newFileName定义为\\192.168.5.1\test则可能捕获到用户hash进行破解

还有一个可以被黑客恶意利用的操作是listSessionIds(),可以用于劫持除了tomcat
manager应用外的每个web应用程序中用户的jsessionid,该操作同样需要写权限,位于

Catalina->Manager->[ApplicationName]->Operations->listSessionIds()

4.5 AJP Listenner

Tomcat最主要的功能是提供Servlet/JSP容器,尽管它也可以作为独立的Java
Web服务器,它在对静态资源(如HTML文件或图像文件)的处理速度,以及提供的Web服务器管理功能方面都不如其他专业的HTTP服务器,如IIS和Apache服务器。因此在实际应用中,常常把Tomcat与其他HTTP服务器集成。

Tomcat有两个连接器,一个连接器监听8080端口,负责建立HTTP连接。在通过浏览器访问Tomcat服务器的Web应用时,使用的就是这个连接器。第二个连接器监听8009端口,负责和其他的HTTP服务器建立连接,在把Tomcat与其他HTTP服务器集成时,就需要用到这个连接器。

(图片转自:《Tomcat Port 8009 与AJP13协议》)

AJP是为Tomcat与HTTP服务器之间通信而定制的协议,能提供较高的通信速度和效率。在配置Tomcat与HTTP服务器集成中。

在某些场景下如果8080因防火墙等原因被限制访问但是开放了8009,就会被攻击者恶意利用,用apache等服务器进行集成,绕过8080端口的访问限制

使用ajp进行集成配置

注:参考https://diablohorn.com/2011/10/19/8009-the-forgotten-tomcat-port/

4.6 Debug Mode

Tomcat在进行远程调试时需要开启debug模式,在调试器和JVM之间使用JDWP进行通信。Tomcat的debug默认是不开启的,需要手动配置,默认端口为8000

debug模式对外开放非常危险,攻击者可直接通过JDWP执行系统命令

五、安全漏洞

5.1 CVE-2017-12615& CVE-2017-12617

CVE-2017-12615 Tomcat远程代码执行漏洞由iswin发现。其实算是绕过PUT上传限制,可上传jsp可执行文件,漏洞关键点在tomcatweb.xml文件中修改配置org.apache.catalina.servlets.DefaultServlet的参数readonly默认值为false时,即允许进行delete和put操作。

一般情况下,tomcat不允许put上传jsp文件,但在tomcat7.0.0 to
7.0.79版本中,存在一处缺陷,windows环境下可通过NTFS文件数据流“::DATA”的方式来绕过进行jsp文件的上传,以及通过“::\$INDEX_ALLOCATION”来创建文件夹等,这部分知识可以参考https://msdn.microsoft.com/en-us/library/windows/desktop/aa364404(v=vs.85).aspx

后续我和xfk及xxlegend在对该漏洞进行fuzz的时候发现windows环境中“test.jsp.”、”test.jsp%20”、”test.jsp/“等方式均可实现上传并能成功解析执行,而重要的是这几个poc是无版本限制。当然我们也对linux平台的各版本tomcat进行了相同的fuzz操作,发现“test.jsp/”也可以成功上传并解析,因此该漏洞也就影响了Tomcat全版本,这也就是后来的CVE-2017-12617。

5.2 CVE-2017-12616

该漏洞与CVE-2017-12615同时被发现,并且利用方式也类似,如果Tomcat在conf/server.xml配置了VirtualDirContex参数来挂载虚拟目录,访问者通过构造请求访问jsp等web资源时,Tomcat就会将VirtualDirContext提供支持资源中相对应文件的内容以文本形式返回,造成源代码泄露。

对于Windows服务器使用test.jsp%20和test.jsp::\$DATA获得源代码,但无法通过test.jsp/获取源代码,不影响linux系统。

5.3 CVE-2016-8735

这个漏洞实质还是JMX反序列化漏洞,Tomcat同样也用了JmxRemoteLifecycleListener这个监听器,但是Tomcat在Oracle修复这个漏洞后自己没有及时更新,导致了反序列还依旧存在。

影响版本:

远程命令执行效果如下

关于该漏洞的具体复现可以参考我之前的一篇文章

http://reverse-tcp.xyz/2016/12/10/Apache-Tomcat-Remote-Code-Execution(CVE-2016-8735)

  • Tomcat
  • Penetration Test

 

作者:逢魔网络安全实验室