September 5, 2007

About third party packages in hosted CMS’s

Filed under: joomla,webapplications — admin @ 2:26 pm

Recently we had an incident on one of our PHP-Hosting servers and everyone could learn once again a bit more about security and how important it is to track all the software-versions installed on a server. However first we want to post some facts:

  1. One Joomla website defaced
  2. No other hosted websites affected, nor spied
  3. Defacement could have been avoided
  4. Nothing more happened, but everyone has to learn something

Turkish script kiddies defaced a little Joomla website hosted by us and called them self the bloodiest terror group :P. Unfortunately none of our administrators was near a computer and the Joomla users simply replaced the defaced index.php with an original one. However the defacement happened again and again and it was obvious that this is very nasty. Finally when someone of us could have a look at the site, we saw that we have done a mistake from our side which made the Joomla installation completely writable by the web server. This is very bad from our side, as we try to avoid such setups in normal and try to restrict write permission per default to a minimum. However nobody is perfect, so such things might happen and it is important that everyone using our systems is also watching on our fingers. So we fixed these settings and thought that it is done with that.

Unfortunately one week later the defacement happened again and this time not the index.php was replaces by their ridiculous statement: the whole configuration.php (Joomla configuration file) was overwritten. But why was it still writable? Well CMS’s are normally chosen because they are nice and simple to use. And therefore their configurations files have often to be writable by the web server. This is a severe security fact, however most user want this as they don’t want to upload the configuration every time by ftp. This was why we had enabled that overwriting of the configuration.php is possible.

So we restored the configuration.php (as it was completely overwritten with the defacement) changed the MySQL password (as this is normally in the configuration file and was accessible therefore by the script kiddies, however we don’t think they were interested in that) and locked from now on for security reasons every configuration.php on our host to be overwritten by the web server. Just a little side note on that: Normally when we setup a new Joomla-Site, we told the people that currently the configuration.php is writable and for security reasons they should tell us when they finished with configuration don’t need to change it anymore, so we can lock it. However less than 10 percents of the Joomla users told us in the past to lock the configuration.php. :-/ So now every configuration.php is locked per default and we learned that we have to insist more on this issue.

After restoring the page we could then examine how the page was defaced. While searching for actual possibilities to deface Joomla websites, we found a posting which lead us to some issues with a third-party gallery module. So we found out that there was exploit publicly posted in the mid of July and a fix for this exploit 1 day later (FOSS rules!). So we examined more about this exploit and found out that exactly this was used to upload some php-script which contained some kind of a web-shell. A so called swiss-army-web-knife in php. This shell then could be used to step through all folders of the installation and edit any files which were writable by the web server (index.php and configuration.php). However due to our open_basedir restrictions they could not access any other folders on our server than the application’s one. Yes we know that there are possibilities for advanced white and black hats to walk around this restriction however for these script kiddies it did its job. 🙂

They uploaded as well other php scripts as well some Perl scripts which could have been used to run some irc-bots and which could have been used to attack as well other servers from our server. However they were completely unusable on our servers, as our (we hope) secure setup avoided them to be executed.

So finally we removed all the uploaded scripts, patched the third party module with the update available since a month, informed the Joomla-users about our examination and since then their site wasn’t defaced anymore. So we all could learn once again some stuff about security:

  1. Security can not be delegated, everyone is responsible for it
  2. Nobody is perfect, everyone can make mistakes which lead to security issues
  3. Tracking the version of your current installed software, modules etc. is important! If the update would have been installed the site would have never got defaced
  4. Hosters can (but this is already very hard and a lot to do) only watch the versions of the main application, but they can not automatically know which third party modules you install nor they can track the versions. The best thing is that you look on yourself that your application is uptodate
  5. A safe setup can avoid of much more damage. (Access all the other setups etc.)
  6. Security gives a lot to do!

Therefor we want once again to remind you to:

  1. not delegate security to us…
  2. track the versions of your installed software…
  3. be aware of security issues, harden your application and work with us together to make our hosting a more secure place

Thanks!

July 22, 2007

give mod_security a try

Filed under: apache,mod_security,webapplications — admin @ 6:08 pm

We recently installed and activated Mod Security on our PHP and Perl Hosts. It seems to be a resonable tool to have attackers as well spammers (and this seems to be the most interesting part) away from your webapplication. However it needs a certain configuration and continous monitoring and might break your web application as there might be valid requests which will match agains the regular expressions of the tools.

So it might be good to start with it on only certain vhosts and the customizing the rule sets. You can as well define the rules for each vhosts, as well maybe adding specific rules.

Note to hosted sites: it might be that your site now breaks. 🙁 We could not test everything however we tried to monitor the servers a bit and figure out problems.

For installation notes, as well further infos, have a look on our wiki-page. Would be nice if other people contribute some infos: http://www.immerda.ch/index.php/Mod_Security

Proudly powered by wordpress 4.7.5 - Theme by neuro