CTF Walkthrough: Celestial
The following writeup shows the process I used to capture the user and root flags on Celestial machine at @ 10.10.10.85
This document contains my field notes I took when I was working through the box.
My way of thinking
The first step consists of the reconnaissance phase as ports scanning, banner grabbing, misconfigurations and so on. The second one to find the weakness, then, the attack itself, finally the privileges escalation called “post exploitation phase”.
Personal notice: The post exploitation was a quite complex, I will do my best to explain how I rooted the “Celestial machine”.
During this steep we are going to identify the target to see what we have behind the IP address.
BTW, the results are above:
The remote system is a Linux machine.
On the system we have a web server under an uncommon port. It’s running under Node Js.
With these elements in hands, we are going to check the service discovered. To do that, we opened our browser.
Step 1.1 The Web server:
At first, we’ve got a blank page!! WTF is this ;)
The reflex is to look at the source code to find an interesting stuff. It could be nice ;)
We have a nice message. In the source code we have “hey dummy 2 +2 is 22 “whereas in normal way, we’ve got a nice error.
Enumeration of the server
At this point of the challenge, we know that we have a NODE JS server. In normal way we can’t see nothing. So, to help us, we are going to fire up a proxy — BURP — to see in deep what it happens.
Ok. At this point break, we have the request under the engine. We can see that we have a cookie with a profile.
The next step is to send the request to the repeater option to play with it.
Just for information, the decoded payload (the next step)
The flaw of our CTF is the deserialization of the class. With it, we are going to produce an RCE on the remote machine.
Further more details:
The cookie named profile from the HTTP request, perform base64 decode of the cookie value and pass it to unserialize () function. The cookie is not secure and can be crafted by a hacker.
In this section, we are going to talk about how to exploit the vulnerability.
We are going to use this tool that allows us to craft our payload:
Let’s encode our payload ;)
Ok, our payload is now crafted. The next step is to send it to the server. To do this step, we are going to use BURP. So, let’s roll.
Now we have our payload correctly setup, we have to setting up the reverse shell to our machine.
Before launching NETCAT, we have to forward the request to server by “GO” bottom” on burp.
We are going to setting up NETCAT on port 4444 and waiting for connections …
The intrusion : We have an intrusion Houston !!!
Now we have a remote shell with Netcat. The goal now is to catch the user flag. To do that, I made a nicer shell.
We are in! Let’s configure the basic of our shell in order to have more facilities to work with.
Once in we had to find some flags. The first one was the user flag, and the second one, the root flag of the machine.
- The user flag was easy because we found the user directory and the text file were in it.
- The root flag (system admin), more complex! One indication was given ;)
Catch the user flag
When we got in, we were at the root of the website. So, the only solution for me was to find the user directory and to catch the flag.
Always know where you are and where you want to go!!
So, searched the location of the user flag on the system with the following command:
Catch the root flag
The way of root, I’ve made some stuff like listing the processus which are running under root.
Then, I investigated on the crontab of the system. It’s a good way because I’ve seen that there is a task on the server and some action was done in background.
As you can see, a simple script is running on the server under root.
So, by running this script, we emulate the root user. So, that’s what I did.
So, to catch the root flag, we have to do this command