Ysoserial Fix Download Jar
Eufemia Graybill
Ysoserial works well enough, but I like to optimize my exploitation steps whenever possible. This includes removing the need to go back and forth between the command line and Burp. So I created the Burp extension Java Serial Killer to perform the serialization for me. It essentially is a modified Repeater tab that uses the payload generation from ysoserial.
I found several overviews of specifically how to attack JSF ViewState like this and this. I also found a tool for payload generation, ysoserial (which not only is a useful tool, but fits the Batman theme).
Since CommonsCollections6 (and most of other gadgets) make heavy use of the Java Reflection API via java.lang.reflect.Field.setAccessible(boolean flag), this restriction has to be taken into account accordingly. Oracle already gave the solution above. Note that the --add-exports parameter does not allow "deep reflection", i.e. access to otherwise private members. So, creating the payload using java --add-opens java.base/java.util=ALL-UNNAMED -jar target/ysoserial-0.0.6-SNAPSHOT-all.jar CommonsCollections6 "java.nio.file.Files.createFile(java.nio.file.Paths.get(\"/tmp/RCE\"));" works just fine and gives code execution in insecure deserialization sinks again.
There exists a Java Object in the Apache Commons FileUpload library that can be manipulated in such a way that when it is deserialized, it can write or copy files to disk in arbitrary locations. Furthermore, while the Object can be used alone, this new vector can be integrated with ysoserial to upload and execute binaries in a single deserialization call. This may or may not work depending on an application's implementation of the FileUpload library.
The ClassFilter was added after the SECURITY-218/CVE-2015-8103 vulnerability disclosure in November 2015. It was one of the 0-day exploits that was released with ysoserial. The patch blocks the deserialization of classes that are in specific classpaths. The list contains classpaths that are used by the ysoserial payloads, like the classpath of the Apache Commons Collections. As you might have noticed, Jenkins is only doing a blacklisting with this patch. If you have a security background, this should be a red-flag for you and we will see that this blacklisting was bad decision.
Insecure Deserialization in Java occurs when a malicious user tries to insert a modified serialized object, leading to an arbitrary code execution vulnerability. This blog will take you through the process of identifying serialized objects in Java applications, selecting a suitable gadget chain, and exploiting the vulnerability using tools such as ysoserial. Stay tuned as we dig deeper into the world of Insecure Deserialization in Java Applications
A post on the ysoserial gitter lead me to this article which was enormously helpful. As per the article, after JEP290 (which affects the JDK version i was running) the JDK has builtin filters for the RMI registry and DGC (which JRMP uses). These filters only allow specific classes to be deserialized. So this explains why none of the regular Ysoserial gadgets worked via the RMIRegistry exploit.
A quick bit of bash later I had it trying every payload ysoserial has to offer, resulting in a notepad.exe spawning! As a sidenote, calc.exe did not spawn even with a working exploit. I assume this is because it is now a UWP app?
This creates a payload of 4205 bytes. However, the maximum size allowed for a cookie is 4096 bytes. Unfortunately, this means when we send it, it never actually reaches the target method and is filtered out somewhere along the way. Rather than tracking down the code and determining if it was possible to send a cookie greater than 4096 bytes through to the function, we instead chose to use the Hibernate2 payload in ysoserial.
The second Hibernate ysoserial payload (Hibernate2) accepts an rmi address instead of a command to execute, and it is less than the cookie size limit. So even after it is encoded, the payload fits under the max cookie limit. So we can essentially use it as a stager, to then provide the full Hibernate2 payload to the server to obtain code execution.
Now we can send the initial payload to the target. The hosting server will see a connection back from the target, it will serve the specified ysoserial payload, and the payload will be deserialized on the target achieving remote code execution. The Hibernate1 payload also needs to be encoded properly, which we can do using the same Java libraries that decode it, as follows:
Append the encoded object to the HTTP request as the `oauth2_authorization_request` cookie data and send the request to the server, as in Figure 7. We will see the callback on the staging server from the ysoserial JRMPListener, and then the payload runs, the shell command executes, and the file is created (see Figure 8).
df19127ead