security week

A week of security

Apologies to regular readers for the lack of updates this week but it's been a very interesting few days.

Almost all my work this week has in some way or other been in the security sphere.

The week started with two days joomla training for a company who wanted to use joomla to build a very specific application for their client (who can't be named - but they fly very fast planes).

Joomla was to be used to replace an existing application for all the obvious reasons, ease of adding and updating content, customisation, visual appearance etc.

Unfortunately neither myself nor the company are able to see the end-clients original application for security reasons so we were both working from screenshots. Having to make a guess from a screenshot as to the functionality required was, and is, challenging to the say the least.


Returning from this client I received an urgent request to perform some apache log analysis for another client who had received threatening emails via their website.

Reading apache logs isn't that hard if you have the right tools and know what to look for but your eyes do tend to go a bit squiffy after a while of staring at log files.

Once I had identified the IP address of the miscreant I was able to trace them back to their ISP and make an appropriate report on this persons illegal activities for the responsible authorities.


Taking a break from regular work I decided to spend a few hours checking out some joomla extensions that are all highly recommended on extensions.joomla.org and I've never had the time to install.

Whenever I get a new extension I always have a look at the code "before" I install it. Mainly it's so that I can try and learn from the developer but also so that I can check for any obvious security issues.

Usually that only extends to checking for the ubiquitous "exec or die" statement that should be present at the beginning of all the php files to prevent them being accessed outside of the joomla framework.

// no direct access

defined( '_JEXEC' ) or die( 'Restricted access' );

Occasionally I spot something more ominous like "call home" functions or even hidden advertising links but this week I spotted the following in a popular extension with a 4.5 star rating.

chmod(JPATH_SITE.DS.'administrator'.DS.'modules'.DS.'mod_xxxxxxx',0777);
chmod(JPATH_SITE.DS.'administrator'.DS.'modules'.DS.'mod_xxxxxxx'.DS.'mod_xxxxxxx.php',0777);
chmod(JPATH_SITE.DS.'administrator'.DS.'templates'.DS.'khepri'.DS.'images'.DS.'header',0777);

No extension should ever chmod any file to 0777 and especially not a core joomla file as in the case of this particular extension.


Back to work and there was a quick request from another site developer to clean up a hacked web site. Two hours later I had removed seven different hacks that had occurred over the last year.

Each one had left behind c99 shell script variants which you really don't want on your server even if they are dormant.

In total I had to clean and remove almost 100 files, not a pretty site and all because the client never upgraded their software when known security vulnerabilities were revealed.


Just to round off the week there was another security issue to work with but more of that in another blog post.

The web was meant to be read, not squished.
This isn't the way to test a responsive design.