Zico on VulnHub
12 March 2017
IntroductionMy friends and I like to solve CTFs on our own, then teach each other how we solved it. This way, we get experience both teaching and learning, and you always understand material you need to explain to someone else better than if you kept it to yourself.
Zico’s author rates the box as “intermediate,” but I’d call it “beginner plus.” The ideas needed to root the box are not complicated, but you need to have a bit of prior knowledge to know that you need to implement them.
Shall we begin?
1. Initial ScanningSince we are dealing with a VulnHub VM, we need to set it up on our HOST ONLY
network. This box is intentionally vulnerable, why hook it up to your real network?
Depending on how you’ve set up your host-only network, you may need to use nmap to determine the machine’s IP.
nmap -sn 192.168.56.0/24
I like to use my benmap script, which runs a few scans and generates
a working directory for the CTF. You can check it out on Github. The nmap -F scan found some potential avenues of attack:
- SSH on port 22
- HTTP on port 80
- rpcbind on port 111
Nikto tells us that Apache is a bit obsolete, but nothing else particularly interesting.
Throw that on our “places to dig” list and let’s use dirsearch.
dirsearch -u 'http://192.168.56.101' -e php,html,js,txt,sh --simple-report=dirsearch_quick
We find a lot of interesting filenames, especially the dbadmin directory.
Anything with “admin” in the title may be worth a look.
Finally, we’ll let fimap see if we can dig anywhere we aren’t supposed to be able to.
I tried something like ../../../../etc/passwd, but didn’t find success. Maybe we can use this later.
fimap -H -d 3 -u "http://192.168.56.101" -w /tmp/fimap_output | tee fimap_result
Lastly, we peruse the site in the browser.
Zico doesn’t seem confident that he is in control of his own site.
Let’s prove that he is right to have doubts and go right for that /dbadmin page.
What have we here?
2. Doing Dirty Deeds in da Database
A php database page, with an obvious version number. The title of “testdb” hints at a default setup.
A default setup may use a default password.password: admin
Those look like password hashes to me.
Our friend Hashbuster should have a look at them.
Not too shabby! Root and user passwords.
I don’t think this db is actually used for anything other than testing, but there is a chance that the same passwords are used to login with SSH.
We can see some other useful information on the database page, however.
For one, we are given the test_user database’s full file path.
This information, combined with the Local File Inclusion vulnerability we spotted earlier means we can access these databases by visiting a URL.
We can try some tricks using SQL commands, but I wonder if
these waters have been charted before…
- Create the table, and set up the listener on your local machine.
nc -lnvp PORTNUM
- Visiting the database in the browser, using our handy-dandy LFI vulnerability will run the payload and pop our shell.
www-data to User
My “advanced” powers of deduction tell me that we are going to have a user named zico. A user with a home directory, even.
Zico seems to be trying out some content management systems for a new website.
The site we got through in order to get this shell used phpliteadmin, so Wordpress must be next.
We see Wordpress sites all the time in CTFs, and know it well enough to know where to look for the squishy bits.
Zico hasn’t implemented this site yet, so it may not have been combed through for sensitive info.
wp-config.php can often contain passwords.
grep -i 'pass' wp-config.php
4. From Zico to RootAs the presumed owner of this box, Zico should be able to get some significant things done.
sudo -ltar and zip are a bit strange to see as sudo-enabled commands. Can they be used for code execution?
Move to a “temporary” folder like /dev/shm and create a file that we will compress.
Compress it with tar as Zico. No need to run as root just yet.
Unarchive the newly created .tar, making sure to use sudo and including the flags to add a checkpoint and commands.
The commands will run along with the .tar command, so any output from the commands will appear in the terminal
Our test payload is the (redundant) command echo $(id), which will output the info belonging to the user who ran the tar command to the terminal.
If things go according to plan, we should see root’s info.
sudo tar -xf archive.tar --checkpoint=1 --checkpoint-action=exec='echo $(id)'
Our privesc concept is proven.
We can just run /bin/bash as our checkpoint commands to spawn a root shell.
sudo tar -xf archive.tar --checkpoint=1 --checkpoint-action=exec='/bin/bash'And, we’re root.
Go to the /root directory and grab the flag.
Post-MortemThis CTF was made purposefully made porous, but these vulnerabilities can be found in the real world.
Here’s what made Zico rootable.
- Serving webpages with ?page= is a recipe for local file inclusion.
- Only one page was intended to reached this way, and it wasn’t even the only link to this page on the site.
- www-data had unneccessary read access to zico’s home folder.
- If zico isn’t a superuser, I’m not sure what reason they would need to have to run tar and zip as root.