Securing Content Management Systems
Download ACSC Protect Securing Content Management Systems (350K PDF), July 2015
- The security of external-facing infrastructure is critical for organisations when considering the security of their network as a whole. Even if external-facing infrastructure does not host sensitive information, there is still a significant risk to the reputation of organisations if external-facing infrastructure is tampered with.
- Vulnerabilities within content management systems (CMS) installed on the web servers of organisations are often exploited by adversaries. Once the CMS has been compromised, the web server can be used as infrastructure to facilitate targeted intrusion attempts.
- This document outlines strategies for identifying and minimising the potential risk to websites using CMS software. The intended audience is individuals responsible for developing and securing websites using CMS.
Risks to content management systems
- Adversaries can use automated tools to scan the Internet for web application vulnerabilities. If a vulnerability is found, an adversary can attempt to exploit it to gain access to the system. Typically these compromises are opportunistic and the result of the poor security posture of the victim rather than a targeted cyber intrusion.
- Once a CMS has been compromised, adversaries can exploit their access to:
- obtain access to authenticated and privileged areas of the site
- upload malware to the web server to facilitate remote access, for example, web shells or remote administration tools (RATs) (A web shell is a type of remote administration tool that is designed to be deployed onto a web server. For further reading, consult Akamai: Web Shells, Backdoor Trojans and RATs.)
- inject malicious content into legitimate web pages. This could be used to serve exploits or malware to visitors or to facilitate remote access to the infrastructure.
- Although the web server may only host publicly-available information, the compromise of any organisation’s web server is significant as an adversary can exploit the trust of users of that website. An adversary can use a compromised web server as part of a ‘watering hole’ attack, or as command and control infrastructure to facilitate other intrusions, for example, compromising an organisation with malware that is configured to receive commands from a compromised web server. A system administrator may look at network traffic communicating with a trusted domain and dismiss it as legitimate.
Minimising risks and improving CMS security
- The most common causes of CMS compromises are due to security oversights. Some of the most effective mitigations are listed below.
- As an alternative to hosting and maintaining a CMS on your own infrastructure, consider using a managed CMS hosting service. Managed CMS hosting services maintain web infrastructure and content management applications, offering support and facilitating timely patching.
- Government customers can use govCMS, which is a hosting service for Drupal-based websites.
- For data that is not considered publicly releasable, use an outsourced service that has been assessed, certified and accredited against the Australian Government Information Security Manual at the relevant classification level. Refer to ASD Certified Cloud Services List.
- A common cause of cyber intrusion is running an out-dated web server and CMS software. This makes exploitation of the CMS trivial in some instances. This risk can be minimised by:
- having an established process to test and deploy patches for the CMS software
- patching the host operating system and third party applications, including themes, frameworks and libraries, used by the CMS.
- A CMS runs on a package of software known as a web stack. Additionally, organisations may employ third-party applications or custom site-specific code. All of these components (as shown in Figure 1) need to be patched, as one vulnerable component could compromise the security of the other layers.
Vulnerability assessment of CMS installations
- Use web vulnerability assessment tools to scan CMS installations for common vulnerabilities. Scanning tools are available on the internet, for example, Arachni or CMS-specific tools such as WPScan for WordPress and the Security Review module for Drupal.
- Conduct vulnerability assessments on custom code or modules that are used for CMS deployment.
- Poor management of legitimate access can lead to the compromise of a CMS. This risk can be minimised by:
- changing default usernames and passwords, including all related services, such as database access
- using strong passwords / passphrases
- ensuring passwords are stored by the CMS as salted hashes rather than cleartext - this prevents an adversary from obtaining cleartext passwords in the event of a compromise
- restricting access to the administrator interface for the CMS from approved or internal IP addresses.
Hardening CMS installations
- Use trusted, supported third-party plugins for the CMS.
- Disable unnecessary functionality and plugins. By removing unneeded functionality you reduce the attack surface available to adversaries.
- Disable or remove detailed debug or error messages in CMS webpages. Web pages that may disclose sensitive debug information, for example phpinfo() pages, should also be removed. An adversary could use this information to profile a CMS and identify out-dated software or plugins that may be vulnerable.
- Version information that may be displayed by default on CMS webpages, for example, in the page footer or in the meta tags on each webpage, should be removed. Note, it is still possible to fingerprint the type and version of a CMS using automated tools such as BlindElephant.
- Follow vendor advice on best practices for securing CMS installations. Refer to references below.
Monitoring CMS installations
- Controls that aid in the detection of unauthorised modification of the website hosted on the CMS:
- using change management to manage the deployment of new versions of your website
- using source control to manage development of custom code
- using file integrity monitoring to manage and detect unauthorised changes to webpages. A properly configured file integrity monitor will assist in detecting modification of legitimate content and additions of malicious scripts.
- Monitoring services that track compromised websites such as zone-h.org and xssed.com can be used to check if your site has been publicly defaced. These sites are limited in that they rely on users to report compromised websites, and hence generally only list public site defacements. It is highly unlikely that in the event that a CMS is compromised and used as command and control infrastructure it will be listed on these types of sites.
- Drupal: Securing your site
- Joomla! Security Checklist
- Open Web Application Security Project
- WordPress – Hardening WordPress
Australian government customers with questions regarding this advice can contact ASD Advice and Assistance.
Australian businesses and other private sector organisations seeking further information should contact CERT Australia.