We’re moving on to DC-6 for this walkthrough. It was actually much easier than DC-5 which I wasn’t expecting. If you wan t to watch a video walkthrough, I have one here.
Normally, we would start off with our Nmap scan, but there were some notes from the author we should pay attention to first. The first was to add wordy to our /etc/hosts file.
The second was to create a wordlist. cat /usr/share/wordlists/rockyou.txt | grep k01 > passwords.txt
This will come in handy later.
Now we can run the nmap scan. nmap -sC -sV -v 192.168.2.129 -oN map1
So it looks like there’s a WordPress site on port 80. Let’s check it out.
Typing in the IP address will get redirected to wordy. This is why you needed to set the etc/hosts file. If you didn’t, then your browser would ether not display it right, or you might be directed to a default internet search.
Clicking around the site, it seems they are very proud of their security plugins. You can also see a user Jens Dagmeister who has limited experience with developing secure plugins.
Since this is WordPress, let’s run wpscan.
In my scan, I chose to enumerate (-e) which will also tell me some user names.
Now I put these users into a file called users for future reference, but also for brute forcing. We can do that with wpscan as well. Remember that password file we made earlier? This is the time to use it.
wpscan –url http://wordy -U users -P passwords.txt
Now that we have mark’s password, we can login. (http://wordy/wp-login.php)
Looking at the tab Activity monitor you can see our brute force attempt … woops 😊
This Activity monitor is certainly the security plugin they were so proud of mentioning earlier. Let’s see if it’s vulnerable.
Running searchsploit on activity monitor leads us to a command injection vulnerability. Let’s check it out.
So the PoC says just change the IP and Port. That’s not exactly true. For one, you need to give it the correct URL. In this case wordy. Also, if you leave in the -nlvp, you’re creating a listener on the victim machine, not your attack machine. That won’t work for a reverse shell so get rid of it. Then change the IP to your attack machine, and the port to whatever you want.
Keep in mind that in real life, this will only work if the victim has netcat and the -e flag, and bash. When trying command injection, you might want to try to capture a ping back to your attack machine or other enumeration techniques before trying random shells.
Anyway, the trick now is how to deploy it. You can’t call Firefox from the command line to open the file. That will force re-authentication with WordPress. Instead you need to open it from a new tab using the URL bar.
Instead of starting it with http:// your use file:// then the full path to your modified html file.
Once the page loads, you should see a Submit request button. Before you press it, start a listener using netcat.
Now press Submit request and you should be greeted with a shell.
Now let’s upgrade our shell with python.
After I enter stty raw -echo, I’m pressing fg then enter. This returns me to the shell. The netcat commands are just left-over artifacts that pop up. You can safely hit enter and it will ignore them.
Now at this point, I would usually look for the SQL password in the WordPress config file, grab some password hashes and start cracking. In this case, that’s not going to get us anywhere.
Instead, we’re going to search through the user directories. In the home directory we find graham, jens, mark, and sarah. A quick search of those directories shows that jens has a backup script, and mark has some stuff.
Looking in jens folder at the backup script shows that it’s just taring the web directory. Something to keep note of.
In mark’s stuff directory there’s a file called things-to-do.txt. This file contains the password for graham.
So let’s login as graham.
Now that we’re graham, let’s see if we have any sudo permissions.
We do … but only to run jens backup script. Still, if we can modify the script, we can become jens. Let’s see what the permissions are.
This is great! Because we’re in the devs group, we can write to the backup script. Let’s modify it to run bash. Unfortunately, we’ll have to use vi to do this. You may find this helpful if you’re like me and hate vi. http://www.atmos.albany.edu/daes/atmclasses/atm350/vi_cheat_sheet.pdf
All I did here is comment out the tar backup and add in a call to bash.
Now let’s run it with our sudo permissions and hopefully become jens.
Awesome! Now we’re jens. Let’s see what permissions we have now.
Ok, so we can run nmap as root. There’s a shell escape for certain versions of nmap, but this isn’t it. Let’s check out GTFO bins and see what else we can do with it.
It looks like we can still get a shell with nmap by using its script functions. GTFO bins is having you make a temp variable to hold the command. I’m just going to make a regular file because it’s faster and I don’t care about writing to disc.
Once the command is echoed into a file, use sudo to call the nmap as root while invoking your malicious script. You should end up as root.
Keep in mind the note from GTFO bins that echo will be disabled. While it’s not necessary, one way to get things back to normal is to copy and paste in the python shell upgrade. python -c ‘import pty, pty.spawn(“/bin/bash”)’. At least this way you’re not typing blind.
Now to get the root flag.
The circled section above is where I put in my python command. Obviously, you can’t see it because echo’s off, but you can see the rest of my input is being displayed.
That’s all for DC-6. This one was certainly easier than some of the others. Still, I hope you enjoyed the walkthrough and found it helpful. I also have a video walkthrough that you can see here.