August 12, 2013

If you run a site powered by the Joomla content management system and haven’t yet applied a critical update for this software released less than two weeks ago, please take a moment to do that: A trivial exploit could let users inject malicious content into your site, turning it into a phishing or malware trap for visitors.

joomlaThe patch released on July 31, 2013 applies to Joomla 2.5.13 and earlier 2.5.x versions, as well as Joomla 3.1.4 and earlier 3.x versions. Joomla credits discovery of the bug to Web security firm Versafe, which says a simple exploit targeting the vulnerability is already in use. Joomla versions 2.5.14 and 3.1.5. fix a serious bug that allows unprivileged users to upload arbitrary .PHP files just by adding a “.” (period) to the end of PHP filenames.

For 2.5.x and 3.x versions of Joomla, it is possible for anyone with access to the media manager to upload and execute arbitrary code simply by appending a period to the end of the file name they would like to run. For sites powered by unsupported versions of Joomla (1.5.x, and a cursory Google search indicates that there are tens of thousands of these 1.5.x sites currently online), attackers do not even need to have an account on the Joomla server for this hack to work.

Acccording to Versafe chief executive and co-founder Eyal Gruner, of the thousands of phishing and malware attacks against the company’s 30+ EMEA financial clients in the first half of 2013, 57 percent were hosted on Joomla-based websites.

“What we’ve seen in the last few months is a significant exploit whereby fraudsters can use sites to host drive-bys and phishing attacks,” Gruner said. He noted that the company found more than 100 Web sites that appeared to have been hacked with this exploit, all hosting malicious Javascript components that were being used by banking Trojans to help automate online account fraud. Gruner said his company notified Joomla about the exploit in early June.

Such a simple attack on such a widely-deployed content management system could be a potent weapon in the hands of crooks who specialize in building Web site botnets. Earlier this month, security firm Arbor Networks warned that it was tracking a Web site botnet dubbed “Fort Disco” which was made up of hacked Joomla and WordPress sites. Earlier in the year, Web site security firm Incapsula said it had tracked more than 90,000 Web sites powered by WordPress that were backdoored with malicious code.

