Z_zz_zzz · 2016/03/08 the assembling

0 x00 preface

Oracle has yet to release an official patch for webLogic’s JAVA deserialization vulnerability.

  1. Replace ObjectInputStream with SerialKiller;
  2. In does not affect business cases, temporary delete the project in the “org/apache/Commons/collections/functors InvokerTransformer. Class” file.

The ObjectInputStream class is a native JRE class, and the InvokerTransformer. Class is a class in the Basic WebLogic package. Modifying or deleting these two classes cannot guarantee that services will not be affected. If the above fixes are used, a lot of testing is required. And simply deleting the InvokerTransformer. Class file does not guarantee that other classes will not be found to have deserialization vulnerabilities later.

Therefore, this paper analyzes JAVA serialization vulnerability of WebLogic, tests multiple versions of Weblogic, and puts forward more feasible repair methods.

0x01 Why Choose WebLogic JAVA deserialization Vulnerability for analysis

  1. Weblogic and websphere are the most widely used enterprise-level JAVA middleware in financial industry.
  2. Weblogic has a higher market share than websphere;
  3. To exploit websphere’s JAVA deserialization vulnerability, you need to access port 8880, the websphere wsadmin service port, which should not be exposed to the public network. If port 8880 of the websphere server is accessible on the public network, the security value of the server is relatively low.
  4. JAVA deserialization vulnerability of WebLogic can directly control the server, causing great harm. In addition, WebLogic usually has only one service port, and the vulnerability cannot be fixed by disabling public network access to a specific port.

0x02 Given conditions

Breenmachine’s “What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? “This Vulnerability.” After reading webLogic’s description, we learned about the following.

  1. You can search the code to see if the WebLogic JAR package contains a specific JAVA class;
  2. When webLogic’s stop script is called, JAVA serialization data is sent to WebLogic;
  3. Through ObjectInputStream. ReadObject methods parse JAVA serialization data;
  4. The first few bytes of T3 data sent by WebLogic are the data length;
  5. Replacing one of the serialized data in T3 data sent by WebLogic as malicious serialized data causes WebLogic to execute the specified code.

0x03 Vulnerability Analysis

Capture packet analysis of JAVA serialized data sent by WebLogic

As we know from BreenMachine’s article, JAVA serialization data is sent to WebLogic when webLogic’s stop script is called, so let’s repeat the process.

The Wireshark running in Windows is used to analyze data packets. However, by default, the Wireshark running in Windows cannot capture packets when accessing ports monitored by the local host. The above problems can be solved. You can also call the Weblogic stop script on a Windows machine and use Wireshark to capture packets. In Linux, you can use tcpdump to capture packets and Wireshark to analyze the packets.

How does the Windows environment capture packets when accessing the local listening port

This problem can be solved by:

  1. Add routing policies.Route add [local IP address, do not use 127.0.0.1] mask 255.255.255.255 [default gateway IP address] metric 1Then you can use the Wireshark to capture and analyze packets. XP test successful, Windows 7 failed.
  2. You can use the RawCap tool to capture 127.0.0.1 packets and use the Wireshark to analyze captured packets. Win7 test successful, XP failed. Download from www.netresec.com/?page=RawCa… .

How do I call weblogic stop scripts from Windows machines

CMD file in the bin directory of the domain. Find ADMIN_URL=t3://[IP]:[port]. [IP] is usually the host name of the local computer, and [port] is usually 7001. Change [IP] and [port] to the IP address and WebLogic listening port of another WebLogic machine respectively. Run the modified stopWebLogic. CMD script and capture packets.

The Wireshark is used to analyze data packets

After capturing the packets during the WebLogic stop script invocation, use Wireshark to analyze the packets. You can filter by using criteria such as IP or port to display only packets related to the invocation of the WebLogic stop script.

It is known that the first 4 bytes of JAVA serialized data are “AC ED 00 05”. Use the “TCP Contains AC: ED :00:05” condition to filter out the packet containing JAVA serialized data. Right-click the first packet and choose “Follow TCP Stream”, as shown in the following figure.

