This will be the 3rd machine that I will be attempting for my OSCP preparation. I have to be honest here, I got stuck on an easy challenge but let’s get into it!
First, the target has the IP address of 192.168.181.150 identified through a host scan with nmap along with the -sn switch.
A port scan is then done with the -sV switch for a version scan, -Pn switch to assume all hosts are up and the -sC switch to load the default scripts for nmap.
The results show ports opened for a mail service, an SMB service, a filtered web server and as well for a filtered ssh port. This may indicate a knockd service running on the target machine.
The scripts loaded also detected a robots.txt file, which prevents search engines from indexing specified pages on another web server running on port 8080.
Having a web server, the next step is to perform directory brute-forcing on the web server using ffuf. The -e switch is also used to find file names. The results also show a robots.txt file being found on the web server.
Going to the robots.txt on the web server hosted on port 8080 shows a directory called /tryharder/tryharder.
Going to /tryharder/tryharder reveals a base64 string denoted by the “==” at the end of the string.
Decoding the string reveals that the passwords for the target machine might be vulnerable to brute-force attacks.
Using enum4linux, the user qiu is allowed to access the SMB service. Connecting to the SMB service with qiu as the username and password as the password allows us to access the SMB service.
Within the SMB service, the knockd.conf file was found. The configuration file reveals the ports needed to open up the other web service and the ssh port.
Using hping the specified ports within the knockd.conf file were pinged to open up the web service on port 80 and the ssh port on port 22.
Going to the website hosted on port 80 reveals nothing.
However, performing a directory brute-force reveals some web pages worth going to.
Within /time, the page displays the current date and time. The values of this page update every now and then.
/login.html reveals nothing of use.
Within robots.txt reveals two directories hidden from search engines, /mercy and /nomercy.
/mercy reveals nothing of use.
/nomercy reveals a RIPS scanner page with the version of 0.53.
Knowing the system’s name and version, searchsploit is used to find exploits targeting this system on exploitdb.
The first exploit seems useful for displaying local files or having a local file inclusion vulnerability. This vulnerability allows the attacker to view any file on the target machine.
To proof that the exploit works, the file parameter was replaced with /etc/passwd file. Loading the page shows the users that are on the target machine. However, after discovering that the exploit works, I was stuck.
What wasn’t mentioned before was that on the website hosted on port 8080, the index page of that webserver was the default page of Apache Tomcat. What I didn’t see because I was just concentrating on getting the flag and not viewing any information carefully is that on the default Apache Tomcat page, the file for configuring usernames and passwords for the platform was mentioned.
Viewing the file with the exploit mentioned reveals two users, thisisasuperduperlonguser and fluffy. These usernames are accompanied by their passwords.
Knowing that thisisasuperduperlonguser was a manager through the configuration file, this user was used to login to the manager page. Getting into the management UI, the first thing that is noticed was the ability to upload war files. This could be an access vector into the target machine.
As Apache Tomcat is running on Java, using msfvenom to list out the available exploits reveal that it is capable to generate Java payloads.
Therefore, the payload was generated with the attacker’s IP address as the listener and port 4444 as the listening port along with the type of payload used and the format of the payload specified.
Uploading the war file into Apache Tomcat reveals another directory, /shell.
Listening on port 4444 on the attacker’s machine and going to /shell, gives us a shell.
The reverse shell is a non-interactive shell, meaning that switching users is not a possibility knowing that some of the user’s credentials are known. However, there is a way of turning the reverse shell into an interactive one using Python.
Using the command above to check the version of Python reveals that Python3 is installed and that using the method above is possible.
Doing so and changing into the user qiu reveals nothing.
Knowing that the user fluffy is present, the specified credentials were used.
Going into the home directory of the user fluffy reveals a hidden directory, .private.
Within the .private directory, there is another subdirectory called secrets. Within the directory, 2 files were present, backup.save and timeclock.
backup.save reveal nothing of use. However, timeclock is the bash script that updates the /time page on the webpage mentioned above.
As /var/www/html requires root privileges to write files and that the values for /time updates every now and then, it can be assumed that a cronjob and that the user root is running the script. With that in mind, a bash reverse shell is added into timeclock as the user fluffy as the file is owned by the user fluffy. The root user will eventually execute the script, hence, giving the attacker root access.
Doing so shows that the attack worked.
Reading proof.txt within /root shows that the challenge is completed.
In conclusion, this challenge is very simple. However, I was only concentrated on finding the flag as we would during CTFs, I neglected some important information when doing the challenge. Nevertheless, I was able to learn from my mistakes and will try to not repeat the same mistake in other challenges.