Header Ads

Joomla Automated Exploitation

Joomla Automated Exploitation – Most people know or have heard about
Joomla. It’s probably the only CMS with the most exploits and vulnerable
addons ever made, and sometimes I wonder who creates all these.
That however, isn’t important. What matters is that once an addon is
installed, there’s a high chance it contains unsanitized code aka a
security hole for us to target, (ab)use and exploit.

In the reconnassiance phase, it is usually quite easy to determine
whether a site is running Joomla or not. If you’re unsure, browse to the
“administrator” directory like this:
http://www.domain.tld/administrator/ (if Joomla is installed in root
folder).
The administrator directory is hardcoded in almost every if not all
versions of Joomla, making it very easy to fingerprint in most cases. If
you’re somehow unable to browse to this directory but suspect the
target is in fact running this CMS, look for URL’s on the site (or in
the source) that looks like this: /index.php?option=com_content or
similar. The keyword to look for is: option=com_xxxxxxxx in the URL’s
because almost no other CMS uses this way of loading modules.

When an addon is identified simply by knowing the standard module
names, a search for known exploits can begin. A search for “Joomla” on
Exploit-DB reveals quite a lot of results where most of these are
addons.
If there is a Proof of Concept available we can try to use it but if
there isn’t, then it could be a good idea to download the addon from the
developers website and audit the script(s). In our scenario there’s a
well described PoC as shown below.

After testing this specific vulnerability we confirm that it works,
and that it’s possible to perform SQL Injections on our current target.
Now it’s nice to know the database version, but exactly what good is
that to us or for that sake the company we may be conducting a
penetration test for? Most penetration testers would like some sort of a
shell, at least I prefer that since it’s easier to escalate privileges
that way.

We could just grab the admin hash and try to crack it, but why not try to upload a backdoor to the server and execute that?

Hax0r 1t n0w

Some of you may remember a tool once made for BackTrack, with a huge
red button saying “hax0r 1t n0w” which launched a series of automated
attacks. I didn’t really use it but loved having it installed on my
desktop just for fun. After all it worked, and so does this custom tool I
just wrote.
In our scenario we’re going to try and upload a file to the server by
using the “FILE” privilege which is disabled by default on MySQL
servers, but in some cases it’s not. The syntax is relatively simple for
such an attack: “-1 UNION SELECT ‘Hello World!’ INTO OUTFILE
‘/var/www/thisiscool.txt’”
One major problem is that we have to know the physical location on
the target server in order to place our file the right place, and if we
supply no such argument then the file is going to be stored in the
database directory making this attack useless.
So how do we circumvent this potential problem? We use a common
wordlist of course with smart variables included! (Variables which takes
the user-input and applies it to predefined webroot variables.)

NBS 0.3 – Joomla Addon Attack Tool

This tool was actually upgraded from being a simple SQLi Assistant
Tool, into a joomla addon vulnerability scanner as well. It’s currently
in beta, but it worked wonders on the target shown in this article.

First the user is given the option whether to use the vulnerability
scanner or supply a vulnerable URL. The first option is definitely the
most interesting, and it simply uses a list of URL’s which can easily be
expanded if desired. I should note however, that there are limitations
of use for this tool since it’s merely a “Proof of Concept” at this
point.
When a vulnerable addon is found, the main tool within is launched and the target needs to be confirmed.

At this point the tool tries to load “/etc/passwd” to determine
whether we have the necessary “FILE” privileges or not and then the
common wordlist for the webroot is used to try and place a file on the
server.
This file is just for testing and making sure we have a place for our actual code, such as a backdoor perhaps written in PHP.
If it was possible to write a file to the test server, the user is
able to choose whether he or she wants to upload code from the console, a
file from the users filesystem or a predefined shell.
The file option is meant for PHP files since it changes the content
and prepares it for this kind of injection. (In short: Comments and new
lines are removed.)
We’re going to try the “shell” option which uses a slightly modified version of the Reverse PHP Shell made by pentestmonkey.net

When we’ve supplied all the args, it’s time to set up a netcat
listener at the port we defined and then browse to the file on the
server.
BOOM! We got a shell baby! ;-)