jboss RPC RCE

分析

看到一个帖子提到jboss 漏洞，就去Twitter找了链接
jboss RPC RCE
https://jspin.re/jboss-eap-as-6-rce-a-little-bit-beyond-xac-xed/
https://s3.amazonaws.com/files.joaomatosf.com/slides/alligator_slides.pdf

https://jspin.re/jboss-eap-as-6-rce-a-little-bit-beyond-xac-xed/https://s3.amazonaws.com/files.joaomatosf.com/slides/alligator_slides.pdf

简单分析了下pdf的内容，漏洞不是传统的http漏洞，是jboss里的remoting3存在问题，可参考weblogic的T3，只是jboss是跑在独立的端口上。

4446: JBoss Remoting Unified Invoker
3873: EJB Remoting Connector
早期版本端口是4445，存在cve-2016-3690 反序列化漏洞（versions <= 5）。
jboss RPC RCE
新版本的4446和3873跑的是Remoting 3，但没有说明文档，作者只好编写代码，手动测试抓包来分析

依赖如下

<dependency>
    <groupId>org.jboss.remoting</groupId>
    <artifactId>jboss-remoting</artifactId>
    <version>2.4.0.GA</version>
</dependency>
<dependency>
    <groupId>org.jboss.logging</groupId>
    <artifactId>jboss-logging</artifactId>
    <version>3.3.0.Final</version>
</dependency>
<dependency>
    <groupId>org.jboss</groupId>
    <artifactId>jboss-common-core</artifactId>
    <version>2.5.0.Final</version>
    <exclusions>
        <exclusion>
            <groupId>org.jboss.logging</groupId>
            <artifactId>jboss-logging-spi</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>concurrent</groupId>
    <artifactId>concurrent</artifactId>
    <version>1.3.4</version>
</dependency>

<groupId>org.jboss.remoting</groupId>

<artifactId>jboss-remoting</artifactId>

</dependency>

<groupId>org.jboss.logging</groupId>

<artifactId>jboss-logging</artifactId>

<version>3.3.0.Final</version>

</dependency>

<groupId>org.jboss</groupId>

<artifactId>jboss-common-core</artifactId>

<version>2.5.0.Final</version>

<groupId>org.jboss.logging</groupId>

<artifactId>jboss-logging-spi</artifactId>

</exclusion>

</exclusions>

</dependency>

<groupId>concurrent</groupId>

<artifactId>concurrent</artifactId>

</dependency>

测试代码

        InvokerLocator locator = new InvokerLocator("socket://30.1.20.3:4446");
        Client remotingClient = new Client(locator, "ALLIGATOR");
        remotingClient.connect();
        System.out.println(remotingClient.invoke("RECIFE"));

InvokerLocator locator = new InvokerLocator("socket://30.1.20.3:4446");

Client remotingClient = new Client(locator, "ALLIGATOR");

remotingClient.connect();

System.out.println(remotingClient.invoke("RECIFE"));

jboss RPC RCE
看到ACED就很亲切了，通过ACED0005交互，然后Client发送payload，这个和我们一般发送的反序列化payload格式有所区别，没有ACED头。文章中解释了头部字段含义，这个之前做反序列化脏数据也涉及到过。（PS: 这里可以看到，建立连接后，server端会主动发送ACED0005，然后client交互ACED0005，在发送payload）
0x77011679

0x77: TC_BLOCKDATA
0x01: Length of TC_BLOCKDATA
0x16: Protocol version 22
0x79: TC_RESET (??)

0x77: TC_BLOCKDATA

0x01: Length of TC_BLOCKDATA

0x16: Protocol version 22

0x79: TC_RESET (??)

参考java/io/ObjectStreamConstants.java
jboss RPC RCE

然后和yso生成的payload可以对比下，其实就是前4字节不同。后续应该就是序列化数据，所以我们可以尝试替换前四字节然后发送利用。
jboss RPC RCE

这里就用yso生成一个，然后发送利用，数据包如下。
jboss RPC RCE

jboss RPC RCE

这个接口应该是RPC，那么应该可以像T3那样注册方法，然后invoke调用，待后续，不过漏洞验证还可以用sleep来测试。
jboss RPC RCE

PS:4446和3873端口均可利用

JDNI

文中还提到了一条jboss原生的反序列化利用链，ProducerManagerImpl，很直观的一条JNDI利用链
jboss RPC RCE
编写构造如下，本地测试可成功

进一步针对spring测试，也可利用。
jboss RPC RCE