Mountaineer
Will you find the flags between all these mountains? - by nirza
Last updated
Was this helpful?
Will you find the flags between all these mountains? - by nirza
Last updated
Was this helpful?
The following post by 0xb0b is licensed under CC BY 4.0
We start with a Nmap scan and find two open ports, port 22 and 80, where we have SSH, and port 80, where a nginx 1.18.0 server is running.
On the index page of the web server, We are greeted with the welcome page of nginx.
Next, we run a directory scan using Feroxbuster and find a WordPress directory, among others.
On the WordPress page we find a blog about Mountains, and can enumerate the first four users, as they have each written a post.
Furthermore, we try a scan for possible VHosts but do not find any with our wordlist.
Since we are dealing with a WordPress page, we will continue with WPScan. WPScan is a vulnerability scanner. By including an API key, we also get a mapping to the existing CVEs. An API key can be obtained free of charge from the following page:
With a simple WPScan we find several vulnerabilities, most of them dating back to 2021, but also some related to the core of WordPress from 2024. Of note are an unauthenticated SQL injection vulnerability and an authenticated arbitrary file upload leading to RCE
This looks like a useful and promising exploit chain. Namely dumping the database, getting password hashes of the users, cracking them and then using them for the file upload for an RCE.
Unfortunately, this was not quite the right approach, as the password hashes could not be cracked.
Furthermore there were attempts on the 'reply' functionality, to elevate some XSS to retrieve the session cookie of a user and other XSS found by the scan.
Furthermore, we focussed mostly on the WordPress page and ignored the Nginx server. There was a focus on the version 1.18.0 with its vulnerabilities, but misconfigurations were not tested.
Let's go ahead and focus on the Authenticated Arbitrary File Upload to get RCE. For this we somehow need to be authenticated. as already mentioned, the SQLI is not the most suitable solution in this case.
After I saw an advice from 0day in Discord, I realised a few things. I also tested the Nginx server but only focussed on CVEs and not on misconfigurations. So let's have a look at the post about nginx on Hacktrick.
When looking through the HackTricks article, one of the things that stands out is Alias LFI Misconfiguration. Using an LFI, we could possibly obtain sensitive information from configs or even credentials.
Alias LFI Misconfiguration In the configuration files of Nginx, a close inspection is warranted for the "location" directives. A vulnerability known as Local File Inclusion (LFI) can be inadvertently introduced through a configuration that resembles the following:
This configuration is prone to LFI attacks due to the server interpreting requests like
/imgs../flag.txtas an attempt to access files outside the intended directory, effectively resolving to/path/images/../flag.txt
We test for the misconfiguration and see that we are able to include the /etc/passwd.
After various attempts to get info from the /var/log/nginx/access.log and other files, we find what we are looking for in the default configuration: /etc/nginx/sites-available/default
Here we find a VHOST that we had previously not found with our VHOST enumeration using FFuF.
We add that to our host file and find a Roundcube mail login.
With our access to Roundcube, we now have the option of logging into a user's mail account if we determine their password. Since cracking the passwords did not work - as mentioned at the beginning - we could have more luck here. If we have access to a mail account, and it is stored on WordPress, we can reset the user's password and then use the Authenticated Arbitrary File Upload To RCE vulnerability to get a shell on the system.
The following WPScan provides us with five users. We could also have enumerated these using the SQLI. But that takes a lot of time.
As the user K2 is mentioned in several articles and has not written a contribution himself, we will concentrate on him for the time being.
The idea is now to bruteforce the password using Hydra. Unfortunately, it was not possible using Hydra and the custom script and is only included in the writeup for information purposes. The user password is guessable.
We create a wordlist using cewl using the two articles.
Next, we capture the log in request using Burp Suite.
From the data we receive, we are able to craft a hydra http-post-form command to be able to brute force possible password candidates.
Unfortunately, the bruteforce using Hydra was unsuccessful. A 302, redirect, was defined as the success. After a short time, however, the message 401 appears and reference is made to the use of http-get module, which makes no sense here. There are also bruteforce scripts on GitHub, but these were also not effective, as the page took too long for a response.
But we are able to guess the password for k2. As you can see below.
After logging in, we have access to the user's mail account.
The next thing we do is to trigger a password reset request on wp-login.
After a short duration, we receive the reset link.
We copy the suggested password and save it.
Now we can move on to CVE-2021-24145 to gain remote code execution. There are PoCs on GitHub available. We use the following one.
We run the PoC and a reverse shell gets uploaded and is accessible at http://mountaineer.thm:80/wordpress//wp-content/uploads/shell.php.
It's a p0wnyCat web shell, but we prefer a more interactive reverse shell. For this, we set up a listener and drop the busybox reverse shell crafted with revshells.com into the web shell.
We receive a connection back, we are www-data. Now we upgrade the shell.
Unfortunately, we do not find the first flag here.
But as we have already seen from the LFI of /etc/passwd, we can also find the users who have posted. We already have credentials for k2.
These were also used again, we can switch to the user k2 with our upgraded interactive shell using the password for Roundcube. Unfortunately no flag here either, but a mail folder. Maybe we can find more here.
In the Sent file, we get more information. It is about the user lhotse. This user has drawn attention to possible security risks. They would like to exchange information, and k2 has collected some information about lhotse. Possibly too much information, because it looks too tempting to generate a password list from it, but more on that later.
Interestingly, we have access to the lhotse home directory. In this directory there is also a mail folder to which we do not have access, but a KeePass file. We have access to these and want to exfiltrate them. Maybe we can crack the KeePass file with the information collected by k2.
Since the KeePass file has a reasonable size, we use base64 to make this content 'copyable'.
Next, we use CyberChef to decode the data and save it to our machine.
If everything worked properly, we should now have a KeePass file on our system.
Now we use cupp to generate a password wordlist of the found information by k2. We are using the interactive mode with -i to let the tool guide us.
We transform the KeePass file now to a hash file using keepass2john. This can now be passed to john with the generated wordlist using cupp. After a short duration, the password is shown to us.
We use that password and find entries for mblanc and kangchenjunga.
We use the credentials of kangchenjunga to switch the users using su and are successful. In the home directory of the user, we find the first flag. Furthermore, we see that the .bash_history file is not empty.
In the notes, we find a hint, that the root user is using the account of kangchenjunga. Inspecting the .bash_history file, we see that (maybe) the root user made a type suroot revealing his password afterward and accidentally stored it in the .bash_history file.
We use that password from the .bash_history file and are able to switch to the user root. In the home directory of the root user, we find the final flag and a nice note at the end.
The root access was a bit too easy for my taste but a nice present at the end.
Even if the CVE shown did not lead to success, I still find it interesting enough to show once. It is a Time-Based Blind SQL Injection where we are able to determine the validity of a query by observing the response time of the database.
WPscan delivers us a link with a short description a working payload and references to the CVE.
The plugin does not sanitise and escape the time parameter before using it in a SQL statement in the mec_load_single_page AJAX action, available to unauthenticated users, leading to an unauthenticated SQL injection issue
Furthermore we are able to find a PoC at exploit-db.com.
The exploit itself uses SQLMap. To make our queries more precise and to get our required information faster, we slightly modify the SQLMap command used. So that we only read out the user names.
And for each specified user only the hash to save time.
