Box link: https://www.vulnhub.com/entry/colddbox-easy,586/

Preface

After completing this box, I read some other walk throughs to see if there was anything I'd missed. As it turns out, I missed quite a bit. I jumped straight from a shell as the Apache user to root. Every other writeup I've found pwned user and then used sudo to get to root. I'm not sure whether the box is intended to have multiple possible paths to success or if I found something new. Your mileage may vary and I'd definitely recommend reading some other people's experiences with this box.

Getting Started

nmap -sV -p- shows only HTTP on 80 and SSH on 4152. I fire up dirb while I check out the site. It looks like a pretty standard Wordpress. I fire off WPScan with aggressive plugin detection in one tab and brute force with -P in another tab. I'd started this pretty late into my evening, so I left the scans running to watch TV and go to bed.

In the morning, I find that the scan has found two users' passwords and then crashed 2.36% through the word list after seven hours and fifteen minutes. While I'm pretty sure that these two users are the only users I'm intended to solve through brute force, I go down a bit of a rabbit hole here. Click [here] to skip it.

Brute Force Rabbit Hole

I don't spend any time troubleshooting and instead restart the brute force and minimize the VM to go about my work day. I come back to the VM after work and find that the scan crashed again with what appears to be the same error (output here). Some cursory Googling seems to indicate that this is due to Ruby choking on non-ASCII characters.

A simple enough fix, I figure. I'll create a second password list containing only ASCII characters. This StackOverflow answer tells me how to use grep to find non-ASCII characters. I use this new knowledge to run a grep that excludes those characters.

grep -Pv "[^\x00-\x7F]" rockyou.txt > rockyou-ASCII.txt

I re-run the brute force using the new ASCII-only rockyou list.

I run into an unfortunate learning opportunity. I've now gotten the credentials I want three different times. But I never saved them. My computer crashes and I lose those credentials. Lesson learned: Don't forget to take notes early and often.

On my fourth attempt at the brute force, I cancel after I get the two credentials that I know I'm able to get. I run another command for something and kick those credentials out of my terminal's scrollback. Lessons learned: Take those notes immediately upon getting the information. Enable infinite scrollback.

It took about an hour for WPScan to get the second credential. I'd imagine that there are other tools that would've performed the brute force faster. An idea occurs to me: We should have a super short dictionary just for CTFs where if something is meant to be BF'd, it's in that dictionary. Lots of CTFs are limited time and it sucks how much progress is time impeded. Also, it sucks that a slower machine could be a significant disadvantage.

In any case, back to attacking Colddbox.

Back to it

dirb's output has a handful of interesting things. In the order of output they are

• /hidden/
• /server-status (403)
• /wp-admin/maint/
• /wp-content/upgrade/

It's been a while since I've used Wordpress so it's possible that those last two aren't as interesting as I think. I called them out because it's possibly a lazy admin forgot to remove something sensitive during maintenance/upgrading. Neither actually yields anything interesting.

The hidden directory contains a message apparently from Philip to Hugo.

I'm not really sure what I'm supposed to do with this information. I suppose maybe this is a hint that Hugo's password is some temporary password that may be easily guessable or brute forcable. In either case, I've already got it!

Pwning with Wordpress

From the message found in /hidden/, I'm guessing that c0ldd is a more senior user so I try logging in as them first. Checking the Users panel in Wordpress confirms that c0ldd is an Administrator account.

Did you know that admins in Wordpress have arbitrary code execution? Admins can edit the code of the themes that are running live. Just go to Appearance -> Editor.

Another quick aside

In a real engagement, you'd want to be as subtle as possible with your hack. In that case I'd:

1. Modify whichever theme file is least likely to be used
2. Modify it to have a webshell
3. Use that webshell to upload a reverse shell
4. Revert the theme file back to its original content

Back to it (Again)

Anyway, I upload a webshell. I don't know. I still feel more comfortable with a webshell than a reverse shell. I should probably get over that.

ls shows no server-status file or directory. I know that the target is on Apache so I search "apache server-status" and find that URL is part of Apache's mod_status and should be available from localhost. I run curl localhost/server-status on my shell and I get the server-status output. I saved that locally so I could view it as rendered HTML but there's nothing particularly interesting there.

When searching for what server-status is, "exploit" is one of the suggested search terms (eg) but doesn't look like something I can exploit to escalate privileges, especially on a VulnHub box where they're not likely to have something automatically clicking around to run your payload.

Getting to Root

I use my webshell to upload the same php webshell that worked so well last time.

I set off to finding privilege escalation. From what little experience I have, my first step is finding setuid binaries. While that page only searches /bin, I usually instead check the entire partition. If you do this, you'll want to redirect stderr to /dev/null otherwise you'll see a lot of output that's simply errors saying you can't read that file.

$ find / -perm -4000 2>/dev/null
/bin/su
/bin/ping6
/bin/ping
/bin/fusermount
/bin/umount
/bin/mount
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/pkexec
/usr/bin/find
/usr/bin/sudo
/usr/bin/newgidmap
/usr/bin/newgrp
/usr/bin/at
/usr/bin/newuidmap
/usr/bin/chfn
/usr/bin/passwd
/usr/lib/openssh/ssh-keysign
/usr/lib/snapd/snap-confine
/usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
/usr/lib/eject/dmcrypt-get-device
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
$ 

The first several binaries listed are things I'd expect to have setuid set. find stands out. I check on my own machine and confirm that's a non-standard configuration. A quick hop over to GTFOBins and I've got privesc!

The root text string base64 decodes to "¡Felicidades, máquina completada!" My Spanish is a little rusty but I think that translates to "Congratulations! Machine completed!" Google translate confirms!

Takeaways:

• Take notes immediately
• Enable unlimited scrollback (possibly log all terminal output?)
• Find a better way to brute force Wordpress. While I'm sure a veritable library of information exists about this, it might be a fun thing to test myself.
• Jump to reverse shells faster. I'm already used to the command line, I should stop relying on webshells and the associated slowness.
• Based on reading others' experience with this box, there's sometimes more than one way to get to the end goal!

This was my first VulnHub box that I did without any guide or walk through - an exciting step!

Feedback is appreciated. Feel free to reach out on Twitter @thecravenone or sam at seemsgood dot com