View data packets in hexadecimal format and search for AC Ed 00 05. You can find the corresponding data and confirm that the captured data contains JAVA serialized data.

Remove the filtering condition for “AC Ed 00 05” and view the first data packet in ASCII format. The content is as follows:

It can be seen that when the WebLogic client sends serialized data to the WebLogic server, the first packet sent is the T3 protocol header. In this paper, the T3 protocol header sent is “T3 9.2.0\nAS:255\nHL:19\n\n”, and the first behavior is “T3” plus the version number of the WebLogic client. The data returned by the Weblogic server is “HELO:10.0.2.0.false\nAS:2048\nHL:19\n\n”, the first behavior is “HELO:” plus the version number of the WebLogic server. Data sent by both the WebLogic client and server ends with “\n\n”.

Convert the packets displayed in Wireshark to JAVA code

As you can see from the screenshot above, the JAVA serialized data in the packet is very long and contains non-printable characters, which cannot be directly exported to JAVA code.

In the Wireshark, the data sent by the client to the server is displayed in red, and the data returned by the server to the client is displayed in blue.

View the first Packet in C array format. The array of peer0_X is Packet 1. Copy the array of peer0_X into an array of C language format, such as “char Peer0_0 [] = {0x01, 0x02… };” , change the char of the data to byte and replace 0x with (byte)0x, which can be directly used in JAVA code, for example, byte peer0_0[] = {(byte)0x00, (byte)0x02… } “.

Parse the JAVA serialized data

According to the article breenmachine we know, you can use the ObjectInputStream. ReadObject methods parse JAVA serialization data.

Using ObjectInputStream. ReadObject method resolution weblogic calls to stop the script send JAVA serialization of the data structure of the HTML code is as follows. The following code needs to be added to the Classpath of JAVA execution, otherwise a ClassNotFoundException will be thrown.

The result of the above code is as follows.

#! bash Data Length-Compute: 1711 Data Length: 1711 Object found: weblogic.rjvm.ClassTableEntry Object found: weblogic.rjvm.ClassTableEntry Object found: weblogic.rjvm.ClassTableEntry Object found: weblogic.rjvm.ClassTableEntry Object found: weblogic.rjvm.JVMID Object found: weblogic.rjvm.JVMID size: 0 start: 0 end: 234 size: 1 start: 234 end: 348 size: 2 start: 348 end: 591 size: 3 start: 591 end: 986 size: 4 start: 986 end: 1510 size: 5 start: 1510 end: 1634 size: 6 start: 1634 end: 1711Copy the code

It can be seen that The JAVA serialized data sent by WebLogic is divided into seven parts. The first four bytes of the first part are the length of the entire packet (1711=0x6AF), and the second to seventh parts are all JAVA serialized data.

Weblogic sends JAVA serialized data in the following format.

Exploit WebLogic’s JAVA deserialization vulnerability

To exploit WebLogic’s JAVA deserialization vulnerability, you need to send two packets to WebLogic.

The first packet is the protocol header of T3. After testing, it is legal to send the string “T3 9.2.0\nAS:255\nHL:19\n\n” as t3’s protocol hair to Weblogic9, WebLogic10G, WebLogic11g, webLogic12C. After sending the T3 protocol header to WebLogic, WebLogic returns the corresponding data, ending with \n\n, as described in the previous section.

The second packet is JAVA serialized data, which can be generated in two ways.

The first is to replace any of the second through seven parts of the JAVA serialization data sent by webLogic as described above with malicious serialization data.

When JAVA serialized data is generated in the first way, the data format is shown below.

The second generation method is to concatenate the first part of the JAVA serialized data sent by webLogic as described above with the malicious serialized data.

When JAVA serialized data is generated in the second way, the data format is shown below.

Malicious serialized data generation process can reference drops.wooyun.org/papers/1324… .

When you send WebLogic the JAVA serialization data generated in the first way above, WebLogic throws the following exception.

