In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-02-24 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Network Security >
Share
Shulou(Shulou.com)05/31 Report--
How to resolve Java deserialization vulnerabilities, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.
I. basic concepts
Java serialization: the process of converting Java objects in memory into byte sequences, which can be understood as taking a snapshot of Java objects. Through serialization, it is convenient to save Java objects in memory, files, databases, and other media, as well as to transfer and share Java objects in the network.
Java deserialization: the reverse process of Java serialization, the process of restoring a sequence of bytes to a Java object.
Serialization / deserialization is not a unique feature of the Java language. Dynamic languages such as PHP, Python, and Ruby also have similar features. The main purposes of serialization / deserialization are:
1. Remote procedure call (RPC): provides Java object data interaction between different systems or processes.
2. Cache / persistent storage: Java objects can be cached or stored in local files, disks, databases and other media
3. Session tokens: interactive data for scenarios such as HTTP cookies, HTML form form parameters, API authentication tokens, etc.
In Java, serialization / deserialization operations are mainly implemented by the java.io.ObjectOutputStream.writeObject (Object) method and the java.io.ObjectInputStream.readObject () method; in user code, custom actions can be implemented by overriding the above methods.
Java serialized data format
Reference document: https://docs.oracle.com/javase/8/docs/platform/serialization/spec/protocol.html
The serialized data of the Java object is a binary stream, starting with a fixed 0xaced and 0x0005, which can be used to identify the deserialized entry point in the application system during penetration testing. (base64 encoding for 0xaced 0005 begins with rO0AB, and Java serialized data usually transmitted in Web applications is encoded by base64.)
Example of Java serialization data:
00000000: aced 0005 7400 0d48 656c 6c6f 2c20 776f.... t..Hello, wo00000010: 726c 6421 rld!
The Java object serialization dump tool is provided on Github, which can parse the serialized data of Java objects. For more information, please refer to https://github.com/NickstaDB/SerializationDumper. For example, the result of parsing the above binary data is as follows:
Second, loophole principle
The cause of the Java deserialization vulnerability is that the Java application receives serialization data from the user and attempts to deserialize it; if an attacker constructs malicious input and causes the deserialization process to produce unexpected objects, it can lead to a variety of consequences, including remote code execution.
Java serialization / deserialization code demo
The following code shows that a string is serialized to a local file, and then the serialized string is recovered from the file.
Package orz.vuln.poc;import java.io.FileOutputStream;import java.io.ObjectOutputStream;// serializes the String object and saves it to the data.ser file public class Serialization {public static void main (String [] args) throws Exception {String text = "Hello, world!"; FileOutputStream fos = new FileOutputStream ("D:/data.ser"); ObjectOutputStream oos = new ObjectOutputStream (fos); oos.writeObject (text); oos.close () Fos.close ();}}
Serialized data:
Package orz.vuln.poc;import java.io.FileInputStream;import java.io.ObjectInputStream;// deserializes the data in the data.ser file into Java objects: public class Deserialization {public static void main (String [] args) throws Exception {FileInputStream fis = new FileInputStream ("D:/data.ser"); ObjectInputStream ois = new ObjectInputStream (fis); String text = (String) ois.readObject (); fis.close (); ois.close () System.out.println (text);}}
Execution result:
Here, you can control the value of the deserialized string by modifying the local file data; for example, modify the data.ser as follows:
00000000: aced 0005 7400 0845 7669 6c54 6578 74.... t..EvilText
Execute the deserialization code, resulting in:
Further Java serialization / deserialization
In actual development, it is more common to deserialize custom class objects by implementing the Serializable interface and overriding the readObject () method to accomplish more operations. The following code example shows that we implement the Serializable interface by customizing the Test class and override the readObject () method. In the readObject () method, we customize the output string "Oops..." And pop-up calculator operation.
Package orz.vuln.poc;import java.io.FileInputStream;import java.io.FileOutputStream;import java.io.ObjectInputStream;import java.io.ObjectOutputStream;import java.io.Serializable;public class DemoCode {public static void main (String [] args) throws Exception {Test test = new Test ("calc.exe"); FileOutputStream fos = new FileOutputStream ("D:/object.ser") ObjectOutputStream oos = new ObjectOutputStream (fos); oos.writeObject (test); oos.close (); fos.close (); FileInputStream fis = new FileInputStream ("D:/object.ser"); ObjectInputStream ois = new ObjectInputStream (fis); Test test2 = (Test) ois.readObject () Ois.close ();}} class Test implements Serializable {private String cmd; public Test (String cmd) {this.cmd = cmd;} / / override the readObject () method private void readObject (java.io.ObjectInputStream in) throws Exception {in.defaultReadObject () System.out.println ("Oops..."); java.lang.Runtime.getRuntime () .exec (cmd); / / trigger code execution, simulate call chain}}
Execution result:
The call stack is as follows:
DemoCode [Java Application] orz.vuln.poc.DemoCode at localhost:53445 Thread [main] (Suspended (entry into method exec in Runtime)) Runtime.exec (String) line: 345 Test.readObject (ObjectInputStream) line: 38 NativeMethodAccessorImpl.invoke0 (Method, Object) Object []) line: not available [native method] NativeMethodAccessorImpl.invoke (Object, Object []) line: 57 DelegatingMethodAccessorImpl.invoke (Object, Object []) line: 43 Method.invoke (Object, Object...) Line: 601 ObjectStreamClass.invokeReadObject (Object, ObjectInputStream) line: 1004 ObjectInputStream.readSerialData (Object ObjectStreamClass) line: 1891 ObjectInputStream.readOrdinaryObject (boolean) line: 1796 ObjectInputStream.readObject0 (boolean) line: 1348 ObjectInputStream.readObject () line: 370 DemoCode.main (String []) line: 22 D:\ Tools\ Java\ jdk1.7.0_21\ jre\ Bin\ javaw.exe (5:13:24, 17 March 2021)
As you can see from the above results, deserialization invokes the overridden readObject () method, which performs custom string output and pop-up calculators. If a code execution utilization chain can be constructed in the rewritten readObject () method, a remote code execution vulnerability exists. Of course, in the actual development process, it is impossible to write code like java.lang.Runtime.getRuntime (). Exec (cmd) directly inside the readObject () method like the above code. But there is not much difference, but the actual call chain is more complex. By controlling the deserialized input data, combined with Java reflection invocation mechanism, we can find a call chain that can build remote code execution, and dynamically call java.lang.Runtime.getRuntime (). Exec () to complete code execution.
You can compare the call stack with a JDK7u21 deserialization vulnerability, but the call process is more complicated:
Orz.vuln.poc.JDK7u21Exploit at localhost:53452 Thread [main] (Suspended (entry into method exec in Runtime)) owns: TemplatesImpl (id=46) Runtime.exec (String) line: 345 EvilCodes. () line: 17 NativeConstructorAccessorImpl.newInstance0 (Constructor) Object []) line: not available [native method] NativeConstructorAccessorImpl.newInstance (Object []) line: 57 DelegatingConstructorAccessorImpl.newInstance (Object []) line: 45 Constructor.newInstance (Object...) Line: 525 Class.newInstance0 () line: 374 Class.newInstance () line: 327 TemplatesImpl.getTransletInstance () line: 380 TemplatesImpl.newTransformer () line: 410 NativeMethodAccessorImpl.invoke0 (Method, Object, Object []) line: not available [native method] NativeMethodAccessorImpl.invoke (Object) Object []) line: 57 DelegatingMethodAccessorImpl.invoke (Object, Object []) line: 43 Method.invoke (Object, Object...) Line: 601 AnnotationInvocationHandler.equalsImpl (Object) line: 197 AnnotationInvocationHandler.invoke (Object, Method, Object []) line: 59 $Proxy0.equals (Object) line: not available LinkedHashMap (HashMap) .put (K, V) line: 475 LinkedHashSet (HashSet) .readObject (ObjectInputStream) line: 309 NativeMethodAccessorImpl.invoke0 (Method, Object) Object []) line: not available [native method] NativeMethodAccessorImpl.invoke (Object, Object []) line: 57 DelegatingMethodAccessorImpl.invoke (Object, Object []) line: 43 Method.invoke (Object, Object...) Line: 601 ObjectStreamClass.invokeReadObject (Object, ObjectInputStream) line: 1004 ObjectInputStream.readSerialData (Object, ObjectStreamClass) line: 1891 ObjectInputStream.readOrdinaryObject (boolean) line: 1796 ObjectInputStream.readObject0 (boolean) line: 1348 ObjectInputStream.readObject () line: 370 JDK7u21Exploit.main (String []) line: 91 III
The root cause of the Java deserialization vulnerability is that the ObjectInputStream.readObject () method does not detect and restrict the generated object types when deserializing, and when such deserialization vulnerabilities exist in some public class libraries, it will have a significant impact. For example, some classes implemented in Apache Commons Collections can be deserialized to implement arbitrary code execution. The deserialization vulnerabilities in WebLogic, WebSphere, JBoss, Jenkins and OpenNMS applications can be exploited because of the use of the Apache Commons Collections class library in these applications. It is as if there is a shared library with a fixed loading address in a system that turns on the defense of ASLR address randomization, or similar to the linked libraries used in the C language. when these inventories are vulnerable, it will have a significant impact on the applications that use these libraries.
Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow 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.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.