Categories
Capture The Flag

Kioptrix Writeup

Ethical Hacking is an essential part of a good cyber security program, knowing how cybercriminals can attack your networks and computers allows you to better defend your systems.

For example, knowing which vulnerabilities are present by regularly scanning your network with a tool like Nessus is an important part of the process, but what can attackers do if they discovered those vulnerabilities first? Are they able to exploit them and gain access to your network? What can they do once they’re inside? Can they cause damage, steal sensitive information, or access other systems?

Ethical Hacking, or Penetration Testing, allows you to think like an attacker and follow similar steps that an attacker would to try to compromise your systems. By hacking yourself first, you can prevent many attacks before they happen by patching the holes in your security.

This post is a basic walkthrough of the Ethical Hacking process using the freely available vulnerable virtual machine Kioptrix. I’m doing this to demonstrate the process of discovery and exploitation of a vulnerable computer system.

For me personally, Kioptrix was challenging enough that I had to think things through and do a bit of external research, but not too hard where I was stuck for days. I haven’t exploited every possible vulnerability, though I was able to get root access and get the users password hashes.

Power-up Kali Linux and download the Kioptrix OVA file from VulnHub. I’ve got both Kali and Kioptrix configured to use VirtualBox’s Host-Only network, just to keep isolated from the public Internet. Safety and all that.

First I need to find the Kioptrix IP address. I’ll check my Kali Linux IP address, just so I know who I am, and what network I need to scan.

I have the IP address 192.168.56.132 on my Kali machine, so I’ll scan 192.168.56.0/24 with the netdiscover tool.

On my host-only network, netdiscover has found 3 IP addresses. Assume for the purposes of this demo that I don’t know what any of them are.

If I ping all 3 IP addresses, only 2 seem to respond.

I’m going to take an educated guess that 192.168.56.146 is the Kioptrix machine, but I’ll confirm with an nmap scan. I don’t know what services are running on Kioptrix yet, so there’s going to have to be some enumeration and scanning to figure out what I’m going to do next.

There’s http, https, ssh and some other open ports, possibly Samba (SMB) as well. It’s looking good that this is the right machine, so just to confirm it’s got http running I’ll see if I can open it up in a web browser.

Looks like it’s an older version of Red Hat Linux running Apache. It’s displaying the default Apache installation page, which could mean that the server isn’t set up correctly or at least is not locked down. Https is also open, but it looks like there’s a certificate error and I can’t load the page.

I’m going to fire up Nessus and run a vulnerability scan. If you don’t have Nessus installed you can follow my article to run through the installation. From Nessus, I’ll create a new scan and select ‘Basic Network Scan’.

I’ll leave most of the scan settings at their default to see what it picks up. After a few minutes, Nessus found an impressive 42 vulnerabilities.

I’ll make note of a few of the interesting ones, in particular I can see a vulnerability that might result in a remote shell, and there’s some critical Apache HTTP vulnerabilities as well.

I’m not quite ready to start exploiting anything yet, this is still a fact finding mission.

I’m going to run a deeper nmap scan with the -A option to see if I can get some more information. This scan is quite noisy and would likely trigger some alerts on a real target.

As we can see, it is an old version of Red Hat Linux, a very old version of Apache (1.3), and down the bottom we can see Samba is running and that I’m definitely scanning Kioptrix, so I’ll continue.

I’ll also run a Nikto scan against the web server. Nikto is another vulnerability scanner that looks only at the web application running on a host, compared with Nessus that scanned multiple services.

A few interesting results that might be worth looking into, particularly the remote shell and code execution vulnerabilities. Theres a potential remote buffer overflow in mod_ssl, and Nikto also found a file called test.php, so let’s see what that is first.

There’s PHP scripts on the server, but looks like PHP is not configured correctly, or at all. When Apache is configured to run PHP, the PHP engine will kick in when the script loads and will display the output that the PHP code is generating. In this case, you can see that the page is just supposed to print the word TEST to the browser, however you can also see the PHP script tags and the ‘print’ statement as well, that tells me that either PHP is not installed correctly, or Apache hasn’t been configured properly to run PHP code.

Either way, this is an interesting find. If there’s a web application running on this server, having a misconfiguration in PHP could mean we might find some exposed credentials or some other sensitive information.

In any case, I’d note this down as a server misconfiguration. PHP version 4 is also terribly out of date.

