Automatic Protection from Vulnerabilities in Concrete5

In April 2015, some engineers from Minded Security performed a secure code review of Concrete5 version 5.7.3.1, the latest stable version at that time. As a result of the test, they discovered multiple security issues, including remote code execution, multiple reflected cross site scripting and SQL injection. The Concrete5 team corrected these vulnerabilities and released a patched version a couple of days later. But during that time a huge number of websites were vulnerable to these attacks.

How Qualys WAF Detects and Protects Against These Attacks

Qualys Web Application Firewall detects and mitigates exploit attempts for these vulnerabilities in Concrete5 using its robust security inspection engine. The WAF appliance evaluates a connection and its payload, and applies a set of security inspection rules that are relevant to the traffic inspected. In this case, standard inspection rules for Remote Code Execution (RCE), Cross-Site Scripting (XSS) and SQL Injection (SQLi) will combine to detect and block exploits of the vulnerabilities detailed below.

Additionally, virtual patching allows users to detect known vulnerabilities within an application and then deploy custom rules to protect the application against specific vulnerabilities and exploits. This provides flexibility to not only deploy default protections to an application, but also to specifically target certain vulnerabilities within the application.

This blend of attack mitigation techniques allow Concrete5 users to be confident in the security of their deployment and to upgrade their Concrete5 instances within normal maintenance timeframes, without needing to cause any additional risk to production applications.

About Concrete5

Concrete5 is an open source content management system (CMS) solution written in PHP. According to the official website, Concrete5 is among the top 5 CMSes used on the web with more than 500,000 websites based on this solution.

First vulnerability: Remote Command Execution

Let’s first talk about the Remote command execution vulnerability on Concrete5. The exploitation of this one must be done in two steps.

The first one is to modify the sender’s email address setting to alter the Sendmail command line in order to add specific parameters to force the Sendmail to log the mail traffic into an arbitrary file. This is the hardest part as the sender’s mail can only be modified by an administrator, but an attacker can force the administrator to do it via a Cross Site Request Forgery attack.

The second step is to register as a new user on  the solution. By sending a specially crafted request containing php code into the mail field an attacker can inject this code into the log file created in the first step. Once this is done, the attacker just have to call the link to the log file to run the injected PHP code.

This attack is critical as it allows an attacker to run code with the web server permission and then gain full access to database or specific files, for example.

Second vulnerability: Cross-Site Scripting

In addition to this RCE vulnerability, multiple reflected Cross Site Scripting were found in the solution. Some user input are used in the HTML code rendered without being validated or encoded. As these XSS are reflected, attacks can be conduct by sending a specially crafted link to the victim. Even if the severity of cross site scripting attack is often considered as medium. This kind of vulnerability can allow an attacker to access the victim’s browser data but also be used to conduct other attacks. On Concrete5 an attacker could use these XSS vulnerabilities to conduct the first step of the RCE attack we have seen above.

Third vulnerability: SQL Injection

The last vulnerability reported publicly is an SQL injection. Some user’s input are used to construct an SQL query without being validated or encoded. It allows the user to modify the SQL query and then change its meaning. It can conduct to a steal of data from the database. This SQL injection can be accessed only from authenticated users with privileges to edit page permissions. Even if the potential attacker must have advanced permissions on the solution, this attack can be considered as critical.