Joomla Hacks – Part I – Phishing

Joomla is a very popular open source CMS, dominating approximately 10% of the website market. While great for them, horrible for many others, as being popular often paints a big target on your back, at least when it comes to CMS applications.

Lately though, Joomla has had a bad spell, in which a vulnerability was found that was allowing for arbitrary PHP uploads via core. Any site that is not properly updated (or patched), can be an easily compromised. This applies to any website running Joomla 1.0.x, 1.5.x and the 1.6 and 1.7 branches, each one needs to be updated to the supported 2.5 or 3.0. Once that is supported, they need to be updated again to the latest 3.1.5 or 2.5.14 versions.

Unfortunately for Joomla users, the upgrade path is perhaps its weakest link. The reverse compatibility issues are so severe in the various branches that it plays right into the attackers objectives facilitating sever vulnerabilities, allowing them to have wider impacts across the website ecosystem. Because of this, we will share in this post one very specific method attackers are using to perform nefarious acts using the websites you visit or own, a little something known as Phishing.

  • Part I – Phishing injection

What is Phishing

Before we can understand what they are doing, we have to understand what Phishing means.

As you might imagine, like the act of fishing, where you find yourself on the banks of a lake or sitting at the pier, a fisherman readies their rod and casts out their line with some bait. This bait has one goal, attract fishes. For every kind of fish there are different rules, what rods to use, what lines to configure, more importantly, what bait is most effective. At its most simplest, fishing comes down to throwing food in the water and hoping something bites.

It’s this simple description of fishing that applies to Phishing.

Phishing is the act of attempting to acquire information such as usernames, passwords, and credit card details (and sometimes, indirectly, money) by masquerading as a trustworthy entity in an electronic communication. – Wikipedia

It’s similar in the way it is done. An attacker will have to consider who will be its prey. What is the end game? Are they looking for financial information, personal information, etc.. the goal will dictate what bait to use. Often the term of Phishing is attributed to two different modes of communication – emails and phone calls. These are the most common, but we assure you there are many more means. In either case, more often than not though the unsuspecting fish, you, the user, are redirected to what appears to be a benign website.

This website will have what appears to be the appropriate look and scheme you have come to expect from your trust service provider. You will gladly enter your credentials and proceed to log in, it will let you in with whatever information you enter and continue to ask you a series of questions to better understand your profile. You will gladly adhere to their lines of questions and when it’s all done, you’ll likely log out and be happy that you have been proactive.

Meanwhile, all the information you have just entered into the website has been stolen.

Understanding Phishing Files

As we now know, most phishing attacks need a website of some kind to host the pages that will be used to scam the user. So if an attacker is sending phishing emails asking the user to reset his PayPal password, he will also need a page with a form where he can send the victims to.

This is what a real phishing site looks like that is targeting Chase, a US bank:

Chase Phishing

If you’re not familiar with the bank, yes, it looks very similar to the real Chase website. The difference here, however, is that and when the user providers his user/pass they are not taken to their account information. Instead, they are redirected to a page that asks them to please update all their information. This second phases lures the attacker to provide more personal information in turn making it easier for the attacker to be more malicious in identity or financial theft. Here is an example of what that looks like:

Chase payment update

When all the information is complete the user is notified that everything is great, please proceed with your daily activities and the user simply logs out. All the while, being none the wiser that they have just started the first day of the worst day of their digital existence.

For this to work, the attackers need a couple of things:

  1. A list of unsuspecting email users – this could come from the various hacks we have seen on sites like LinkedIn, eHarmony and many others
  2. A website that can be used to house the malicious files
  3. A malicious server to collect all the data

This of course is in its simplest form, the entire life cycle is a bit more complex.

With this information, attackers are able to mass email their unsuspecting victims. Regardless of how they lure the unsuspecting users, the goal, these days, is often the same, get them to website in which the user willingly gives up their information. This is where CMS applications like Joomla come into play.

Phishing Hidden in Joomla Sites

Joomla like so many other CMS application has had its run in with vulnerabilities over the years. It most recently had one where it allowed the upload of arbitrary PHP files to the /images directory of any install. These uploads often contained shells and in some instances Phishing files like the one we shared above. We wish we could say there was only one location where these files are injected, but the reality is it’s all about opportunity. For instance, in this recent vulnerability it allowed attackers to exploit the /images directory so that’s where we found them. There have been other instances though where we have seen them embedded in /plugins, /cache, /includes and other such directories within the root of the CMS itself.

Th reality is that often these Phishing sites are nothing more than 1, maybe 2, PHP or PHTML or HTML sites with some JS and require little if any core functionality form the CMS itself. This allows its placement to be really easy, all they need is the full path to the location and they are able to mask that location with what appears to be a benign website, something like this:

