# RealWolrdCTF 2021 Old System Writeup
Author: Voidfyoo of Chaitin Tech
## Overview
In 2021 RealWorldCTF (also referred to as RWCTF), I made a Java
deserialization challenge named `Old System`. Players need to exploit the
deserialization vulnerability in the environment of java 1.4.
You might think: "What? Java 1.4? This is too old, it's almost 20 years ago".
In fact, this challenge is modified based on a real system I encountered in a
penetration test last year. The key of this challenge is to examine the
players' understanding of the Java deserialization exploit gadget chain and
the ability to mine new gadget chains. If you are interested, please continue
reading.
## Challenge Analysis
### Start the game!
The description of `Old System` challenge is as follows：
```
How to exploit the deserialization vulnerability in such an ancient Java
environment ?
Java version: 1.4.2_19
```
The java version is specified in the description, and the webapp war is
provided in the attachment:
Only one servlet is defined in `WEB-INF/web.xml`:
```XML
Tomcat Demo WebappTomcat Demo Webapporg.rwctf.ObjectServletorg.rwctf.ObjectServletorg.rwctf.ObjectServlet/object
```
The request access path mapped by this servlet is `/object`, and the
corresponding class is `ObjectServlet`:
```Java
package org.rwctf;
import java.io.File;
import java.io.IOException;
import java.io.PrintWriter;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class ObjectServlet extends HttpServlet {
private ClassLoader appClassLoader;
public ObjectServlet() {
}
public void init(ServletConfig var1) throws ServletException {
super.init(var1);
String var2 = var1.getServletContext().getRealPath("/");
File var3 = new File(var2 + File.separator + "WEB-INF" + File.separator +
File.separator + "lib");
if (var3.exists() && var3.isDirectory()) {
File[] var4 = var3.listFiles();
if (var4 != null) {
URL[] var5 = new URL[var4.length + 1];
for(int var6 = 0; var6 < var4.length; ++var6) {
if (var4[var6].getName().endsWith(".jar")) {
try {
var5[var6] = var4[var6].toURI().toURL();
} catch (MalformedURLException var9) {
var9.printStackTrace();
}
}
}
File var10 = new File(var2 + File.separator + "WEB-INF" + File.separator +
File.separator + "classes");
if (var10.exists() && var10.isDirectory()) {
try {
var5[var5.length - 1] = var10.toURI().toURL();
} catch (MalformedURLException var8) {
var8.printStackTrace();
}
}
this.appClassLoader = new URLClassLoader(var5);
}
}
}
protected void doPost(HttpServletRequest var1, HttpServletResponse var2)
throws ServletException, IOException {
PrintWriter var3 = var2.getWriter();
ClassLoader var4 = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(this.appClassLoader);
try {
ClassLoaderObjectInputStream var5 = new
ClassLoaderObjectInputStream(this.appClassLoader, var1.getInputStream());
Object var6 = var5.readObject();
var5.close();
var3.print(var6);
} catch (ClassNotFoundException var10) {
var10.printStackTrace(var3);
} finally {
Thread.currentThread().setContextClassLoader(var4);
}
}
}
```
Note that the HTTP request body part is deserialized in the `doPost` method of
the `ObjectServlet` class, so there is a deserialization vulnerability.
When designing this challenge, in order to ensure the difficulty, I designed a
`URLClassLoader` (that is, the `appClassLoader` field of the `ObjectServlet`
class) for the entire deserialization process. The purpose is to limit the
classes that can be loaded by deserialization within the scope of the JRE
standard library and the current webapp (`/WEB-INF/classes`, `/WEB-INF/lib/`),
players are not allowed to consider Tomcat's global dependency library. The
design purpose of the `ClassLoaderObjectInputStream` class is also the same:
```Java
package org.rwctf;
import java.io.IOException;
import java.io.InputStream;
import java.io.ObjectInputStream;
import java.io.ObjectStreamClass;
import java.io.StreamCorruptedException;
import java.lang.reflect.Proxy;
public class ClassLoaderObjectInputStream extends ObjectInputStream {
private final ClassLoader classLoader;
public ClassLoaderObjectInputStream(ClassLoader var1, InputStream var2) throws
IOException, StreamCorruptedException {
super(var2);
this.classLoader = var1;
}
protected Class resolveClass(ObjectStreamClass var1) throws IOException,
ClassNotFoundException {
return Class.forName(var1.getName(), false, this.classLoader);
}
protected Class resolveProxyClass(String[] var1) throws IOException,
ClassNotFoundException {
Class[] var2 = new Class[var1.length];
for(int var3 = 0; var3 < var1.length; ++var3) {
var2[var3] = Class.forName(var1[var3], false, this.classLoader);
}
return Proxy.getProxyClass(this.classLoader, var2);
}
}
```
### Ysoserial gadget analysis
Ok, now it is clear that this challenge is a deserialization vulnerability.
The range of classes that can be loaded by deserialization is the JRE standard
library, `/WEB-INF/lib/` and `/WEB-INF/classes/` jar/class.
There are 4 jar packages in the `/WEB-INF/lib/` directory:
If you know about Java deserialization vulnerabilities, then you must know
ysoserial, a Java deserialization exploit tool. Ysoserial has integrated a lot
of Java deserialization gadget chain payload, here is the source code address
of this project: https://github.com/frohoff/ysoserial
You can directly run ysoserial to see which gadget chain payload can be
generated:
Experienced players should directly notice the two libraries `commons-
collections` and `commons-beanutils`. The usage of these two libraries is very
extensive, and we often deal with them whether it is penetration testing or
code auditing. So at first glance, you might think that these two libraries
happen to exist in the webapp dependencies, so just pick one and break
through?
But you should note that this system is very old, so in fact its dependent
library version is also very old.
For example, the version of the `commons-collections` library is 2.1
The core of the `commons-collections` library's deserialization gadget chain
lies in `Transformer`, such as `InvokerTransformer` or
`InstantiateTransformer`, but these classes do not exist in the 2.1 version of
the `commons-collections` library:
Therefore, the gadget chain of the `CommonsCollections` series in ysoserial
definitely does not work.
Now let's look at `CommonsBeanutils`.
Some novices may be confused by the dependency library version of the gadget
chain marked in ysoserial, thinking that a certain chain can only work under
the corresponding marked dependency version, which is not the case. Like the
`CommonsBeanutils1` chain in ysoserial, the dependency version marked by the
author is:
```
commons-beanutils:1.9.2, commons-collections:3.1, commons-logging:1.2
```
But these versions actually reflect only the library version used by the
author of ysoserial when writing and using them, and the actual scope of
influence may not be limited to this. Therefore, before rushing to draw
specific conclusions on the dependency version, let's take a look at how this
chain is constructed in the source code in ysoserial:
```Java
package ysoserial.payloads;
import java.math.BigInteger;
import java.util.PriorityQueue;
import org.apache.commons.beanutils.BeanComparator;
import ysoserial.payloads.annotation.Authors;
import ysoserial.payloads.annotation.Dependencies;
import ysoserial.payloads.util.Gadgets;
import ysoserial.payloads.util.PayloadRunner;
import ysoserial.payloads.util.Reflections;
@SuppressWarnings({ "rawtypes", "unchecked" })
@Dependencies({"commons-beanutils:commons-beanutils:1.9.2", "commons-
collections:commons-collections:3.1", "commons-logging:commons-logging:1.2"})
@Authors({ Authors.FROHOFF })
public class CommonsBeanutils1 implements ObjectPayload