#! bash java.io.EOFException at weblogic.utils.io.DataIO.readUnsignedByte(DataIO.java:435) at weblogic.utils.io.DataIO.readLength(DataIO.java:828) at weblogic.utils.io.ChunkedDataInputStream.readLength(ChunkedDataInputStream.java:150) at weblogic.utils.io.ChunkedObjectInputStream.readLength(ChunkedObjectInputStream.java:196) at weblogic.rjvm.InboundMsgAbbrev.read(InboundMsgAbbrev.java:37) at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:287) at weblogic.rjvm.MsgAbbrevInputStream.init(MsgAbbrevInputStream.java:212) at weblogic.rjvm.MsgAbbrevJVMConnection.dispatch(MsgAbbrevJVMConnection.java:507) at weblogic.rjvm.t3.MuxableSocketT3.dispatch(MuxableSocketT3.java:489) at weblogic.socket.BaseAbstractMuxableSocket.dispatch(BaseAbstractMuxableSocket.java:359) at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:970) at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:907) at weblogic.socket.NIOSocketMuxer.process(NIOSocketMuxer.java:495) at weblogic.socket.NIOSocketMuxer.processSockets(NIOSocketMuxer.java:461) at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:30) at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:43) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:147) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:119)Copy the code

Weblogic throws the following exception when it sends the JAVA serialization data generated by the second method above to WebLogic.

#! bash weblogic.rjvm.BubblingAbbrever$BadAbbreviationException: Bad abbreviation value: 'xxx' at weblogic.rjvm.BubblingAbbrever.getValue(BubblingAbbrever.java:153) at weblogic.rjvm.InboundMsgAbbrev.read(InboundMsgAbbrev.java:48) at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:287) at weblogic.rjvm.MsgAbbrevInputStream.init(MsgAbbrevInputStream.java:212) at weblogic.rjvm.MsgAbbrevJVMConnection.dispatch(MsgAbbrevJVMConnection.java:507) at weblogic.rjvm.t3.MuxableSocketT3.dispatch(MuxableSocketT3.java:489) at weblogic.socket.BaseAbstractMuxableSocket.dispatch(BaseAbstractMuxableSocket.java:359) at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:970) at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:907) at weblogic.socket.NIOSocketMuxer.process(NIOSocketMuxer.java:495) at weblogic.socket.NIOSocketMuxer.processSockets(NIOSocketMuxer.java:461) at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:30) at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:43) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:147) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:119)Copy the code

Although WebLogic throws the above exception when it exploits webLogic’s JAVA deserialization vulnerability, webLogic has already executed the readObject method on malicious serialized data and the vulnerability is still triggered.

According to the test, the T3 protocol header packet must be sent first, and then the JAVA serialization packet must be sent, so that WebLogic can deserialize JAVA and trigger the vulnerability. If only JAVA serialization packets are sent, T3 protocol header packets are not sent first, the vulnerability cannot be triggered.

Call procedure when triggered by WebLogic’s JAVA deserialization vulnerability

The code that uses FileOutputStream to write to an illegal file is constructed as malicious serialized data and sent to WebLogic. When WebLogic performs de-serialization of the serialized data, it will throw an exception when the vulnerability is triggered. The call process when the vulnerability is triggered can be viewed through stack information. As shown below.