Most of the other findings in Nikto seem to be false positives, I couldn’t find any installation of WordPress and none of the paths listed seemed accessible. Doesn’t mean there’s nothing there though, but I might run gobuster to see what else I can find. I’ll try the Common-PHP-Filenames.txt wordlist first.

Unfortunately I only find the same test.php file I already found with Nikto. I’ll run it again with a different wordlist.

Gobuster found a few additional directories and for good measure, I’ll also run dirbuster as well. These tools do similar things but one may occasionally find something the other missed so it’s worth a shot.

As expected, dirbuster found the same things as gobuster but we went a bit further into the folders and found some extra files. The rest of these don’t look too interesting and are probably default configurations left lying around, but I’ll check some of them out anyway.

In the usage folder there’s some HTML files that show interesting information, looks like traffic statistics for a web application.

We also have an MRTG folder, opening the first link shows some documentation. Similarly the /manual folder is the Apache documentation, which doesn’t seem to be found on the server, however I do find a directory listing, which is another server misconfiguration that could let me navigate around the server and possibly reveal some additional information or sensitive files.

Trying to navigate up to the parent directory takes me to the default home page again, but clicking on the mod directory reveals some additional information, as we can see there’s mod_ssl which was discovered in the vulnerability scan, and also mod_perl which could mean Perl CGI scripts are running somewhere.

I tried to see if I could navigate out of the Apache webroot with a bunch of /../../../../../../../ but no luck.

Also notice the message under the directory listing, it shows the Apache version which we’ve already discovered, but this is still information disclosure so I’ll note that down too.

There’s quite a few potential vulnerabilities I’d like to explore. I’ll pick a few of the most interesting ones first.

While I’m still looking into Apache, I’ll check if there’s any known exploits for the Apache version that’s running, version 1.3.20. I did a quick Google for the version numbers and ran searchsploit on Kali.

If you recall from the vulnerability scan, we also discovered a potential remote buffer overflow in mod_ssl, so I’ll check that now too.

Looks like there’s possibly an exploit available. I’m going to test version 3 which is the file 47080.c. As it’s a C file it will need to be compiled, following the instructions in the file comments.

Running the exploit spawned a shell as the apache user, this is great, but notice from the output that it tried to download and compile a ptrace-kmod.c file, which looks like a privilege escalation. My network configurations are such that neither Kali or the target can access the Internet so the download failed and I was given a non-privileged shell as the apache user.

This is cool anyway, so I’m going to grab the /etc/passwd file first while I’m here as it will show me the Linux user accounts on the server.

I don’t want to reboot both machines and change network settings but I want to see if I can get this exploit to work, so I downloaded the ptrace-kmod.c file from another machine and uploaded it to Kali. I modified the statement at line 341 in the 47080.c to download the file from the Kali box rather than the Internet and re-compiled. Then I started a Python http server and re-ran the exploit.

The additional C file looked like it uploaded and ran this time, and the exploit succeeded, giving me a root shell. 😉

I’m going to grab the /etc/shadow file and have a look around.

Next I’m going to assess the SMB service. Samba is a file-sharing protocol running on port 139. Using the tool smbclient I’m able to connect to Samba anonymously but I can’t do much else.

I need to figure out what version of Samba is running, so I’ll use Metasploit for this next part, typing msfconsole at the command line.

Using the Metasploit module auxiliary/scanner/smb/smb_version I can see that the Samba version is 2.2.1a. Searching the Metasploit database for an exploit shows a few, however there’s only one for the version running on Linux. So I’ll use that.

Setting Metaspolit to use exploit/linux/samba/trans2open seems to work and opens a Meterpreter session, however it died immediately on opening, so that’s not cool.

A bit of research and some help (once again) from the TCM Security training videos, I realised I need to change the payload. By default, metasploit was trying to send a staged payload to open a meterpreter shell, but setting the payload to a non-staged payload is required for this to work.

Changing the payload and re-running the exploit worked and I was able to get a root shell.

Finally, I know SSH is running, and now that I have the /etc/passwd file I also know which users are on the system, so for fun I’ll try to SSH to John’s account.

Turns out this is because the box is quite old and is using an older version of the SSH protocol, so with a bit of Googling and some guidance from the TCM Security videos, I managed to get SSH to connect.

I don’t know John’s password yet, but I do have the /etc/shadow file so I could try to crack the passwords.

I also tried to brute-force SSH using hydra, which didn’t seem to yield any results.

And also with Metasploit.

However, I have a root shell from exploiting both Apache/mod_ssl and Samba and I’ve got the hashed passwords. So I’ll consider this box pwned.