Phobos
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 3000 192.168.175.131
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-01 19:42 +08
Nmap scan report for 192.168.175.131
Host is up (0.17s latency).
Not shown: 65534 filtered tcp ports (no-response)
PORT STATE SERVICE
80/tcp open httpWeb Enumeration
Port 80 hosts the default Apache2 page:
I ran a gobuster scan and found a few directories:
The /svn directory requires credentials:
Using admin:admin doesn't work for this. When we view the traffic in Burpsuite, we can see that the Authorization header is added and it uses the Basic Base64 method of authenticating users.
I ran another directory scan with wfuzz this time using this header, and managed to find one directory:
This directory just contains some interesting files:
Source Code Review -> RCE Point
These appear to be files for the application hosted at the other directory of /internal. One of the files users/views.py contains some interesting information:
This bit of code does not validate the name of the file that is being deleted. In this case, we can attempt to upload a file with a name to inject code.
However, when trying to exploit this thing, the internal website does not seem to be working with all the links being broken.
This made me think more about WHERE exactly this site is being hosted.
Svn -> Domain Discovery
Earlier we saw the /svn directory and just enumerated it as per normal. However, 'svn' is short for Subversion, which is a version control application that can be enumerated with the command svn.
We might be able enumerate the logs of the site, and it worked!
We can find the differences between the 2nd and 3rd revision of the repository:
There's a hidden domain here! We can add that to our /etc/hosts file and enumerate that.
Internal Website -> Account Takeover
The website led us to this login page:
Remember that we have the source code of this website, so we can find all the endpoints at the views.py file we saw earlier. The /register directory lets us register a new user.
We can then login to the site! For some reason it's not loading the visual elements right on my machine...
There are a few functions in this site. We know that the 'Submission' one is vulnerable, but we need some kind of administrator account first. So we can view the 'MyAccount' function:
When the traffic is intercepted, it includes a username parameter:
Maybe we can change the username to something else, so I changed it to admin and found that I could login as the admin user!
LFI Firewall Rules -> Shell
The administrator had a few things different, such as the 'Submissions' function being replaced with a submission reviewer:
When we choose a report and view it, it sends this HTTP POST request:
This looks vulnerable to LFI, and testing it reveals that it works!
Earlier, the repository comments mentioned something about a UFW firewall. A quick google search on its files reveal that the rules are stored at /etc/ufw/user.rules, which can be read using the LFI:
Here are the rules:
This machine seems to only accept connections using port 6000, which is probably we need to use for our reverse shell. Now that we know what port to use, the only thing left is to abuse the RCE via the Delete File function.
Here's the request I sent:
This wold give us a shell as www-data:
The user flag is within the /var/www directory.
Privilege Escalation
MongoDB Creds -> Root
We can enumerate the ports that are listening on the host since nmap only picked up on HTTP port 80.
It seems that port 27017 for MongoDB is open on the machine. We can use chisel to port forward this. Remember that port 6000 is the port allowed through the firewall! So use that for HTTP and the port to connect to!
We can then access and enumerate the MongoDB instance from our machine:
There are some hashes present, and all 3 are crackable:
The last password was for the user root, and we can try an su, which ends up working:
Rooted!
Last updated