<a href="evilsite/chase"></a>

In this example all the user would see is:

In the recent Chase case we shared earlier, the pages were inside the following path:

As I mentioned though, it’s not limited to that. Here a few more realistic directories that we have found files in:

Some Hardening Tips

I can almost here all the internet pundits already, “Ah, well that’s obvious.. pff… “, unfortunately though it’s not for a lot of everyday website owners. One way to address this shortcoming is for website owners to disable PHP execution in directories that don’t require it, which in the case of Joomla make up a lot.

As Joomla is often configured on a LAMP (Linux Apache MySQL PHP) stack you can take advantage of .htaccess by adding it to each of the directories in which you don’t require PHP to be executed. It would like something like this:

# Disable PHP Execution in this folder
<Files *.php>
Deny from all

Mind you, this might be a bit aggressive, depending on how your templates, components, plugins and everything else is built it could break a few things. Often case it comes down to CSS not being rendered or images not being loaded. You will need to hunt those issues down and don’t just remove the hardening, modify it to something like this:

Order Allow,Deny
Deny from all
<FilesMatch "^[^.]+.(?:[Jj][Pp][Ee]?[Gg]|[Pp][Nn][Gg]|[Gg][Ii][Ff]|[Pp][Dd][Ff])$">
Allow from all
Order Allow,Deny
Deny from all
<FilesMatch "^[^.]+.(?i:jpe?g|png|gif|pdf)$">
Allow from all


Order Allow,Deny
Deny from all
<FilesMatch "^[^.]+.(?i:jpe?g|png|gif|pdf)(?i:.gz)?$">
Allow from all

Whatever you decide, be sure to test and be prepared to undo. The latter parts is often something you’ll want to do directories like plugins and templates as those are often the ones generating the elements of your website that people see, but if you apply it to components, includes and others you might have refine things a bit as well. If you find a specific file that needs to have access you can modify it to read something like:

<Files *.php>
deny from all
<Files yourawesomefile.php>
allow from all

This will make it so you deny all by default, while refining the ones that can run. This is the preferred method of most information security professionals.


Unfortunately, Phishing is but one attack we see on CMS applications like Joomla. It is however one of the hardest ones to detect. Unlike SPAM, and other types of Malware, it doesn’t often make itself readily available via the main website. Often it’s location is obscure and only known to the attacker, allowing it to be used in mass email Phishing campaigns. Fortunately, how it gets in is often attributed to two things – Access Control Issues and Software Vulnerabilities either in core or in it’s extensibility.

Lastly, remember that to be effective at this scams, attackers are dependent on you, website users, to not know the difference. Learn to become proactive with your online habits, this extends beyond just visiting websites, but how you interact with your emails and social media outlets.

As for website owners and administrators, you can follow some of the guidance above, but if you prefer not to worry about it you might want to get proactive with your defenses to include detection and protection.

  1. My previous entry – everything after the $double quote was added by the blog engine and can be ignored.

  2. The second set of code that you have listed under “Some Hardening Tips” are ones that I came up with over years of testing. I guess I should explain a bit in what they do. They basically white-list file extensions that you allow access from HTTP. They also prevent double extensions from being accessed.

    The reason behind this, is that there are so many file extensions that can be executed from HTTP besides all versions of php. Please note that these rules prevent access from HTTP. If you want to totally disable a script in a specific category you’ll have to force a Handler upon the file extensions. White-listing here is tricky, but I’ve actually figured a way to achieve it. I may write an article on how to do it sometime soon.

    Also, you do not need the “Deny from all” in the code that I came up with. This will suffice:

    Order Allow,Deny

    Allow from all

    Reason being is that in the Allow,Deny directive, if the file does not match an Allow or Deny directive it is denied. No need in making the server parse something that is already assumed.

    The first part “[^.]+” means not a literal period one or more times. This is to prevent access to double extensions. example: not-an-image.php.jpg

    The next part is the file extensions “(?i:jpe?g|png|gif|pdf)”. I’m using assertion “(?i:” to allow for the file extensions to be case insensitive while at the same time making this a non-capturing group to speed up the parsing. Please note this will only work on Apache 2.0 and above.

    The last part “(?i:.gz)?” means to include files that are gzipped if they are available. This is also case insensitive in a non-capturing group for speed. The reason I included gzipped versions is because some sites are set up to serve gzipped version of static files to browsers if they accept them for quicker delivery to the viewer. Me, being one of them.

    This code is as strong and inefficient as I believe it can be made.

    1. It looks like my additional comment has not yet been approved yet. I just wanted to state, that you need to remove this from the code above:


      For some reason, Disqus added it to the code. I pasted a url from pastebin dot com, but it hasn’t been approved yet.

Comments are closed.

You May Also Like