Tomcat远程代码执行漏洞——CVE-2016-8753 /

2018-10-27 本文已影响0人 Evil_cosey

Tomcat远程代码执行漏洞——CVE-2016-8753

前言

站在甲方公司安全的角度考虑，Tomcat是一种在实际中常被采用的服务器，所以我们针对该漏洞从原理、危害、利用条件以及限制方面对该漏洞进行分析，并着重考虑甲方公司在面对这个漏洞时应该做些什么。

漏洞背景

Tomcat是运行在Apache上的应用服务器，支持运行Servlet/JSP应用程序的容器。Tomcat也可以看作是Apache的扩展，不过实际上Tomcat也可以独立于Apache运行。

漏洞描述

Oracle修复了JmxRemoteLifecycleListener反序列化漏洞(CVE-2016-3427)。部分Tomcat用户可能使用了JmxRemoteLifecycleListener这个监听器，但是由于Tomcat并没有及时升级，所以存在这个远程代码执行漏洞。

受影响的版本主要有：

Apache Tomcat 9.0.0.M1 to 9.0.0.M11
Apache Tomcat 8.5.0 to 8.5.6
Apache Tomcat 8.0.0.RC1 to 8.0.38
Apache Tomcat 7.0.0 to 7.0.72
Apache Tomcat 6.0.0 to 6.0.47

漏洞利用

测试服务器版本：Tomcat版本8.0.36

在Tomcat/conf/server.xml中添加catalina-jmx-remote.jar包，修改catalina文件配置如下：

配置文件修改

需要注意一点在conf/server.xml中增加配置之后，可能会出现无法启动等现象，查阅log发现是java编译时找不到加载类：

log

这里需要将catalina-jmx-remote.jar和groovy-2.3.9.jar包放到lib目录下，并且修改CATALINA_OPTS的值，可参阅官方说明文档。

成功启动配置好的Tomcat后，通过上面添加的远程监听端口10001，构造通信包来执行远程代码calc.exe：

执行远程代码calc.exe

这里的通信包使用了ysoserial。

最后我们发现确实打开了服务器上的计算器程序：

命令生效

以上只是该漏洞的一个简单利用，通过这种方式，我们可以尝试构造其它语句来实现目标服务器的远程代码执行，例如：我们可以尝试为这个服务器添加一组账号，这里我们需要注意执行代码需要获得管理员权限。

远程代码执行

在服务器上查看发现确实添加成功：

代码执行成功

限制分析

通过对该漏洞的利用进行分析，我们发现上文中该漏洞起作用的关键无非两点：

1. 目标服务器中JMX必须是可远程访问的。
2. 目标服务器要启用JmxRemoteLifecycleListener包(默认情况下是不启用的)。

而此漏洞发布时在严重程度上被定义为Important，而非Critical，主要是因为采用此listener的数量并不算大，而且即便此listener被利用，通过JMX端口访问来实现的方式对攻击者来说也不是很有效。
那么对于一般的甲方公司来说，假设他们的服务器中部署有Tomcat，并且开启了listener这个监听类，同时考虑到JMX和Groovy的广泛应用性，那么服务器极有可能被攻击者通过这个漏洞来执行远程代码，从而拿到shell，造成巨大危害。

应对措施

面对这个漏洞，应有的应对措施是升级到不受影响的版本或者改变JMX密码认证方式等。

站在一个甲方公司的角度来说，我们首先要考虑这个漏洞是否对企业目前的安全状况造成了影响，这里针对漏洞利用的条件，我们可以通过查看nvt来检测JMX的使用情况，也可以通过查看server的配置表等关键信息来看服务器是否开启使用了这个监听类。Tomcat的默认是没有使用catalina-jmx-remote.jar包的，即使启用了一般也不太可能部署于公网来提供访问，所以该漏洞的影响范围可能比较受限。

当然如果公司没有用采用Tomcat用作服务器或者采用了Tomcat作为服务器却没有开启这个监听类，那么就不需要考虑这个安全问题。反之，可能出现的远程代码执行漏洞会严重影响到服务器的安全，需要引起高度重视，这里我们推荐公司稳妥起见，升级Tomcat到安全的版本。

不受影响版本:

Upgrade to Apache Tomcat 9.0.0.M13 or later(Apache Tomcat 9.0.0.M12 has the fix but was not released)
Upgrade to Apache Tomcat 8.5.8 or later(Apache Tomcat 8.5.7 has the fix but was not released)
Upgrade to Apache Tomcat 8.0.39 or later
Upgrade to Apache Tomcat 7.0.73 or later
Upgrade to Apache Tomcat 6.0.48 or later

另外如果由于服务器数量多，业务绑定紧密等不方便升级，我们也可以采用改变JMX密码认证的方式同样来避免安全问题的出现。

以下是可能会用到的补丁代码：

Diff of /tomcat/trunk/webapps/docs/changelog.xml

--- tomcat/trunk/webapps/docs/changelog.xml 2016/11/02 11:57:28 1767643
+++ tomcat/trunk/webapps/docs/changelog.xml 2016/11/02 11:57:36 1767644
@@ -97,6 +97,10 @@
StoreConfig component includes the executor name when writing the
 Connector configuration. (markt)
 </fix>
+ <fix>
+ When configuring the JMX remote listener, specify the allowed types for
+ the credentials. (markt)
+ </fix>
 </changelog>
 </subsection>

tomcat/trunk/java/org/apache/catalina/mbeans/JmxRemoteLifecycleListener.java

--- tomcat/trunk/java/org/apache/catalina/mbeans/JmxRemoteLifecycleListener.java 2016/11/02 11:57:28 1767643
+++ tomcat/trunk/java/org/apache/catalina/mbeans/JmxRemoteLifecycleListener.java 2016/11/02 11:57:36 1767644
@@ -264,6 +264,10 @@
serverCsf = new RmiClientLocalhostSocketFactory(serverCsf);
}

+ env.put("jmx.remote.rmi.server.credential.types", new String[] {
+ String[].class.getName(),
+ String.class.getName() });
+
 // Populate the env properties used to create the server
if (serverCsf != null) {
   env.put(RMIConnectorServer.RMI_CLIENT_SOCKET_FACTORY_ATTRIBUTE, serverCsf);
  @@ -328,7 +332,7 @@
   cs = new RMIConnectorServer(serviceUrl, theEnv, server,
   ManagementFactory.getPlatformMBeanServer());
   cs.start();
- registry.bind("jmxrmi", server);
+ registry.bind("jmxrmi", server.toStub());
   log.info(sm.getString("jmxRemoteLifecycleListener.start",
   Integer.toString(theRmiRegistryPort),
   Integer.toString(theRmiServerPort), serverName));

Tomcat远程代码执行漏洞——CVE-2016-8753 /