![](\"https:\/\/varutra-1a3b6.kxcdn.com\/wp-content\/uploads\/2018\/09\/java-desc-1024x683.png\" "\\"java")
<\/p>\n<\/p>\n
![\"\"](\"https:\/\/www.varutra.com\/blog\/wp-content\/uploads\/2018\/09\/Desearlization-exploitation.png\")
<\/a><\/h3>\nIntroduction<\/strong><\/p>\n In this case study, we will not focus on how serialization vulnerabilities and how they work because there are plenty of articles on this subject. Instead, we will focus on how to reliably detect and exploit these issues. For this task, all we need to know is that the vulnerability depends on how Java deserializes serialized objects. Default Java classes responsible for the deserialization task first deserialize each serialized object and then try to cast the object to the expected Java class. So, all the received objects are deserialized, even if they are not instances of the expected types; in this case, after deserialization an exception arises when trying to cast the object to the expected type. What makes the issue so critical is the fact that the Java language offers the possibility to add custom code to the class definition that is executed upon deserialization.<\/p>\n For this reason, to be able to achieve Remote Command Execution (RCE) it is necessary to find a \u201cchain\u201d to an object that, once deserialized, allows the attacker to execute arbitrary Java code. Obviously, the class of the chosen object must be loaded in the ClassLoader of the target system. For this reason, usually some \u201cvulnerable\u201d libraries are needed to exploit this issue. These libraries expose the objects used for the exploitation, but the vulnerability itself lies in how Java deserializes the objects, and not in the libraries used for the exploitation. Removing only the \u201cvulnerable\u201d libraries does not protect completely against this issue, because new chains could be discovered and the vulnerability could be triggered anyway.<\/p>\n Once a deserialization issue is discovered, the ysoserial tool can be used for exploitation. This tool generates custom exploitation vectors, based on the \u201cvulnerable\u201d libraries loaded in the target system. In this article we will analyze how to discover and exploit Java deserialization vulnerabilities using a Burp Suite plugin we developed based on ysoserial: the Java Deserialization Scanner.<\/p>\n Installation<\/strong><\/p>\n The Java Deserialization Scanner plugin can be installed in two ways:<\/p>\n Serialization<\/strong><\/p>\n Serialization is the process of converting a complex object into a representation that can more easily be transmitted.<\/p>\n Deserialization is the process of recreating the object from that representation.<\/p>\n Several Java technologies are layered over serialization:<\/p>\n PoC:\u00a0Serialization Process<\/p>\n Trust Boundaries<\/strong><\/p>\n Web Application often contains multiple components & libraries each component may operate in one or more trusted domains.<\/p>\n Examples:<\/p>\n Deserialization of Untrusted Data<\/strong><\/p>\n In Java, reading a Data object from a serialized stream is as simple as:<\/p>\n ObjectInputStream in = new ObjectInputStream( inputStream );<\/p>\n return (Data)in.readObject();<\/p>\n The problem is that there\u2019s no way to know what object Deserializing before it gets decoded.\u00a0 So an attacker can serialize a bunch of malicious objects and send them to web application. Hence, the call of readObject (), it gets too late. The attacker\u2019s malicious objects have already been instantiated, and have taken over entire server.<\/p>\n Detection<\/strong><\/p>\n The detection of deserialization vulnerabilities is not always a simple task. By generating a payload with ysoserial and sending it to the target application, usually we may either get a Java Stack Trace (and if we are lucky we can discover the presence of the issue, but only with a knowledge of the vulnerable library targeted) or no verbose output at all.<\/p>\n Therefore, in order to reliably detect the presence of the vulnerability, we modified ysoserial to generate Java native sleep payloads instead of RCE payloads and we added these payloads to the Java Deserialization Scanner. For this task it is necessary to use Java native sleep payloads, because the Java sleep call is synchronous; executing a system sleep using the default RCE payloads generated by ysoserial would be useless, because they are asynchronous and we would get the response from the server before the end of the sleep command, regardless of the presence or the absence of the issue.<\/p>\n In the latest version of the plugin, we added two new methods to further improve detection:<\/p>\n In order to generate payloads that execute native Java DNS resolution, we modified ysoserial again. Usually, DNS resolution requests are the ones that are most likely to bypass corporate firewalls and consequently are a quite good detection method. In general, the timing method is more reliable and preferable, but the DNS method can be useful on unstable systems or highly delayed networks. Thanks to Burp Suite Collaborator, it is not necessary to have authority on a DNS zone, and everything can be done within the Burp Suite pro tool.<\/p>\n The CPU detection method is based on Wouter Coekaerts\u2019 SerialDOS work<\/a>: it is able to detect deserialization issues without the presence of any vulnerable library. The payload is based on a system object (java.util.HashSet) that employs many CPU cycles for the deserialization task. SerialDOS was created as a PoC of a Denial of Service (DoS) attack, but by decreasing the CPU cycles necessary for deserialization it can also be used as a detection method. This payload is very useful to detect if the application endpoint actually performs Java deserialization and if it implements a strict whitelist.<\/p>\n approach. If this check gives a positive result there is also the possibility that the target application implements a whitelist approach that permits HashSet class of java.util package. In this case the application is still vulnerable to DoS attacks (using full-power SerialDOS payloads).<\/p>\n Demonstration<\/strong><\/p>\n Now, let\u2019s demonstrate how to use desearlization plugin for detection. The detection is integrated in Burp Suite Active and Passive Scanner. By default, Time and DNS checks are added to Burp Suite scanner, but they can be disabled from the Configurations panel of the plugin, in the section \u201cAutomatic scanner configurations\u201d:<\/p>\n In order to reduce the number of requests executed by the Active Scanner, the checks added by the plugin are executed only if a serialized object is present in the original request. The payload is encoded with the same encoding found in the original request (for instance, if the serialized object is encoded in BASE64, the exploit vector will be encoded in BASE64 and so on). The currently supported encoding formats are:<\/p>\n The CPU detection method is not included by default in the active scan checks, because it must be used with caution: sending a huge number of \u201clight\u201d SerialDOS payloads may still cause problems on old or highly-loaded systems. In order to execute checks with custom insertion points or use the CPU payload, the plugin provides the \u201cManual Testing\u201d tab, in which the user can select the insertion point (currently only one at a time is supported) like in the Burp Suite Intruder, choose the check type (DNS, Time, or CPU), choose the preferred encoding and test the parameter. By selecting Sleep or DNS checks, the plugin tests all the supported vulnerable libraries, while with the CPU check the plugin will use a library-independent CPU payload. By default, detected issues are automatically added to the global issues of the host, but this behavior can be disabled in the \u201cConfigurations\u201d tab. In the same tab it is possible to enable verbose mode, in order to inspect the requests and their responses in the results pane.<\/p>\n The requests to test can be manually inserted in the Manual Testing tab or can be sent from other Burp Suite tabs using the contextual menu that opens with the right button of the mouse:<\/p>\n PoC: Menu for exploitation<\/p>\n The configuration of the Manual Testing tool is explained in the following PoC:<\/p>\n Exploitation<\/strong><\/p>\n The \u201cExploiting\u201d tab offers a comfortable interface to exploit deserialization vulnerabilities. This tab uses the ysoserial tool to generate exploitation vectors and includes the generated payload in a HTTP request. ysoserial takes as argument a vulnerable library and a command and generates a serialized object in binary form that can be sent to the vulnerable application to execute the command on the target system (obviously if the target application is vulnerable). The Exploiting tab supports the same encoding formats as the detection sections of the plugin.<\/p>\n Now, let\u2019s demonstrate how to use the plugin for exploitation. First, we need to open the \u201cConfiguration\u201d tab and insert the path where we have a copy of the ysoserial tool (ysoserial is necessary only for exploitation; detection payloads are already included in the plugin):<\/p>\n PoC: Configuration Tab<\/p>\n Step: 1 –<\/strong> Then, as we saw for manual testing, it is possible to insert the request manually or to send it from other Burp Suite tabs using the contextual menu that opens with the right button of the mouse. The user can then select the insertion point (currently only one at a time is supported) like in the Burp Suite Intruder, insert the ysoserial command (refer to the ysoserial manual for syntax) and click the correct \u201cAttack\u201d button, based on the desired encoding. The configuration of the \u201cExploiting\u201d tool is explained in the following PoC: PoC: Steps to Perform Manual Exploitation<\/p>\n Step: 2 –<\/strong> As shown in above PoC, we have used burp collaborator to check whether it is exploitable with the help of ping command. Burp Suite Collaborator is an external server added to Burp Suite in order to discover out-of-band vulnerabilities and issues that can be found only from external service interaction. It is a great tool and increases the power of Burp Suite Scanner a lot. However, a simple ping payload that does a DNS query confirmed that the system is indeed vulnerable.<\/p>\n PoC: DNS Query to Burp Collaborator Server<\/p>\n Step: 3 –<\/strong> For further exploitation, we can use windows commands like nslookup to check if any DNS query is received, so that we can confirm the vulnerability as shown in following PoC.<\/p>\n PoC: Nslookup<\/p>\n Step: 4 –<\/strong> As we know that, it is vulnerable for serialization attack so that we can craft our payload as harmful as possible and we have clue about that it is using windows server. Hence, we can craft the payload accordingly like we will send the command restart to server. Payload as motioned in the following PoC.<\/p>\n PoC: Restart Command sent to Windows Server<\/p>\n Step: 5 –<\/strong> After the command execution server will get restart and it will show service unavailable error. Our exploitation part will get successful. Attacker can do remote code execution (RCE) by using serialization vulnerability.<\/p>\n PoC: Server gets restart and it will display \u201cService Unavailable\u201d<\/p>\n Additional considerations<\/strong><\/p>\n Once the vulnerability is confirmed, the PenTester may need to do some trial and error of commands to execute in order to get a shell. Here are a few useful tips getting that working:<\/p>\n <\/p>\n Author,<\/p>\n Tanmay Nashte Varutra Consulting<\/em><\/p>","protected":false},"excerpt":{"rendered":" Introduction In this case study, we will not focus on how serialization vulnerabilities and how they work because there are plenty of articles on this…<\/p>\n","protected":false},"author":3,"featured_media":3204,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"inline_featured_image":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[259,140,284,289,121,272],"tags":[139,141,142,143,144],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n
\n
\n
\n
<\/a><\/p>\n\n
\n
\n
<\/a><\/p>\n\n
<\/a><\/p>\n<\/a>PoC: Steps for Detection of Serialization Vulnerability<\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n\n
\nAttack & PenTest Team<\/em><\/p>\n