Content Management Systems – An Easy Target?

There is an awful lot to think about when thinking about securing your web server [1]. Taking a step back and thinking about how the bad guys operate is sometimes helpful, and should be an important part of the process.

  • Attackers will rarely be interested in the specific target site (unless it is a large or high-profile target [2]). What the attackers want is large volumes of vulnerable sites which they can compromise.
  • The majority of attackers will use the ‘front door’. If there are known vulnerabilities that are easy to exploit, attackers will use them first. A failure to patch (OS or application) or to disable unnecessary services often gift the attacker free entry.

Content Management Systems (CMS) have become established tools in the creation and management of web sites. Numerous applications are available, the bulk of which are free to use (GPL license). Their ease of use and popularity with hosting providers means that a huge number of sites out there are managed by CMS. This presents an opportunity for hackers – lack of diversity can be a bad thing.

Let’s take a look at an example targeting Joomla! [3] – an extremely popular open source CMS, that is widely used. Around the middle of 2007, a vulnerability was discovered (and publicly disclosed) detailing how to compromise vulnerable Joomla! managed sites. Various attacks where seen shortly afterwards where hackers had managed to upload malicious content within victim sites. Several months later, we are still seeing vulnerable sites being used in attacks. For example, using the vulnerability to upload an exploit script (Mal/Psyme-B) which installs a keylogging application and a malicious trojan (Troj/KillAV-DD) as illustrated below.

[Attack using CMS vulnerability]

I noticed a couple of UK sites attacked in this way over the past few days. The path (.../expose/...) gives a clue to the vulnerable component. In this case it is Expose, a Flash gallery plugin. Just like other CMS, Joomla! supports many plugins. Users need to be aware that a vulnerability in any one of these exposes (apologies for the pun) them to attack.

Aside from patching the CMS and the relevant plugins, there are other steps users can take to reduce their risk.

  • Hide. Take steps to make it harder for hackers to find your site when that scan/search for potential victims. By taking evasive actions such as those listed below, you can help to prevent the simple attacks (for example retrieving administrator password via SQL injection attack).
    • Remove META tags that identify the CMS used
    • Change the default directory names used by the CMS (may be non-trivial).
    • Change the default database and table names used by the CMS (typically db driven).
  • Secure. Ensure all directories have the correct permissions set. Consider how much information an attacker can glean by attempting to request the default admin login page, or a known non-existent page etc etc.
  • Educate. Familiarise yourself with your CMS. Many offer active support and forum pages which provide useful information and security notifications to help you stay secure.

At the end of the day, CMS are terrific. They enable us to create and manage sites very efficiently with minimal fuss. However, failure to consider some of the security implications can leave you exposed. Investing some time in securing systems can save an awful lot of headache later.