Method Analysis for fixing weblogic JAVA deserialization Vulnerability
Oracle has not released official JAVA deserialization vulnerability patches for weblogic in public. Currently, there are only two solutions:
Use SerialKiller to replace the ObjectInputStream class for serialization;
Delete the org/apache/commons/collections/functors/InvokerTransformer. class file in the project without affecting the service.
The ObjectInputStream class is the native class of JRE, and InvokerTransformer. class is the class in the weblogic basic package. modifying or deleting the above two classes cannot guarantee that the services will not be affected. If the above repair method is used, a lot of testing work is required. Only the InvokerTransformer. class file is deleted, and the deserialization vulnerability of other classes cannot be found in the future.
Therefore, this article analyzes the JAVA serialization vulnerability of weblogic, tests multiple versions of weblogic, and puts forward more feasible repair methods.
0x01 why weblogic's JAVA deserialization vulnerability is selected for analysis
Weblogic and websphere use enterprise-level JAVA middleware for the financial industry;
Weblogic has a higher market share than websphere;
To exploit the JAVA deserialization vulnerability in websphere, you need to access port 8880, which is the wsadmin service port of websphere and should not be exposed to the public network. If Port 8880 of the websphere server is accessible from the public network, the security value of the server is relatively low;
The JAVA deserialization vulnerability of weblogic can be exploited to directly control servers. weblogic usually has only one service port and cannot be fixed by disabling access to a specific port from the public network.
0x02 known conditions
Breenmachine's "What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability. "This article analyzes the JAVA serialization Vulnerability of weblogic. After reading This article's description about weblogic, we know the following information.
You can search for the weblogic jar package to check whether it contains a specific JAVA class;
When weblogic's stop script is called, JAVA serialized data is sent to weblogic;
You can use ObjectInputStream. readObject to parse JAVA serialized data;
The first few bytes of the T3 data sent by weblogic are the data length;
Replace a serialized data in the T3 data sent by weblogic with a malicious serialized data, so that weblogic can execute the specified code.
0x03 Vulnerability Analysis
JAVA serialization data packet capture analysis sent by weblogic
According to the breenmachine article, we know that JAVA serialization data will be sent to weblogic when weblogic's stop script is called. We will repeat this process.
The data packet analysis tool is good for Wireshark in Windows, but it cannot capture packets when accessing the port listened by the Local Machine by default. The above problem can be solved. You can also call weblogic of another machine on Windows to stop the script and use Wireshark to capture packets; or use tcpdump to capture packets in Linux, use Wireshark to analyze the generated data packets.
In Windows, how does one capture packets when accessing the port listening on the local machine?
You can solve this problem by using the following methods:
Add a routing policy. route add [local IP address, do not use 127.0.0.1] mask route 255.255.255.255 [default gateway IP address] metric 1. Then you can use Wireshark for packet capture analysis. XP test successful, win7 failed.
The RawCap tool can be used to capture packets at 127.0.0.1. Wireshark can be used to analyze the generated packet capture files. If Windows 7 is tested successfully, XP fails. For http://www.netresec.com /? Page = RawCap.
How to call weblogic stop scripts of other machines on Windows machines
Edit stopWebLogic in the bin directory of domain. in the cmd file, find the "ADMIN_URL = t3: // [IP]: [port]" section. [IP] is generally the Host Name of the local machine, and [port] is generally 7001. Change [IP] and [port] to the IP address of the machine where weblogic is located and the weblogic listening port respectively. Run the modified stopWebLogic. cmd script and capture the package.
Use Wireshark to analyze data packets
After completing packet capture for the weblogic stop script call process, Wireshark is used to analyze the data packets. You can use conditions such as IP addresses or ports to filter data packets. Only data packets related to the weblogic stop script are displayed.
The first four bytes of JAVA serialized data are known to be "ac ed 00 05". The "tcp contains ac: ed: 00: 05" condition is used to filter data packets containing JAVA serialized data, right-click the first packet and select "Follow TCP Stream", as shown in.
View the data packet in hexadecimal format and find "ac ed 00 05". You can find the corresponding data and check that the captured data contains JAVA serialized data.
Cancel the filtering condition for "ac ed 00 05" and view the first packet in ASCII format. The content is as follows.
When the weblogic client sends serialized data to the weblogic Server, the first packet sent is the T3 protocol header. The T3 protocol header sent during this test is "t3 9.2.0 \ nAS: 255 \ lymphoma: 19 \ n ". The first act is" t3 "and the weblogic Client Version Number is added. The data returned by the weblogic Server is "HELO: 10.0.2.0.false \ nAS: 2048 \ UN: 19 \ n". The first behavior is "HELO:" And the weblogic Server version number. The data sent by the weblogic client and server ends with "\ n.
Converts the data packets displayed by Wireshark to JAVA code.
From the above we can see that the JAVA serialized data in the data packet is very long and contains non-printable characters and cannot be exported directly to JAVA code.
In 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.
Use the C array to view the first data Packet. The peer0_x array is Packet 1, and the peer0_x array is copied to an array in the C format, for example, "char peer0_0 [] = {0x01, 0x02 ...}; ", change the" char "of the preceding data to" byte ", and replace" 0x "with" (byte) 0x ", which can be converted to a form that can be directly used in JAVA code, format: "byte peer0_0 [] = {(byte) 0x00, (byte) 0x02 ...} ".
Parse JAVA serialized data
According to the breenmachine article, we know that you can use the ObjectInputStream. readObject method to parse JAVA serialized data.
Use the ObjectInputStream. readObject method to parse the JAVA serialization Data Structure sent when weblogic calls the stop script. The Code is as follows. When executing the following code, you must add weblogic. jar to the classpath executed by JAVA. Otherwise, a ClassNotFoundException exception will be thrown.
The execution result of the above Code is as follows.
Data size-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: 1711
We can see 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 data packet (1711 = 0x6AF), and the second to the seventh parts are JAVA serialized data.
The format of JAVA serialized data sent by weblogic is as follows.
JAVA deserialization vulnerability in weblogic
To exploit the JAVA deserialization vulnerability of weblogic, you must send two data packets to weblogic.
The first packet is the protocol header of T3. It was tested that it is valid to send the "t3 9.2.0 \ nAS: 255 \ UN: 19 \ n" string to weblogic9, weblogic10g, weblogic11g, and weblogic12c as the T3 protocol hair. After the T3 protocol header is sent to weblogic, weblogic also returns the corresponding data, ending with "\ n". For the specific format, see the previous article.
The second data packet is serialized in JAVA, which can be generated in two ways.
The first generation method is to replace any of the JAVA serialized data in the second to seventh parts of the JAVA serialized data sent by weblogic as malicious serialized data.
When JAVA serialization data is generated in the first way, the data format is as follows.
The second generation method is to splice the first part of JAVA serialization data sent by weblogic in the previous article with malicious serialization data.
The second method is used to generate JAVA serialized data. The data format is as follows.
When the JAVA serialization data generated in the first method is sent to weblogic, weblogic throws the following exception.
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. base‑actmuxablesocket. dispatch (base‑actmuxablesocket. 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.exe cute (SocketReaderRequest. java: 43)
At weblogic.kernel.ExecuteThread.exe cute (ExecuteThread. java: 147)
At weblogic. kernel. ExecuteThread. run (ExecuteThread. java: 119)
When the JAVA serialization data generated in the second method is sent to weblogic, weblogic throws the following exception.
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. base‑actmuxablesocket. dispatch (base‑actmuxablesocket. 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.exe cute (SocketReaderRequest. java: 43)
At weblogic.kernel.ExecuteThread.exe cute (ExecuteThread. java: 147)
At weblogic. kernel. ExecuteThread. run (ExecuteThread. java: 119)
Although weblogic throws the above exception when exploiting the JAVA deserialization vulnerability of weblogic, weblogic has executed the readObject Method for malicious serialized data, and the vulnerability will still be triggered.
According to the test, you must first send the T3 protocol header data packet and then send the JAVA serialization data packet to enable weblogic to perform JAVA deserialization and then trigger the vulnerability. If only JAVA serialized data packets are sent, the T3 protocol header data packet is not sent first, and the vulnerability cannot be triggered.
JAVA deserialization vulnerability in weblogic
The code that uses FileOutputStream to write an invalid file is constructed as a malicious serialized data and sent to weblogic. When weblogic deserializes the serialized data, an exception is thrown when a vulnerability is triggered. You can view the call process when the vulnerability is triggered through stack information, as shown below.
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. java: 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. base‑actmuxablesocket. dispatch (base‑actmuxablesocket. 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.exe cute (SocketReaderRequest. java: 43)
At weblogic.kernel.ExecuteThread.exe cute (ExecuteThread. java: 147)
At weblogic. kernel. ExecuteThread. run (ExecuteThread. java: 119)
Check whether weblogic uses the Apache Commons Collections component.
Breenmachine writes in the article that you can search for the code to check whether the weblogic jar package contains a specific JAVA class. Because specific JAVA classes may exist in many different jar packages, this method cannot accurately determine whether weblogic uses the Apache Commons Collections component-specific JAVA classes.
You can use the following methods to accurately determine whether weblogic uses the JAVA class specified by the Apache Commons Collections component.
Install any j2ee application in weblogic and write the following code in a jsp.
String path = [complete class Name of the class to be searched]. class. getResource (""). getPath ();
Out. println (path );
%>
Or the following code.
String path = [complete class Name of the class to be searched]. class. getProtectionDomain (). getCodeSource (). getLocation (). getFile ();
Out. println (path );
%>
Access the preceding jsp file using a browser and you can see the complete path of the jar package where the corresponding class is located.
Use the preceding method to find the jar package where "org. apache. commons. collections. map. TransformedMap" is located. The example is as follows.
Use of Apache Commons Collections components by weblogic of different versions
The following is the jar package of weblogic where "org. apache. commons. collections. map. TransformedMap" is located.
Weblogic version
Path of the jar package where the TransformedMap class is located
9.2
None
10.2.1 (weblogic 10g), 10.3.4 (weblogic 11g)
Modules/com. bea. core. apache. commons. collections_3.2.0.jar In the weblogic installation directory
12.1.3 (weblogic 12c)
Wlserver/modules/features/weblogic. server. merged. jar in the weblogic installation directory
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, which triggers the deserialization vulnerability.
0x04 vulnerability repair
How to fix vulnerabilities
Weblogic's default service port is 7001, which provides services for HTTP (S), SNMP, T3, and other protocols. Because weblogic uses one port for different protocols, the JAVA deserialization vulnerability cannot be prevented by limiting port access through the firewall.
In most application scenarios, you only need to be able to access the web application server over the Internet using the HTTP (S) protocol. For weblogic servers, in most cases, you only need to be able to access the HTTP (S) service provided by weblogic over the public network without accessing the T3 protocol.
In rare cases, O & M personnel need to use weblogic's T3 protocol:
Execute the weblogic stop script on the weblogic Server;
Script-based configuration of weblogic through WLST;
Write a program that uses the T3 protocol for weblogic status monitoring and other management functions.
The T3 protocol and HTTP protocol are both based on TCP protocol. The T3 protocol starts with "t3", and the HTTP protocol starts with "GET" and "POST". There are obvious differences between the two.
Therefore, only a specific server is allowed to access the T3 protocol of the weblogic Server and the JAVA deserialization vulnerability of weblogic can be fixed. Even if other weblogic classes are found to have JAVA deserialization vulnerabilities in the future, they can also be protected.
If weblogic is fixed to the username and password required to be sent when the T3 protocol is sent, the deserialization problem of weblogic is also fixed, but the password is stored on the weblogic client.
Invalid vulnerability repair methods
First, deploy the application to the non-management Server to determine whether its service port also provides the T3 protocol service.
AdminServer is the default Management Server of weblogic. After a non-management Server named "Server-test" is added, the Server information of weblogic is as follows. The management Server and the non-management Server use different listening ports to deploy j2ee applications on non-management servers. This allows the weblogic console and applications to use different ports to provide services.
After testing, the newly added non-managed Server listening port also provides the T3 protocol service and also has the JAVA deserialization vulnerability. Therefore, this method does not work for the JAVA deserialization vulnerability. However, you can separate the weblogic Console port from the application port. You can use the firewall to disable access to the weblogic console through the public network.
Websphere service port
Let's look at another widely used enterprise-level JAVA middleware: websphere service port. As you can see, the default HTTP service port of websphere applications is 9080, the default HTTPS service port of applications is 9443, the default HTTP service port of the console is 9060, and the default HTTPS service port of the console is 9043, the port for receiving JAVA serialized data is 8880. Therefore, as long as the public network is unable to access port 8880 of the websphere server through the firewall, the JAVA deserialization vulnerability of websphere can be prevented through the public network.
Impact of network devices on data packets
A company that has certain security requirements may select a deployment architecture when deploying a weblogic Server that needs to provide services to public network users (the firewall between different network regions in the Intranet has been omitted ).
The impact of network devices on data packets is as follows.
IPS
IPS can update protection rules. Some IPS have already set protection rules for JAVA deserialization vulnerabilities, blocking malicious JAVA serialized data packets.
Firewall
The firewall here refers to the traditional firewall, not the next generation firewall. It only cares about IP addresses and ports, does not care about packet content, and cannot block malicious JAVA serialized data packets.
WAF
Like IPS, blocking malicious JAVA serialized data packets depends on protection rules.
Web Proxy
Only performs proxy forwarding on the HTTP protocol, and does not perform proxy forwarding on the T3 protocol.
Server Load balancer
You can specify the protocol type for Server Load balancer. For security reasons, you should select HTTP protocol instead of TCP protocol. Only HTTP protocol is forwarded, and T3 protocol is not forwarded.
According to the above analysis, web proxy and Server Load balancer can stably ensure that only HTTP data is forwarded, and T3 data is not forwarded. Therefore, JAVA deserialization vulnerabilities can be protected.
If a web proxy or Server Load balancer is deployed in the path for accessing the weblogic server from the public network, the JAVA deserialization vulnerability attack initiated from the public network can be protected. This is why weblogic deserialization vulnerabilities of large companies are rarely discovered. The network architecture of weblogic determines that JAVA deserialization vulnerabilities cannot be exploited on the Internet.
Feasible vulnerability repair methods
Deploy Server Load balancer Devices
Server Load balancer is deployed on the outer layer of the weblogic Server to fix the JAVA deserialization vulnerability.
Advantages
Disadvantages
It has little impact on the system and does not need to be tested.
You need to purchase a device; cannot protect against JAVA deserialization vulnerability attacks initiated from the Intranet
Deploy a separate web proxy
Deploying a separate web proxy on the outer layer of the weblogic Server can fix the JAVA deserialization vulnerability.
Advantages
Disadvantages
Same as above
Same as above
Deploy web proxy on weblogic Server
Modify the listening port of weblogic on the weblogic console, as shown in.
Install web Proxy applications on the server where weblogic is located, such as apache and nginx, so that the web Proxy listens to the original weblogic listening port and forwards the HTTP request to the weblogic of the local machine, the JAVA deserialization vulnerability can be fixed.
Advantages
Disadvantages
It has little impact on the system and does not need to test the impact on existing system functions.
Cannot defend against JAVA deserialization vulnerability attacks initiated from the Intranet; it will increase the performance overhead of the server.
Deploy a web proxy on the weblogic Server and modify the listening IP address of the weblogic Server.
On the weblogic console, modify the weblogic listening port and the listening address to "127.0.0.1" or "localhost", as shown in. After modification, only the weblogic Server can access the weblogic service.
Install web Proxy applications on the server where weblogic is located, such as apache and nginx, so that the web Proxy listens to the original weblogic listening port and forwards the HTTP request to the weblogic of the local machine, the JAVA deserialization vulnerability can be fixed. The IP address of the web proxy listener must be set to "0.0.0.0". Otherwise, other servers cannot access the listener.
You need to change the IP address in the ADMIN_URL parameter in the weblogic stop script to "127.0.0.1" or "localhost". Otherwise, the Stop script is unavailable.
Advantages
Disadvantages
It has little impact on the system and does not need to test the impact on existing system functions. It does not need to purchase devices. It can defend against JAVA deserialization vulnerability attacks initiated from the Intranet.
Will increase the performance overhead of the server
Modify weblogic code
Weblogic handles the T3 protocol class as "weblogic. rjvm. t3.MuxableSocketT3 ". the weblogic classes of different versions are in different jar packages. For the method of finding the jar package of a class, see the previous section" determine whether weblogic uses the Apache Commons Collections component.
Use eclipse or other IDE To create a java project, create the weblogic. rjvm. t3 package, and create the MuxableSocketT3.java file. After locating the weblogic jar package of the weblogic. rjvm. t3.MuxableSocketT3 class, decompile it and add the corresponding jar package to the classpath of the created java project. Copy the decompiling code of the original MuxableSocketT3 class to MuxableSocketT3.java of the created java project. If the class in other jar packages is introduced, you need to add the corresponding jar package to the classpath of the java project.
Weblogic calls the dispatch method of the MuxableSocketT3 class when processing the T3 protocol. The original code of the dispatch method of weblogic 12.1.3 is as follows.
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 );
}
In this method, the processing of the Client IP address is restricted. If the client IP address that sends the T3 protocol data is not the allowed IP address, the connection is denied. The following is the code of the dispatch method after the limit is added.
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 );
}
Stop weblogic, replace the compiled MuxableSocketT3 *. class file with the jar package of MuxableSocketT3, start weblogic, and send the T3 Protocol packet to weblogic again. The following output is displayed.
It indicates that the code added above has been correctly run and has no impact on the normal functionality of weblogic, and can restrict the IP address of the client sending T3 data to fix the deserialization vulnerability.
When weblogic processes the HTTP protocol, it does not call the MuxableSocketT3 class. Therefore, the above modifications do not affect normal business functions.
You can use environment variables or configuration files to specify the IP address of the client that can send the T3 protocol and read it in the modified dispatch method. The example in this article only allows the local machine to send the T3 protocol. You need to change the IP address in the ADMIN_URL parameter in the weblogic stop script to "127.0.0.1" or "localhost". Otherwise, the Stop script is unavailable.
Advantages
Disadvantages
It has little impact on the system and does not need to test the impact on existing system functions. It does not need to purchase devices. It can defend against JAVA deserialization vulnerability attacks initiated from the Intranet, without increasing the performance overhead of servers.
There are commercial risks that may affect oracle Maintenance
The biggest problem with the above solution is that it may have an impact on oracle maintenance. However, I believe there are many companies that have not signed a maintenance contract with oracle. If you do not worry about the problems, you can use this method. If you can ask oracle to provide official patches, it would be better.