#! bash org.apache.commons.collections.FunctorException: InvokerTransformer: The method 'newInstance' on 'class java.lang.reflect.Constructor' threw an exception at org.apache.commons.collections.functors.InvokerTransformer.transform(InvokerTransformer.java:132) at org.apache.commons.collections.functors.ChainedTransformer.transform(ChainedTransformer.java:122) at org.apache.commons.collections.map.TransformedMap.checkSetValue(TransformedMap.java:203) at org.apache.commons.collections.map.AbstractInputCheckedMapDecorator$MapEntry.setValue(AbstractInputCheckedMapDecorator.j ava:191) at sun.reflect.annotation.AnnotationInvocationHandler.readObject(AnnotationInvocationHandler.java:356) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1893) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) at weblogic.rjvm.InboundMsgAbbrev.readObject(InboundMsgAbbrev.java:67) at weblogic.rjvm.InboundMsgAbbrev.read(InboundMsgAbbrev.java:39) at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:287) at weblogic.rjvm.MsgAbbrevInputStream.init(MsgAbbrevInputStream.java:212) at weblogic.rjvm.MsgAbbrevJVMConnection.dispatch(MsgAbbrevJVMConnection.java:507) at weblogic.rjvm.t3.MuxableSocketT3.dispatch(MuxableSocketT3.java:489) at weblogic.socket.BaseAbstractMuxableSocket.dispatch(BaseAbstractMuxableSocket.java:359) at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:970) at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:907) at weblogic.socket.NIOSocketMuxer.process(NIOSocketMuxer.java:495) at weblogic.socket.NIOSocketMuxer.processSockets(NIOSocketMuxer.java:461) at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:30) at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:43) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:147) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:119)Copy the code

Determine whether WebLogic uses the Apache Commons Collections component

Breenmachine writes that you can find out if a WebLogic JAR contains a particular JAVA class by searching the code. Because a particular JAVA class may exist in many different JAR packages, this method cannot accurately determine whether WebLogic uses Apache Commons Collections component-specific JAVA classes.

The following is an accurate way to determine whether WebLogic uses Apache Commons Collections component-specific JAVA classes.

Install any J2EE application in WebLogic and write the following code in a JSP.

#! Js <% String path = [full class name].class.getResource("").getPath(); out.println(path); % >Copy the code

Or the following code.

#! Js < % String path = / need to find the full name of the class of a class. Class. GetProtectionDomain () getCodeSource (). The getLocation () getFile (); out.println(path); % >Copy the code

Using a browser to access the ABOVE JSP file, you can see the full path to the JAR package where the corresponding class resides.

Through the above method to find the “org.apache.com mons. Collections. Map. TransformedMap” jars, sample as below.

Use of the Apache Commons Collections component by different versions of Weblogic

“Org.apache.com mons. Collections. Map. TransformedMap” weblogic jar package information is as follows.

Weblogic version Path to the JAR package where the TransformedMap class resides
9.2 There is no
10.2.1(WebLogic 10G), 10.3.4(WebLogic 11g) Weblogic installation directory modules/com.bea.core.apache.com mons. Collections_3. 2.0. The jar
12.1.3 (weblogic 12 c) Weblogic installation directory wlserver/modules/features/weblogic server. The merged. The jar

Weblogic 9.2 does not contain the TransformedMap class, so the deserialization vulnerability cannot be triggered. Weblogic 10G, WebLogic 11g, and WebLogic 12C all contain the TransformedMap class, so the deserialization vulnerability can be triggered.

0x04 Vulnerability Fixed

Idea of Vulnerability repair

The default service port of WebLogic is 7001, which provides services for protocols such as HTTP(S), SNMP, and T3. Because different WebLogic protocols use the same port, there is no way to prevent JAVA deserialization vulnerability by restricting port access through firewalls.

In most application scenarios, users only need to use HTTP(S) to access the Web application server on the public network. In most cases, webLogic servers only need to access HTTP(S) services provided by WebLogic on the public network, and do not need to access T3.

In a few cases, o&M personnel need to use WebLogic T3 protocol:

  • Execute webLogic stop script on weblogic server.
  • Script configuration of WebLogic through WLST;
  • Write the program using T3 protocol to communicate with Weblogic state monitoring and other management functions.

Both T3 and HTTP are based on TCP. T3 starts with “T3” and HTTP starts with “GET” or “POST”. There are obvious differences between the two protocols.

Therefore, it is possible to limit the T3 protocol that only allows certain servers to access webLogic servers and fix the JAVA deserialization vulnerability of WebLogic. Even if JAVA deserialization vulnerabilities are found in other WebLogic classes in the future.

If webLogic is fixed to require the user name and password of WebLogic to be sent when sending T3 protocol, the deserialization problem of WebLogic can also be fixed, but it will bring about the problem of how to store the password in the WebLogic client.