29 thoughts on “Simple Hack Threatens Outdated Joomla Sites

  1. Bill Gates

    Hello. We at Micro Soft are working on fixing this. Please stand hold

  2. Matt Peters

    Wow, that is a really simple exploit.

    I’ve found these to be one of the most frustrating problems lately. You end up blocking small businesses in the area because their website gets compromised and is hosting malware. Now we can’t buy services from them and their reputation suffers. What are they supposed to do? Do I expect the landscaping company to have a security consultant come in and fix their site?

    1. Bruce Jackson

      Joomla Migration / Upgrade services aren’t that expensive – and yes, all infected sites will need fixing or taking offline.

      A better upgrade system in Joomla (such as that finally implemented in v2.5) naturally helps keep costs down for website owners though.

    2. Elin

      What should they do? First apply the recommended fix, which is simple to do. Second review any installed extensions that might be allowing uploads of files. Check the extension developer’s website for updates and also .. go ahead and see if the exploit works. If it does work and there is not a fix, remove that extension or apply the fix yourself which you can get help on at

  3. Barry Shteiman

    We have been looking deeply into CMS systems such as WordPress, Joomla and others lately. There is a clear appetite for Hackers to look into vulnerabilities in CMS software, and more important – custom plugins. there have already been several studies showing both the consumer growth of the CMS deployment, but also the vulnerable stage of it.

    In a webinar that I recently delivered we have looked into a live botnet, that not only uses WordPress as a platform to hack into, but then inject malicious software, install a bot on the server and adding it to the botnet, and then using zombies to continue grow the botnet.

    Its a funny game, since most companies want their CMS up and running, small maintenance windows, and minimum amount of involved developers (hey, we sourced software… it has to be safe) while most of the useful plugins used in order to decorate, add functionality and run the website – include vulnerabilities in them. sad part ? since its a 4th party of a 3rd party application – no one actually owns patching!


  4. Andrew Conway

    I’m a researcher for Cloudmark, the spam filtering company. We’ve been seeing compromised domains used by spammers for a long time, but it’s really ramped up in the past six months, with over a hundred thousand compromised domains being used by a single spam attack. About sixty percent of these are Joomla 1.5. There are a couple of other bugs in this release that are used as well as the recently discovered one. Though patches have been published for these, many sites are still vulnerable. One is a SQL injection attack that allows you to reset the administrator password, and the other is in the JCE plug in which allows you to upload a .php file as a .gif and then use the directory rename function to turn it back into a .php

    There’s software published by a Turkish security researcher at that will scan a list of domains for the latter vulnerability and exploit it if found. We see this being used in the wild to compromise domains. However, it is by no means the only tool used. If a Joomla site is vulnerable we usually see three or four different successful attacks, with several different spammers using the site for call to action URLs, and sometimes sending spam or hosting landing pages. We also see one click DDOS tools.

    Brian, feel free to contact me privately if you want more details on any of this.

  5. IA Eng

    Geezuz, this is so simple a bug, its crazy. I dont use the software anymore but, I am sure there is alot of users who still run it, even extremely older versions.

    When I tried this software in the past, and it was at best, clunky. I opted to use a different software which offers updates to the skins and software on a pretty regular basis.

    Joomla was/is supposedly added to several other software packages and I often wonder what that does to the underlying software itself. One in particular software was a shopping cart, but I do not know how much internal workings of the Joomla product was imbedded into it.

    I’ll email the creator of the shopping cart software and see if he moved away from the Joomla extensions.

  6. RussledMyJimmies


    // Remove any trailing dots, as those aren’t ever valid file names.
    $file = rtrim($file, ‘.’);

    Patch just removes dots, i suspect it could be still exploited.

    1. Alex

      I would need to look in the code but this kind of sanitizing should be before it checks for allowed file extentions otherwise it won’t help. If it would still accept the PHP file to be uploaded this is not a real patch.

      1. Don Gilbert

        As you know, files submitted in forms always get uploaded (unless there’s a check via JavaScript or limits within the upload form) to the /tmp/ directory on the web server. Once uploaded, you use move_uploaded_file() to transfer it to a web-accessible location. The referenced code is run on the name of the uploaded file before it get’s moved, and then it runs through the normal validations, which obviously fail and prevent the file from being moved to an web-accessible location.

    2. Elin

      That’s not the actual fix of the issue. All that part of the code does in the media handler is compare the length of two strings and removing the full stop does make it fail the test, but that isn’t why the processing was wrong. That’s just an added layer of protection for people coming at it from a direction different from the core. There was actually a logic problem when there was a blank file extension.

  7. Canuck

    RE – Fort Disco

    Been seeing a real uptick in scans looking for the three noted files:
    Joomla – administrator/index.php
    WordPress – wp-login.php
    Datalife Engine – admin.php

    What got my attention are the ips being used – rather clean and overwhelmingly coming from US residential ranges (Comcast etc).

    The Arbor Networks article says thus far it’s been targeting websites outside of North America/W.Europe – could someone be putting in more effort than usual and are rolling out their plan step by planned step?

  8. Don Gilbert

    Thanks for posting this and helping to spread the word that people need to update. Security fixes like this need to be installed ASAP.

    It should be noted, however, that 90% of standard Joomla installs are safe from this, even if they don’t apply the patch. The reason is the attacker must have the proper authorization level in order to use the media manager, and by default, the public does not have that permission. Site owners that we (Joomla Security Dtrike Team) contacted about the vulnerability all verified that they had changed the permission levels such that the public was able to upload arbitrary files. That, coupled with knowledge of the system, led to the exploit.

    @RussledMyJimmies, we chose to simply remove the trailing dot because that was the source of the exploit. Having that there caused Joomla to believe the file had no extension, and was thereby a safe file to upload. Normally, a user cannot upload scripts or other executable file types; those are all disallowed by the media settings for allowed extensions. However, the problem still remains that website owners can choose to add “.php” to the allowed extensions list, this opening themselves back up to the exploit if they also allowed public access to the media manager. At that point, there’s not much the Joomla Project can do about it.

    1. A


      The statement regarding Joomla! 1.5.x being vulnerable without authentication is inaccurate. By default this statement is false unless the administrator has loosened security configurations from the defaults applied.

      1. Don Gilbert

        Just to be clear, Joomla 1.5 had no authorization levels in order to protect against this. Core level ACL was added in Joomla 1.7.

        1. CA

          @Don – In versions prior to 1.7, unauthenticated users could upload any file at will as long as it was in the allowed file types list?

          1. brian

            @CA no unauthenticated users could never use this exploit. Only users with access to the media manager (which is not a default registered user) were able to exploit this vulnerability.

            The blog post states that this vulnerability allowed “unprivileged users to upload” but that isn’t true.

            1. DK

              +1 Thank you Brian for the clarification

              I has been trying to reproduce this issue even going back to the original Joomla 1.5.0 and was unable to access Media Manager without authentication.

              In later versions of Joomla 1.5.x the default media manager setting is set to allow “authors” to access media manager. The “author” label has to be set by the admin of the site.

              If your site allows open registration, and a user signs up they are label’ed as “registered” not “authors”, thus they are restricted from accessing media manager.

              It is possible of course for the admin to lower the media manager requirement it to “registered” but that is at the admin’s discretion.

              I am sure there are sites out there that are mis-configured that allow “registered” users access to media manager but that is an admin issue.

              1. Brian

                It is technically possible for a “registered” user to access the media manager but they would not have Upload rights.

                1. Elin

                  Exactly, there are two different actions in the media manager. One allows inserting an image from the filesystem into content. The other allows upload of files. You control who uploads files separately from who can insert images in text. By default the upload rights in 1.5 are restricted to “manager and above” and those users are all users to whom you have granted at least some access to your administrator.

        2. Elin

          Joomla 1.5 has strong fixed access levels. So in Joomla 1.5 a site admin would really have to hack the core in order to allow unlimited public uploads, but it is always possible that an extension developer is bypassing the built in security checks. By default you must be an “author” to upload … but the truth is you should not trust user input no matter where it is coming from, a trusted user can hurt you a lot more and may be a lot more motivated to target you personally. Hence it is really important to filter well for everyone.

  9. CA

    How did you find that the 1.5x versions of Joomla will not require authentication to access/exploit the vulnerable com_media component? Thanks.

      1. brian

        To which Don unfortunately was not clear about as he is relatively new to Joomla. The blog post states that this vulnerability allowed “unprivileged users to upload” but that isn’t true. Unauthenticated users could never use this exploit. Only users with access to the media manager (which is not a default registered user) were able to exploit this vulnerability.

        1. CA

          Thanks for clarifying this. This seemed like a post-auth issue only, until this posting. We need the CVE.

      2. Elin

        @BrianKrebs would you please correct paragraph two, it is factually incorrect and leading to unnecessary upset.

  10. Jonathan Cameron

    This is very similar to the ‘double extension’ exploit. Search for “Why File Upload Forms are a Major Security Threat” on the acunetix com website, and scroll down to cases 4 and 5. Worth knowing!

    1. Elin

      Absolutely and this is the bigger issue in reality. As Joomla developers we need to make sure that end users who don’t know anything about security don’t unintentionally create holes in their sites. If we are going to empower people to turn on file uploads we need to make sure that it is happening safely. We should always err on the side of more safety.

Comments are closed.