Here’s my write-up for VulnNet Node, a CTF challenge created by TheCyb3rW0lf.
Write-up
I deployed the box using TryHackMe’s interface and scanned the host using nmap:
I also ran a full port scan but this was the only port open. Node.js running Express, hosting a webpage.
I took a look at the website in my browser and found a fairly simple website with some sort of account functionality.
I followed the link to the login page.
I tried a few different inputs but couldn’t make anything interesting happen, so I took a look at the source code.
The form wasn’t wired up to anything. Weird. At this point, I had already starting capturing traffic with Burp so I went back to Burp and took another look at the requests and responses.
I could see a cookie that was being sent from my browser to the application on requests. Burp decoded the cookie from base64 which showed it contained some JSON which (I presumed) was being parsed by the application in some way. I modified the contents of the cookie and could see my changes reflected in the response. I wondered if there was some sort of template injection so I tried a few different things to trigger an error, in hopes that an error might give me a bit more to work with.
I set the cookie’s “username” value to “\” and the following error was returned:
This error showed that the application was using a library called “node-serialize”. I began researching different exploits and vulnerabilities that might be present within the node-serialize library, and came across an interesting blog post. This blog post summarised an exploit present in node-serialize, and even provided a python script to generate a payload which would initiate a reverse shell. I downloaded the script, ran it, set up netcat to listen for the connection back, and sent the payload.
I had successfully gained shell access to the machine. I took a look around and found another user on the box: “serv-manage”. I also ran sudo -l to see what the “www” user could do.
GTFOBins documented a way to initiate a shell via NPM. If I could do this, I would get shell access as the “serv-manage” user.
After a few attempts (and a fair bit of mistyping) I had a shell.
I then took a look at what sudo privileges “serv-manage” had, and found that they had access to run three systemctl commands and edit a couple of files in /etc/systemd/system. If I could alter what these scripts were executing, I could potentially get a remote shell as the root user.
I upgraded my shell because I knew I would need to use an editor to edit these files. For future me:
On the remote machine:
python3 -c "import pty;pty.spawn('/bin/bash')"; export TERM=xterm
ctrl + Z to background the session
On my machine:
stty raw -echo; fg
vulnnnet-auto.timer ran vulnnet-job.service every 30 minutes. The first thing to do was to change vulnnnet-auto.timer to run every minute, just to speed things up a bit. The second thing to do was to change the command vulnnet-job.service was executing. I set up netcat to listen on a different port on my machine and had vulnnet-job.service initiate a remote connection back to my machine.
I saved the files, ran the commands, waited a few seconds, and I had root!
>> Home