Invalid bug fix method

First, deploy the application to a non-management Server and check whether its service port also provides T3 services.

AdminServer is the default webLogic administrative Server. After a non-administrative Server named server-test is added, the information about the WebLogic Server is as follows: The administrative Server and the non-administrative Server use different listening ports, and j2ee applications can be deployed on the non-administrative Server so that the WebLogic console and the application can serve on different ports.

According to the test, the newly added listening port of the non-management Server also provides the service of T3 protocol, and JAVA deserialization vulnerability also exists. Therefore, this repair method is not effective for JAVA deserialization vulnerability, but it can separate the WebLogic console port from the application port, and use a firewall to prohibit access to the WebLogic console through the public network.

The service port for websphere

Let’s look at the service port situation for websphere, another widely used enterprise JAVA middleware. As you can see from the figure below, websphere’s default HTTP service port is 9080 for the application, 9443 for the application, 9060 for the console, 9043 for the console, and 8880 for receiving JAVA serialized data. So simply by blocking the public network from accessing port 8880 of the websphere server through a firewall, you can prevent the exploitation of websphere JAVA deserialization vulnerabilities over the public network.

Impact of network devices on data packets

A company with security requirements may choose the following deployment architecture to deploy the WebLogic server to provide services for users on the public network (firewalls between different network zones on the Intranet are omitted).

The impact of the network devices on packets is as follows.

  1. IPS

    The IPS can update defense rules. A vendor’s IPS may have configured a defense rule against JAVA deserialization vulnerability to block malicious JAVA serialization packets.

  2. A firewall

    The firewall here refers to the traditional firewall, not the next generation firewall. It only cares about IP and port, but does not care about data packet content, and cannot block malicious JAVA serialized data packets.

  3. WAF

    As with IPS, whether malicious JAVA serialized packets can be blocked depends on protection rules.

  4. Web agent

    Proxy forwarding is performed only for HTTP, but not for T3.

  5. Load balancing

    You can specify the protocol type for load balancing. For security, select HTTP instead of TCP and forward only HTTP rather than T3.

According to the above analysis, Web proxy and load balancing can stably forward only HTTP data and not T3 data, thus protecting against JAVA deserialization vulnerability.

If a Web proxy or load balancer is deployed in the path from the public network to the WebLogic server, JAVA deserialization vulnerability attacks launched from the public network can be protected. This is also the reason why webLogic deserialization vulnerability of large companies is rarely found. Its network architecture determines that WebLogic JAVA deserialization vulnerability cannot be exploited in the public network.

Feasible method of bug fixing

Deploy load balancing devices

JAVA deserialization vulnerabilities can be fixed by deploying load balancing devices outside the WebLogic server.

advantages disadvantages
The impact on the system is small and the impact on existing system functions does not need to be tested Need to buy equipment; JAVA deserialization vulnerability attacks launched from the Intranet cannot be defended

Deploy an independent Web proxy

Deploying a separate Web proxy outside the WebLogic server fixes the JAVA deserialization vulnerability.

advantages disadvantages
Same as above Same as above

Deploy the Web proxy on the WebLogic server

Modify the WebLogic listening port in the WebLogic console, as shown in the following figure.

JAVA deserialization vulnerability can be fixed by installing Web proxy applications such as Apache and Nginx on the webLogic server so that the Web proxy can listen on the original WebLogic listening port and forward HTTP requests to the local WebLogic.

advantages disadvantages
The impact on the system is small, and there is no need to test the impact on the existing system functions; No need to buy equipment JAVA deserialization vulnerability attacks launched from the Intranet cannot be defended. Increases the performance overhead of the server

Deploy the Web proxy on the WebLogic server and change the listening IP address of the WebLogic server

In the WebLogic console, modify the listening port of WebLogic and set the listening address to 127.0.0.1 or localhost, as shown in the following figure. After the modification, only the local webLogic server can access the WebLogic service.

