tomcat中间件漏洞复现
Apache Tomcat文件包含漏洞CVE-2020-1938
一、漏洞描述
Tomcat是Apache开源组织开发的用于处理HTTP服务的项目，两者都是免费的，都可以做为独立的Web服务器运行。Apache Tomcat服务器存在文件包含漏洞，攻击者可利用该漏洞读取或包含 Tomcat 上所有 webapp 目录下的任意文件，如：webapp 配置文件或源代码等。
二、漏洞危害等级
高
三、影响版本
Apache Tomcat 6
Tomcat 7系列 <7.0.100
Tomcat 8系列 < 8.5.51
Tomcat 9 系列 <9.0.31
四、漏洞原理
tomcat默认的conf/server.xml中配置了2个Connector，一个为8080的对外提供的HTTP协议端口，另外一个就是默认的8009 AJP协议端口，两个端口默认均监听在外网ip。
tomcat在接收ajp请求的时候调用org.apache.coyote.ajp.AjpProcessor来处理ajp消息，prepareRequest将ajp里面的内容取出来设置成request对象的Attribute属性。可以通过此种特性从而可以控制request对象的下面三个Attribute属性
javax.servlet.include.request_uri
javax.servlet.include.path_info
javax.servlet.include.servlet_path
再通过控制ajp控制的上述三个属性来读取文件,通过操控上述三个属性从而可以读取到应用目录下的任何文件。
五、漏洞复现
开启apache服务
在webapp 配置文件或源代码等，修改文件方便确认是否成功
kali运行poc
六、漏洞修复
1.更新到安全版本
Apache Tomcat 7.0.100
Apache Tomcat 8.5.51
Apache Tomcat 9.0.31
https://tomcat.apache.org/download-70.cgi
https://tomcat.apache.org/download-80.cgi
https://tomcat.apache.org/download-90.cgi
或Github下载：https://github.com/apache/tomcat/releases
2.关闭AJP服务，修改Tomcat配置文件Service.xml,注释掉
3、配置ajp配置中的secretRequired跟secret属性来限制认证
Apache Tomcat 远程代码执行(CVE-2019-0232)
whh6tl 2020-07-25 18:44:57 151640
漏洞简介：
2019年4月10日，Apache Tomcat披露了一个漏洞，漏洞编号为CVE-2019-0232，该漏洞存在于启用了enableCmdLineArguments选项的CGI Servlet中,与JRE向Windows传递参数过程中的bug有关。成功利用此漏洞可允许远程攻击者在目标服务器上执行任意命令,从而导致服务器被完全控制。由于Apache Tomcat应用范围广泛，该漏洞一旦被大规模利用，带来后果将不堪设想
威胁类型
远程代码执行、提权
威胁等级
高
漏洞编号
CVE-2019-0232
受影响系统及应用版本
Apache Tomcat 9.0.0.M1 to 9.0.17
Apache Tomcat 8.5.0 to 8.5.39
Apache Tomcat 7.0.0 to 7.0.93
漏洞复现：
1、搭建环境
VMware 虚拟机 windows 7
JDK 1.8.0_73
Apache tomcat 9.0.13
2、复现步骤
首先安装JDK（我这里用的jdk_1.8.0_241）然后配置环境变量
下载符合版本的Tomcat安装包 传送门
下载JDK，准备配置环境
1、装jdk 随意选择目录，如果没有特殊要求直接默认完成安装即可
2、安装jre→更改→ \java 之前目录和安装 jdk 目录相同即可
3、安装完JDK后配置环境变量 计算机→属性→高级系统设置→高级→环境变量
4、系统变量→新建 JAVA_HOME 变量 。
变量值填写jdk的安装目录
我的路径是C:\Program Files\Java\jdk1.8.0_241
5、系统变量→寻找 Path 变量→编辑
在变量值最后输入 %JAVA_HOME%\bin;%JAVA_HOME%\jre\bin;
6、系统变量→新建 CLASSPATH 变量
变量值填写 .;%JAVA_HOME%\lib;%JAVA_HOME%\lib\tools.jar
7、检验是否配置成功 运行cmd 输入 java -version若如图所示 显示版本信息 则说明安装和配置成功。
8、在上述网址中下载Tomcat，下载好安装包之后，进入bin目录执行startup.bat启动tomcat。
9、访问http://localhost:8080
10、修改配置文件
首先修改apache-tomcat-9.0.13\conf\ web.xml
（1）将此段注释删除，并添加红框内代码。
enableCmdLineArguments
true
executadle
（2）将此处注释删除
11、然后更改 apache-tomcat-9.0.13\conf\ context.xml
添加privileged="true"语句 如下图
环境搭建完成！
12、在apache-tomcat-9.0.13\webapps\ROOT\WEB-INF目录下新建 cgi-bin 文件夹
在文件夹内创建一个.bat文件
Bat文件内写如下内容
@echo off
echo Content-Type: test/plain
echo.
set foo=&~1
%foo%
13、直接浏览器访问对应的cgi-bin下的bat文件（默认会将bat文件下载回来）
14、在后边追加系统命令：
此命令为调出计算机
漏洞复现成功！
2、修复建议
禁用enableCmdLineArguments参数。
在conf/web.xml中覆写采用更严格的参数合法性检验规则。
升级tomcat到9.0.17以上版本。
Tomcat反序列化漏洞(CVE-2016-8735)
参考：https://its201.com/article/qq_48985780/121418420
漏洞描述：
该漏洞与之前Oracle发布的mxRemoteLifecycleListener反序列化漏洞（CVE-2016-3427）相关，是由于使用了JmxRemoteLifecycleListener的监听功能所导致。而在Oracle官方发布修复后，Tomcat未能及时修复更新而导致的远程代码执行。
该漏洞所造成的最根本原因是Tomcat在配置JMX做监控时使用了JmxRemoteLifecycleListener的方法。
漏洞影响版本：
ApacheTomcat 9.0.0.M1 到9.0.0.M11
ApacheTomcat 8.5.0 到8.5.6
ApacheTomcat 8.0.0.RC1 到8.0.38
ApacheTomcat 7.0.0 到7.0.72
ApacheTomcat 6.0.0 到6.0.47
漏洞利用条件：
外部需要开启JmxRemoteLifecycleListener监听的10001和10002端口，来实现远程代码执行。
漏洞复现：
所需环境工具包：
catalina-jmx-remote.jar：
https://archive.apache.org/dist/tomcat/tomcat-8/v8.5.2/bin/extras/catalina-jmx-remote.jar
groovy-2.3.9.jar：
http://central.maven.org/maven2/org/codehaus/groovy/groovy/2.3.9/groovy-2.3.9.jar
ysoserial.jar：
https://jitpack.io/com/github/frohoff/ysoserial/master-SNAPSHOT/ysoserial-master-SNAPSHOT.jar
漏洞所需环境：
ApacheTomcat 8.5.2
Jdk1.7.0_80
安装成功如下图：
在进行漏洞复现之前我们需要配置几点如下：
conf/server.xml中第30行中配置启用JmxRemoteLifecycleListener功能监听的端口：
<Listener className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener" rmiRegistryPortPlatform="10001" rmiServerPortPlatform="10002" />
配置好jmx的端口后，我们在tomcat版本所对应的extras/目录下,下载catalina-jmx-remote.jar以及下载groovy-2.3.9.jar两个jar包。下载完成后放至在lib目录下。
接着我们再去bin目录下修改catalina.bat脚本。在ExecuteThe Requested Command注释前面添加这么一行。
set CATALINA_OPTS=-Dcom.sun.management.jmxremote.ssl=false - Dcom.sun.management.jmxremote.authenticate=false
主要配置的意思是设置启动tomcat的相关配置，不开启远程监听jvm信息。设置不启用他的ssl链接和不使用监控的账户。具体的配置可以去了解一下利用tomcat的jmx监控。至此所有的配置成功保存后，我们运行tomcat。
顺带监听本地的10001和10002的RMI服务端口是否成功运行。
监听成功，我们开始来构造Payload执行命令。首先老套路弹个计算器。payload如下:
漏洞利用：
一般我们可以利用该漏洞，往tomcat的webapp程序目录下写一个文本文件去证明该漏洞存在。poc如下：
java -cp ysoserial.jar ysoserial.exploit.RMIRegistryExploit 192.168.0.167 10001 Groovy1 "calc.exe"
执行弹窗计算器
以及可以直接向服务器上利用wget/copy等命令上传木马来进行获取webshell提权等。
访问 文件，反弹shell。
漏洞修复：
1.关闭JmxRemoteLifecycleListener功能，或者是对jmx JmxRemoteLifecycleListener远程端口进行网络访问控制。同时，增加严格的认证方式。
2.根据官方去升级更新相对应的版本。
CVE-2017-12615漏洞复现
参考先知社区：
https://xz.aliyun.com/t/5610
Coisini / 2019-07-11 09:13:00 / 浏览数 17007 安全技术 漏洞分析顶(1) 踩(0)
-
引言
这是一个关于任意文件上传的漏洞，在tomcat中启用put方法会导致任意文件可以上传，从而导致服务器权限被获取。 -
漏洞介绍
2017年9月19日，Apache Tomcat官方确认并修复了两个高危漏洞，其中就有远程代码执行漏洞(CVE-2017-12615)。当存在漏洞的Tomcat 运行在 Windows 主机上，且启用了HTTP PUT请求方法（例如，将 readonly 初始化参数由默认值设置为 false），攻击者将有可能可通过精心构造的攻击请求数据包向服务器上传包含任意代码的 JSP 的webshell文件，JSP文件中的恶意代码将能被服务器执行，导致服务器上的数据泄露或获取服务器权限。
漏洞危害：泄露用户代码数据，或用户服务器被攻击者控制。
影响范围：Apache Tomcat 7.0.0 – 7.0.79
-
环境搭建
测试环境：windows 10
Tomcat 7.0.56（Tomcat服务器是一个免费的开放源代码的Web应用服务器。）
Jdk 1.8.0
使用工具：Firefox ，burpsuit v1.7.36，
Firefox: 自由及开放源代码网页浏览器。
Burp Suite: 用于攻击web应用程序的集成平台，包含了许多工具。Burp Suite为这些工具设计了许多接口， 以加快攻击应用程序的过程。所有工具都共享一个请求，并能处理对应的HTTP消息、持久性、认证、代理、日志、警报。在一个工具处理HTTP请求和响应时，它可以选择调用其他任意的Burp工具。 -
漏洞代码分析
通过阅读conf/web.xml文件，可以发现：默认 readonly为true，禁止HTTP进行PUT和DELTE类型请求:
当web.xml中readonly设置为false时可以通过PUT/DELETE进行文件操控，漏洞就会触发。
这个CVE漏洞涉及到 DefaultServlet，DefaultServlet作用是处理静态文件，同时DefaultServlet可以处理PUT或DELETE请求，默认配置如图2：
可以看出即使设置readonly为false,默认tomcat也不允许PUT上传jsp和jspx文件，因为后端都用org.apache.catalina.servlets.JspServlet来处理jsp或是jspx后缀的请求，而JspServlet负责处理所有JSP和JPSX类型的动态请求，从代码没有发现处理HTTP PUT类型的操作, 所以可知PUT以及DELTE等HTTP操作由DefautServelt实现。因此，就算我们构造请求直接上传JSP webshell显然是不会成功的。该漏洞实际上是利用了windows下文件名解析的漏洞来触发的。根本是通过构造特殊后缀名，绕过Tomcat检测，让Tomcat用DefaultServlet的逻辑处理请求，从而上传jsp webshell文件。
具体来说，主要有三种方法：
shell.jsp%20
shell.jsp::$DATA
shell.jsp/
本次测试，使用第一种方法，可成功实现上传，并取得WebShell。
- 漏洞复现
根据描述，在Windows服务器下，将readonly参数设置为false时，即可通过PUT方式创建一个JSP文件，并可以执行任意代码。
Tomcat7中readonly默认值为true，手动将其改为false，在conf/web.xml中手动添加红色方框类内容，如图3：
设置完成后，启动Tomcat，利用PUT请求创建文件。
构造webshell请求，使用burpsuite抓包，如图4：
使用burpsuite发送构造的webshell，如图5：
提示404，请求测试结果表明了猜测结论是正确的。JspServlet负责处理所有JSP和JPSX类型的动态请求，不能够处理PUT方法类型的请求。
利用文件解析漏洞采用PUT方式上传jsp webshell文件。其中文件名设为/shell.jsp%20。（如果文件名后缀是空格那么将会被tomcat给过滤掉。）如图6：
发送成功后在webapps/root发现文件shell.jsp,说明漏洞复现成功。如图7：
访问发现可以正常输出，如图8：
6. 修复方案
1、配置readonly值为True或注释参数，禁止使用PUT方法并重启tomcat。
注意：如果禁用PUT方法，对于依赖PUT方法的应用，可能导致业务失效。
2、根据官方补丁升级最新版本。