Top Content Management System Vulnerabilities

Every application and server has contact surfaces with at least a few other entities or domains. Typically, a web interface that is facing the public internet has been considered to be the most vulnerable and “risky” when it comes to vulnerabilities. Indeed, if a surface is accessible for the whole world, things can get complicated rather soon.

Further, if anyone can contribute, upload, manage or manipulate content, more potential vulnerabilities are sure to emerge, some more popular than others, but we’ll be talking about top content management system vulnerabilities that we’ve been detecting by analyzing around 3000 hacking incidents a day.

Top Content Management System Vulnerabilities in 2017

Vulnerabilities can also occur within the system, even just on the operating system level. Privilege escalation exploits are common means for an attacker to escape any non-admin user cage and gain full permissions on the target system. These nasty vulnerabilities that still occur every now and then, various defenses have been promoted.

Furthermore, various social engineering attacks might easily defeat many technical measures which were deployed to secure the process of content management. Most challenging ones might very well be those that make use of a mix of a wide range of attack types and vulnerabilities.

Attack vectors and vulnerability types evolve also during the time, still, some old methods are proven to be successful even after tens of years of vulnerability management and patching. A distinctive recent type of vulnerability, cross-site scripting (XSS), combines weaknesses in the client side execution environment creatively with backend flaws of eg. lack of verification of parameters and content.

Many of the vulnerabilities of web content management systems are not specific to web content management but inherent to web technologies, server environments, and protocols as a whole.

What is XSS – Cross-Site Scripting

This attack vector, or vulnerability, exploits both the client environment (that is the javascript execution environment within the browser process for the most) and the lack of parameter and content sanitization on the server side. This allows an attacker to inject code, arbitrary code onto the target web application.

However, this is radically different from the traditional “code execution vulnerability” as in this vulnerability the injected code is executed on the client side instead of on the server infrastructure. This limits the immediate technical scope of the attack, but when properly constructed, exploits using this mechanism can be more destructive when it comes to user privacy, actual content served and even allow manipulation of the database and stored variables.

This type of vulnerability is increasingly common, particularly with web content management systems that are highly web-oriented in their technical architecture. On the other hand, with client-side execution environment disabled, the large part of the XSS attack vector becomes ineffective.

Open Source content management systems like Drupal and WordPress exhibit larger numbers of vulnerabilities of this type, likely due to their heavier use of the client-side environment, at least when compared to classic corporate-oriented frameworks like SharePoint where server-side remote vulnerabilities are more common. Because of the emerging number of third-party CMS plugins, XSS remains to be one of the top content management system vulnerabilities.

Tip: Scan here to see if your website has security headers in place, to make the first step to protecting the website from cross-site scripting.

What is Arbitrary Remote Code Execution

Injecting code into an application can have lethal effects on the privacy of the user and stability of the system as a whole. Code injection within the same local execution environment may be easier than many thinks, yet remote injection is traditionally considered to require specific knowledge or tools.

At least, it requires a vulnerability that provides a surface, however narrow or rare, for a remote attacker to send a piece of code for the remote execution environment, which too naively without further evaluation would run freely.

This can open remote backdoors, for attackers to gain full console access to the target environment – in many cases without any indication of an attack having occurred for the end user or administrators.

Many of modern day attacks exploited remote code execution vulnerabilities, either on the web surface or within other more specific and narrow-use protocols and ports. Full-scale remote code execution vulnerability, even when exploited against a web content management system, often derive from the underlying platform instead of the high-level content management application. PHP scripting language, .NET environment or a database or file sharing interface are all potential targets, some earlier victims, of remote code execution vulnerability.

As this kind of vulnerability typically may be located on a lower level than within the CMS system itself, they can oftentimes be patched by changing underlying methods and function calls to avoid using or exposing vulnerable parts of the lower level system. For this matter, eg. PHP hosting environment is often hardened by disabling specific functions on the platform level that are known to have been exploited (eg to run operating system shell commands from the web server context).

Another variation of this kind of remote code execution attack is for attackers to target client environments instead of the remote infrastructure. Client environments, endpoints, may be more interesting and also less protected for some attackers. This type of attack is technically a local code execution attack, but it is delivered remotely, eg. using a decoy attachment.

A file, in this case, includes an exploit that is triggered on the client (now “remote”) environment, allowing, for example, backdoor installation or just console access to the compromised host. Both types of attack may use similar “payloads”, yet the delivery mechanism is different. Content management systems need to increasingly ensure that they would not be misused as launch-pads for client exploits of this type as well. Unfortunately, it has made its way to top content management system vulnerabilities in 2017.

What is SQL Injection

Video by: Christian Linares

Most modern content management systems still rely on a database backend, typically a SQL database. There is a growing trend to develop “headless” systems, which rely more on client-side processing and storage. Still today, backend databases are common, and oftentimes those fail to implement user-level authentication and instead rely on application-specific credentials. When the web layer is vulnerable to a nasty thing, SQL injection, the whole database may be compromised.

Similar to other code injection mechanisms, by definition, this type of attack is used to issue arbitrary SQL code directly into the database layer. This type of vulnerability is often due to lack of parameter sanitization. It enables the attacker to issue direct database commands to manipulate the database directly.

This is still one of the top content management system vulnerabilities out there today, despite a long history of awareness and particularly simple defenses available. Sometimes, however new injection points are revealed, and proper parameter value sanitization practices should be taken as bare essentials for any input value processing. Regardless if it could be an entry point for SQL injection attack.