Vulnversity - TryHackMe Room
The link for this lab is located here: https://tryhackme.com/room/vulnversity
In this room, we will learn about active reconnaissance, web application attacks and some basic privilege escalation to hack into a vulnerable machine.
Task 2 - Reconnaissance
First of all, we need to gather basic information about the target machine. For me, this starts with a very simple all ports scan - just to identify any open ports. This reveals that 6 ports are open on our target with little information about what is running on them.
The next step is to gather service information and get more details about each service if possible. For this, I run a scan to gather OS information, service detection and some basic Nmap scripts along with the specified ports found in the previous scan (saves time scanning all 65,535 ports with service detection).
This reveals a variety of information including an FTP version (3.0.3), Samba running on port 139/445 which indicates to me a Linux machine, Squid HTTP proxy running on port 3128 which is interesting and an HTTP server running on port 3333 via Apache.
It also reveals to us that the machine is likely a Linux machine running Ubuntu - seen from various header information including HTTP.
Task 3 - Locating Directories using GoBuster
Navigating to the website reveals an interesting web page.
Clicking on any links we see does not reveal any new page which is intriguing. This tells me there is a hidden directory somewhere. To find these hidden directories, we can use GoBuster - a directory busting tool.
To use it effectively, I use the following syntax which specifies directory busting (dir) followed by the URL and the wordlist to use - I used a dirbuster wordlist which proves successful most times.
Looking at the results, it reveals some directories including standard ones like images, css and js. The interesting one here is /internal. Navigating to that page reveals an upload page.
Task 4 - Compromise the Web Server
Looking back at the scan results, we saw that this server is running Apache. Doing a quick Google search reveals that PHP is the programming language commonly used with Apache. From this, we can try uploading a PHP file. If successful, we could then navigate to it and execute malicious code.
Trying to upload a simple PHP file with some random text inside reveals an error message that the extension is not allowed. Interesting…..
Are there any other php extensions? Doing a quick Google search reveals there are multiple valid PHP extensions that can be used for PHP.
Knowing this, we can create a list of all the extensions and use Burp to test each one quickly and effectively.
First, we intercept a request for an upload we make.
Once intercepted, we can send that request to Intruder and choose the payload we want to change for each request - in this case the “.php” part of the request ONLY.
Once set, we can navigate to the payload options and load the txt file created with the extensions inside as our payload and run the attack.
Running the attack should reveal that the “.phtml” file comes back with a different length, indicating it worked or something changed. Unfortunately, in my scenario, this was not working so I decided to do it manually.
Instead, I simply went through and uploaded each file until a Success message popped up after uploading the “.phtml” file.
Knowing that we can successfully upload a PHP file with this extension, we can use a PHP reverse shell and simply change the extension to “.phtml”. We can use this php reverse shell and simply change the IP and port in the code to your IP and a port of your choosing - I chose 8888.
Once changed, we can simply rename the file from .php to phtml to match the extension that is allowed to be uploaded.
Then, we can simply upload it to the site and receive a success message.
To catch the reverse shell, we must be running a netcat listener on the same port as the one in the code you changed.
Once listening, simply navigate to the /uploads/php-reverse-shell.phtml and check the netcat listener - you should have received a reverse shell.
Next, I decided to stabilize the shell a little more using the following.
Once stabilized, I check the contents of the “/home” directory to see any users on the system - a user called bill has a home directory located there.
Inside the /home/bill directory there is a user.txt file which contains the user flag.
Task 5 - Privilege Escalation
With this shell, the next thing to do is try to gain root privileges. There are multiple ways to do this but I decided to run LinPeas on the system to see if it could identify anything.
First, I had to get LinPeas on the target by hosting the linpeas.sh file through a Python3 web server on my local machine
Once hosted, I used the wget command to download linpeas to the target machine inside the /tmp directory since /tmp is normally world readable and writable allowing us to create, modify and download files there.
Once on the system simply give it executable permissions using chmod.
And then run it. Once it has ran, looking through the results, we see a critical file having SUID permissions - systemctl.
Navigating to GTFOBins and searching for systemctl with SUID permissions reveals a way to get a possible root shell.
Simply follow the instructions on GTFOBins - this way creates a service that systemctl is going to start for us and that service will be running with elevated privileges
Systemctl is a controlling interface and inspection tool for the widely-adopted init system and service manager systemd. Systemd in turn is an init system and system manager that is widely becoming the new standard for Linux machines.
Systemd initializes user space components that run after the Linux kernel has booted, as well as continuously maintaining those components throughout a system's life cycle. These tasks are known as units, and each unit has a corresponding unit file.
We can create our own unit file and let systemd start it. Normally systemctl will look for unit files in the default folder, which is /etc/system/systemd but we do not have permission to write to that folder.
We can create a unit file and let systemctl start it via an environment variable.
First, we create a variable which holds a unique file.
eop=$(mktemp).service
Then, we create a unit file and write it into the variable
$ echo '[Service]
> ExecStart=/bin/sh -c "chmod +s /bin/bash"
> [Install]
> WantedBy=multi-user.target' > $eop
Inside the unit file, we entered a command which will let shell execute the command chmod and add a SUID bit to the /bin/bash file. Finally, we use the /bin/systemctl program to enable the unit file
/bin/systemctl link $eop
/bin/systemctl enable --now $eop
Once all ran, checking the permissions on /bin/bash reveals it has the “s” bit for the user and group - which is root. This means we can run “bash -p” to keep the privileges of the BASH shell effectively giving us root privileges
Running bash -p returns us a root shell with effective user and group IDs of root.
Once in, navigate to /root and grab the root.txt flag.
