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?
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.)
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! ;-)