Chapter III
Third and final part of the walkthrough-series for the AllEndEvent pentest challenge.
Last updated
Third and final part of the walkthrough-series for the AllEndEvent pentest challenge.
Last updated
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.
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.
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.
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.
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.
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.
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.
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:
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:
In addition to that, make sure to start a listener for the reverse shell.
Afterwards, check the configuration of the reverse shell payload.
Let's copy the contents of the reverse shell into the 404.php template.
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.
We successfully gained shell access to the internal server as the apache user.
Well, we've been here before. Let's look at the WordPress configuration file.
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:
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:
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:
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.
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.
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.
Reload http://wiki.allendevent.com:54321/?p=999
Restart the listener
Update the IP in the 404 template
Now let's mount the exposed NFS share to a temporary directory on the web server.
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.
Subsequently, we copy the original /bin/bash on the internal server to the writeable share.
Then we modify the bash binary to be owned by root and add 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.
At last, we gained root access on the internal server - great success!
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.
One final look.
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.
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.
no_root_squash
no_root_squash exploitation steps
admin credentials
404.php theme file in WordPress
GatewayPorts option
404 template with the contents of the reverse shell
wiki.allendevent.com
mount the exposed internal share
root access via exploitation of an NFS share misconfiguration
customers.xlsx in Libre Office