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.
Security vulnerabilities within content management systems (CMS) installed on web servers of organisations are often exploited by adversaries. Once a 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 web servers using CMS. The intended audience is individuals responsible for developing and securing websites or web applications using CMS.
Risks to content management systems
An adversary can use automated tools to scan the internet for security vulnerabilities. If a security vulnerability is found, the adversary can attempt to exploit it to gain access to a web server. 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, an adversary can exploit their access to:
- obtain access to authenticated and privileged areas of a web application
- upload malware to the web server to facilitate remote access, for example, web shells  or remote administration tools (RATs)
- inject malicious content into legitimate webpages.
Although a web server may only host publicly releasable information, the compromise of an organisation’s web server is significant as an adversary can exploit the trust of its users. Further, 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.
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.
A common cause of a cyber intrusion is running an out-dated web server and CMS. This makes exploitation of a CMS trivial in some instances. This risk can be minimised by having an established process to test and deploy patches for the CMS, as well as 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 below) need to be patched, as one vulnerable component could compromise the security of the other layers.
Vulnerability assessment of CMS installations
Security controls that aid in assessing CMS installations for security vulnerabilities include:
- using tools to scan CMS installations for security vulnerabilities, for example, CMS-specific tools such as WPScan for WordPress and the Security Review module for Drupal
- conducting vulnerability assessments of 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 for all related services
- using strong passphrases
- ensuring passphrases are stored by the CMS as salted hashes rather than cleartext
- restricting access to the administrator interface for the CMS from approved or internal IP addresses.
Hardening CMS installations
Security controls that aid in hardening CMS installations include:
- using trusted and supported third-party plugins for the CMS
- disabling unnecessary functionality and plugins
- disabling or removing detailed debug or error messages in CMS webpages; webpages that may disclose sensitive debug information, for example phpinfo() pages, should also be removed
- removing 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; note, it is still possible to fingerprint the type and version of a CMS using automated tools such as BlindElephant 
- following vendor advice on best practices for securing CMS installations.
Monitoring CMS installations
Security controls that aid in the detection of unauthorised modification of content hosted on the CMS include:
- using change management to manage deployment of new versions of webpage content
- using source control to manage development of custom code
- using file integrity monitoring to manage and detect unauthorised changes to webpages.
Monitoring services that track compromised websites, such as https://www.zone-h.org and http://www.xssed.com, can be used to check if a website has been defaced. These websites are limited though in that they rely on user reporting, and hence generally only list public website 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 websites.
The Australian Government Information Security Manual (ISM) assists in the protection of information that is processed, stored or communicated by organisations’ systems. It can be found at https://www.cyber.gov.au/acsc/view-all-content/ism.
The Strategies to Mitigate Cyber Security Incidents complements the advice in the ISM. The complete list of strategies can be found at https://www.cyber.gov.au/acsc/view-all-content/publications/strategies-mitigate-cyber-security-incidents.
Vendor advice on best practices for securing CMS installations can be found at:
- Drupal: https://www.drupal.org/docs/develop/security
- WordPress: https://wordpress.org/support/article/hardening-wordpress/
- Joomla!: https://docs.joomla.org/Security_Checklist
- Open Web Application Security Project: https://www.owasp.org.
If you have any questions regarding this guidance you can contact us via 1300 CYBER1 (1300 292 371) or https://www.cyber.gov.au/acsc/contact.