Recently Updated Documents

Securing CMS

Last updated 1 month ago

Download From Source

Securing Content
Management Systems
Introduction
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.

Intended audience
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 shells1 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.

1

https://blogs.akamai.com/2013/10/web-shells-backdoor-trojans-and-rats.html

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.

Mainstream host
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 GovCMS2, 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 (ISM). For more information, refer to
the Australian Cyber Security Centre’s (ACSC’s) Certified Cloud Services List 3.

Patch management
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



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.

Figure 1: Components of a typical web stack

2
3

https://www.govcms.gov.au
https://www.acsc.gov.au/infosec/irap/certified_clouds.htm

2

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.

Account management
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 BlindElephant4



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.

4

https://community.qualys.com/community/blindelephant

3

Further information
The Australian Government Information Security Manual (ISM) assists in the protection of information that is
processed, stored or communicated by organisations’ systems. This publication can be found at
https://www.acsc.gov.au/infosec/ism/.
The Strategies to Mitigate Cyber Security Incidents complements the advice in the ISM. The complete list of
mitigation strategies and supporting publications can be found at
https://www.acsc.gov.au/infosec/mitigationstrategies.htm.
Vendor advice on best practices for securing CMS installations can be found at:


Drupal: https://www.drupal.org/docs/develop/security



WordPress: https://codex.wordpress.org/Hardening_WordPress



Joomla!: https://docs.joomla.org/Security_Checklist



Open Web Application Security Project: https://www.owasp.org.

Contact details
Organisations or individuals with questions regarding this advice can contact the ACSC by emailing
asd.assist@defence.gov.au or calling 1300 CYBER1 (1300 292 371).

4