渗透测试 | Tomcat渗透

前言

Tomcat服务器是一个免费的开放源代码的web应用服务器，属于轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP程序的首选。可以这样认为，当在一台机器上配置好 Apache服务器，可利用它响应HTML页面的访问请求。实际上 Tomcat是 Apache服务器的扩展，但运行时它是独立运行的，所以当运行 tomcat时，它实际上作为一个与 Apache独立的进程单独运行的。

目前版本型号7-10版本

默认端口：8080

安装

首先要有java的环境

注意：Tomcat的版本对与JAVA版本以及相应的JSP和 Servlet都是有要求的，Tomcat8版本以上的是需要Java7及以后的版本，所以需要对应JDK的版本来下载Tomcat的版本

然后安装Tomcat 一路默认下来 就ok了

可以看到它的8080端口 已经开启了

访问一下

Tomcat分析

主要文件

上传目录

Tomcat渗透

Tomcat任意文件写入(CVE-2017-12615）

影响范围

Apache Tomcat7.0.0-7.0.81（默认配置）

复现

这边我用vulhub

去底层看看源码

漏洞原理

产生是由于配置不当（非默认配置），将配置文件conf/web.xml中的readonly设置为了 false，导致可以使用PUT方法上传任意文件，但限制了jsp后缀，不过对于不同平台有多种绕过方法

开始复现

抓包 改位PUT 上传方式

去上传目录看看

成功上传

绕过，成功上传jsp

可以看到上传a001.jsp 是成功绕过了

其他两种我就不进行演示了

都是可以的

上传马儿，这边我用冰蝎进行连接

注意：不能开代理

看看冰蝎server目录下的jsp马儿

冰蝎的jsp马儿

注意这边要用/进行绕过,上传jsp

也可以看到是成功上传的

用冰蝎进行连接一下

最新版本复现

这边把这个漏洞的代码 粘贴进最新的版本

不加的话 PUT 上传txt都是不可以的

保存退出 进行重启Tomcat

确实是可以成功写入的

进行PUT写入txt 发现它是可以的

但是绕过，上传jsp 三种方法我都试了 是不行的

修复

把readonly 改成true

Tomcat远程代码执行（CVE-2019-0232）

影响范围

这边就用 Windows 8.5.39 进行复现

安装

同样是先安装java

然后安装Tomcat

访问一下

漏洞原理

漏洞相关的代码在tomcat\java\org\apache\catalina\servlets\CGIServlet.java中，CGISerlvet提供了一个cgi的调用接口，在启用enableCmdLineArguments参数时，会根据RFC 3875来从Url参数中生成命令行参数，并把参数传递至Java的Runtime执行。

这个漏洞是因为Runtime.getRuntime().exec在 Windows中和 Linux中底层实现不同导致的

Java的Runtime.getRuntime().exec在CGI调用这种情况下很难有命令注入。

而 Windows中创建进程使用的是 CreateProcess，会将参数合并成字符串，作为lpComandLine传入 CreateProcess。程序启动后调用GetcommandLine获取参数，并调用CommandLineToArgw传至argv

在 Windows中，当CreateProcess中的参数为bat文件或是cmd文件时，会调用 cmd.exe，故最后会变成cmd.exe /c "a001.bat dir"，而Java的调用过程并没有做任何的转义，所以在 Windows下会存在漏洞。

除此之外，Windows在处理参数方面还有一个特性，如果这里只加上简单的转义还是可能被绕过

例如dir "\"&whoami"在 Linux中是安全的，而在Windows会执行命令。 这是因为 Windows在处理命令行参数时，会将"中的内容拷贝为下一个参数，直到命令行结束或者遇到下一个"，但是对"的处理有误。因此在Java中调用批处理或者cmd文件时，需要做合适的参数检査才能避免漏洞岀现。

漏洞分析

Tomcat的 CGI_Servlet组件默认是关闭的，在conf/web.xml中找到注释的 CGIServlet部分，去掉注释，并配置 enableCmdLineArguments和executable

就是配置这里

这里主要的设置是enableCmdLineArguments和 executable两个选项。

1.enableCmdLineArguments启用后才会将Url中的参数传递到命令行 2.executable指定了执行的二进制文件，默认是perl，需要置为空才会执行文件本身。

同样在conf/web.xml中启用cgi的 servlet-mapping

修改conf/context.xml的添加 privileged=”true”属性，否则会没有权限

配置目录文件

在C:\Tomcat\webapps\ROOT\WEB-INF下创建cgi-bin目录

并在该目录下创建一个a001.txt

里面内容随意

记得重启一下

然后我们访问

可以看到成功任意代码执行！

修复方式

开发者在 patch中增加了cmdLineArgumentsDecoded参数，这个参数用来校验传入的命令行参数，如果传入的命令行参数不符合规定的模式，则不执行。 校验写在 setupFromRequest函数中

不通过时，会将 CGIEnvironment的valid参数设为 false，在之后的处理函数中会直接跳过执行

修复建议

1.使用更新版本的 Apache Tomcat。这里需要注意的是，虽然在9.0.18就修复了这个漏洞，但这个更新是并没有通过候选版本的投票，所以虽然9.0.18没有在被影响的列表中，用户仍需要下载9.0.19的版本来获得没有该漏洞的版本

2.关闭 enableCmdLineArguments参数

Tomcat弱口令&后台getshell漏洞

影响范围

Tomcat8

这边就还是用vulhub进行复现

之前的容器要关掉

去docker底层看看它的源码

把这三个文件复制出来

源码

manager（后台管理）

host-manager（虚拟主机管理

访问一下

访问一下它的后台管理地址

或者点这里

它的登录窗口是没有验证码的 直接爆破就可以

默认

登录进去之后 进行查看

为什么需要上传wa包，为什么不是 tar.zip？？

war包是用来进行Web开发时一个网站项目下的所有代码，包括前台HTML/CSS/JS代码，以及后台 JavaWeb的代码。当开发人员开发完毕时，就会将源码打包给测试人员测试，测试完后若要发布则也会打包成War包进行发布。War包可以放在Tomcat下的webapps或word目录，当Tomcat服务器启动时，War包即会随之解压源代码来进行自动部署。

上传JSP的大马

zip压缩 然后改后缀 成war的包

或者使用Java命令：

这里的/2就是war包的名字

去docker底层看看是否成功上传

它会自动部署 那我们访问一下

成功解析jsp大马，并能 upload上传功能！

这里上传冰蝎的jsp马儿

upload之后 上冰蝎进行连接

再贴一个JSP大马

MSF攻击

这里就直接略过了 自己去操作一下

这就成功进来了

修复建议

1、在系统上以低权限运行 Tomcat应用程序。创建一个专门的 Tomcat服务用户，该用户只能拥有一组最小权限（例如不允许远程登录）

2、增加对于本地和基于证书的身份验证，部署账户锁定机制（对于集中式认证，目录服务也要做相应配置）。 在CATALINA_HOME/conf/web.xml文件设置锁定机制和时间超时限制 3、以及针对manager-gui/manager-status/manager-script等目录页面设置最小权限访问限制

Tomcat manager App暴力破解

漏洞复现

我们先抓后台的包

然后放包 进行登录

这里注意这段回显

发现Tomcat的后台登录账号和密码

是以base64加密的 账号:密码

然后我们重新去抓后台的包 进行爆破

添加密码本 和base64 的编码规则

把这个自带的编码 对勾去掉

开始攻击 拿到账号和密码

这里讲第二种方式

自定义迭代器

分位置 进行不同的载入

比如这里 就应该是3个位置

下面和之前的设置 一样

base64编码 和去掉对勾 默认的Url编码

修复建议

1.取消 manager/html功能 2.manager页面应只允许本地IP访问

Tomcat AJP文件包含漏洞分析(CVE-2020-1938)

漏洞简介

由于 Tomcat在处理AJP请求时，未对请求做任何验证

通过设置AJP连接器封装的 request对象的属性，导致产生任意文件读取漏洞和代码执行漏洞！ CVE-2020-1938又名 GhostCat，由长亭科技安全研究员发现的存在于 Tomcat中的安全漏洞，由于 Tomcat AJP协议设计上存在缺陷，攻击者通过 Tomcat AJP Connector可以读取或包含 Tomcat上所有 webapp目录下的任意文件，例如可以读取 webapp配置文件或源码。

此外在目标应用有文件上传功能的情况下，配合文件包含的利用还可以达到远程代码执行的危害。

源码分析

漏洞成因是两个配置文件导致

Tomat在部罢时有两个重要的配置文件conf/server.xml、conf/web.xml

前者定义了 Tomcat启动时涉及的组件属性，其中包含两个connector(用于处理请求的组件)

如果开启状态下，tomcat启动后会监听8080、8009端口，它们分别负责接受http、ajp协议的数据

后者则和普通的javaWeb应用一样，用来定义servlet

参考链接

https://xz.aliyun.com/t/7325

https://yinwc.github.io/2020/03/01/CVE-2020-1938/

运行过程

从图中可以看出，Tomcat最顶层的容器是 Server，其中包含至少一个或者多个 Service，一个 Service有多个 Connector和一个 Container组成。

这两个组件的作用为:

1、Connector用于处理连接相关的事情，并提供Socket与Request和Response相关的转化； 2、Container用于封装和管理 Servlet，以及具体处理 Request请求

Tomcat默认的conf/server.xml中配置了2个Connector，

一个为8080端口 HTTP协议(1.1版本)端口，默认监听地址：0.0.0.0:8080

另外一个就是默认的8009 AJP协议(1.3版本)，默认监听地址为：0.0.0.0:8009，两个端口默认均监听在外网。此次漏洞产生的位置便是8009 AJP协议，此处使用公开的利用脚本进行测试，可以看到能读取web.xml文件

漏洞复现

利用vulhub

Poc地址：

https://github.com/YDHCUI/CNVD-2020-10487-Tomcat-Ajp-lfi

脚本是基于Python2的

它可以看webapps目录下的所有东西

可以看到它的语法要求

文件包含RCE

在线bash payload生成：http://www.jackson-t.ca/runtime-exec-payloads.html

最终的txt的payload

这边要手动上传上去

查看

然后开始上传

可以去docker 底层看看

成功传上去了

开启nc监听

具体可以看这里：

https://blog.csdn.net/qq\_30653631/article/details/93749505?utm\_medium=distribute.pc\_aggpage\_search\_result.none-task-blog-2\~aggregatepage\~first\_rank\_v2\~rank\_aggregation-1-93749505.pc\_agg\_rank\_aggregation&utm\_term=Ubuntu%E5%AE%89%E8%A3%85nc&spm=1000.2123.3001.4430

可以看到成功上线了

可以和War联动是吧 可以和PUT联动

把shell弹到MSF上

MSF生成木马

我这边还是上kali吧 Ubuntu不是很顺手

去docker底层看看

上MSF 开启监听

执行文件包含RCE

可以看到已经拿到shell了

按shell就可以进来了

修复建议

1、将 Tomcat立即升级到9.0.31、8.5.51或7.0.100版本进行修复 2、禁用AJP协议 具体方法：

编辑/conf/server.xml，找到如下行：

注释或删除

3、配置 secret来设置AJP协议的认证凭证。