JAVA deserialization vulnerability can be fixed by installing Web proxy applications such as Apache and Nginx on the webLogic server so that the Web proxy can listen on the original WebLogic listening port and forward HTTP requests to the local WebLogic. The listening IP address of the Web proxy must be set to 0.0.0.0; otherwise, other servers cannot access it.

You need to change the IP address of ADMIN_URL in the WebLogic stop script to 127.0.0.1 or localhost; otherwise, the stop script is unavailable.

advantages disadvantages
The impact on the system is small, and there is no need to test the impact on the existing system functions; No need to buy equipment; Protects against JAVA deserialization vulnerability attacks launched from the Intranet Increases the performance overhead of the server

Modify webLogic code

Weblogic handle T3 protocol such as “weblogic. RJVM. T3. MuxableSocketT3”, the class of different versions of weblogic in different jars, See the section “Determining whether WebLogic uses the Apache Commons Collections component” above to find the JAR package in which a class resides.

Create a Java project using Eclipse or another IDE, create the Weblogic.rJVM.t3 package, and create the muxablesockett3.java file in it. In locating the “weblogic. RJVM. T3. MuxableSocketT3” class of weblogic jar package, decompiled, add the corresponding jar package to create a Java project classpath. Copy the decomcompiled code of the original MuxableSocketT3 class into the muxablesockett3. Java of the Java project you created. If classes from other JAR packages are introduced, add the corresponding JAR packages to the Java project classpath.

When weblogic processes T3 protocol, dispatch method of MuxableSocketT3 class is called. The original code of dispatch method of weblogic 12.1.3 is as follows.

#! java public final void dispatch(Chunk list) { if (! (this.bootstrapped)) { try { readBootstrapMessage(list); this.bootstrapped = true; } catch (IOException ioe) { SocketMuxer.getMuxer().deliverHasException(getSocketFilter(), ioe); } } else this.connection.dispatch(list); }Copy the code

In this method, the processing of limiting client IP address is added. If the client IP address sending T3 protocol data is not allowed, the connection is rejected. The code for the Dispatch method with the added restriction is as follows.

#! java public final void dispatch(Chunk list) { if (! (this.bootstrapped)) { try { //add String ip = getSocket().getInetAddress().getHostAddress(); System.out.println("MuxableSocketT3-dispatch-ip: " + ip); if(! IP. Equals (" 127.0.0.1 ") &&! ip.equals("0:0:0:0:0:0:0:1")) rejectConnection(1, "Illegal IP"); //add-end readBootstrapMessage(list); this.bootstrapped = true; } catch (IOException ioe) { SocketMuxer.getMuxer().deliverHasException(getSocketFilter(), ioe); } } else this.connection.dispatch(list); }Copy the code

Stop WebLogic, replace the generated MuxableSocketT3*. Class file with the JAR package containing MuxableSocketT3, start WebLogic, and send the T3 protocol packet to WebLogic again. The following output is displayed.

The above figure shows that the code added above works correctly, has no impact on the normal function of WebLogic, can limit the client IP that sends T3 data, and can fix the deserialization vulnerability.

When WebLogic processes THE HTTP protocol, MuxableSocketT3 class is not called. Therefore, the above modification does not affect normal service functions.

The client IP that is allowed to send T3 can be specified through an environment variable or configuration file, read in the modified Dispatch method. The example in this article only allows the native to send T3. You need to change the IP address of ADMIN_URL in the WebLogic stop script to 127.0.0.1 or localhost; otherwise, the stop script is unavailable.

advantages disadvantages
The impact on the system is small, and there is no need to test the impact on the existing system functions; No need to buy equipment; It can protect against JAVA deserialization vulnerability attacks launched from the Intranet. There is no performance overhead for the server There is a business risk that may affect oracle maintenance

The biggest problem with this fix is the impact it may have on Oracle maintenance, but I believe that there are many companies that do not have maintenance contracts with Oracle. If you are not worried about related problems, you can use this fix. It would be nice to ask Oracle to provide an official patch.