This article aims to present how easy is to overlook the security of (some parts of) the application, leaving widely used CMS systems insecure despite its popularity, open source approach and the multitude of testing performed already. The same issues will apply to other products used by your company if your testing scope is not well defined or security testing is not handled properly.
Whether you have an internal security team, you order penetration tests on a regular basis or just writing some code we show you why it is so crucial to get the testing phase right. Maximize the effectiveness of your efforts to protect your users, data and your brand.
XSS in Drupal 8.7.0 and PrestaShop 22.214.171.124,
Update to PrestaShop 1.7.6 (beta or later)
Scope your penetration tests correctly with experts from Logically Secure to avoid this.
In today’s world, it is often believed that a widely used opensource product is trustworthy. One would assume that the standard Content Management Systems (CMS) like PrestaShop, Drupal or WordPress have been tested over and over on multiple occasions. For instance, internal testing by application and plugin developers on each release, clients and end-users spotting the bugs as well as by security companies testing the whole product on a routine external web penetration tests.
However, there is a missing piece that largely defines the level of effectiveness of security-related efforts on those products, a test scope! A good test scope allows determining the current state of the product security in whole, exposing all risks. On the other end, a poorly conducted scoping or poorly chosen test scope can lead to penetration test results that are close to the results of spinning the wheel of fortune (despite skills of the testers).
We have taken a set of popular CMS systems (Joomla, WordPress, Drupal, PrestaShop) to test the unusual parts of the applications and check if all user journeys have been thoroughly tested. A properly scoped test (with no budget nor time constraints) ensures that all user journeys are covered in equal depth by the test and all potential risks are attempted to be discovered.
Whilst the typical test will focus only on the front end of the webpage, and sometimes on a backend of that system, we wanted to map all user journeys starting from the very beginning. A first application flow to be ever executed and which could be targeted is an installation stage.
We have tested an installation stage on below products:
- Joomla 3.9.6
- WordPress 5.2
- Drupal 8.7.0 (and 7.66)
- PrestaShop 126.96.36.199
The test focused on Cross Site Scripting (XSS) type of vulnerabilities only, however, other insecure behaviour was noted. We discovered two instances of reflected Cross Site Scripting (XSS) in the installation scripts. The XSS vulnerability is very dangerous and is listed on OWASP TOP 10. These scripts in CMS products often present huge insecurities by being exposed as pointed out by Hanno Bõck during his DefCon talk (https://www.youtube.com/watch?v=TMNeSnjZfCI). Despite vendors not fully addressing his concerns, this does not mean we should discard all vulnerabilities in this particular user journey. At the end of the day, this will affect all system administrators – higher privileged users in the company.
The Drupal CMS system seemed reasonably immune to XSS vulnerabilities, filtering longer HTML tags completely at each stage of the installation. We have found a false positive of Form Hijacking (at the very first page with language selection), it is suspected that browsers implemented some countermeasure for this attack or the Proxy tool incorrectly interpreted syntax.
However, not all error messages were sanitized correctly. This allowed testers to manipulate the website look with the HTML code injection (limited reflected XSS) by injecting <a> and <div> tags. Below payload ‘alert(1)a’ in a ‘driver’ parameter appears as a link. This can be further modified to steal user credentials, for instance showing a nice message of ‘Please login here to resolve this error’.
In addition, it was possible to load an external resource using an <IMG> tag. Loading an External resource shows the risk that a user can be forced to load external malicious scripts, frames to capture the details or to simply redirect his/her attention. This POST request can be executed directly, no additional user interaction is required.
PrestaShop has shown a lot less resistance against these types of attacks. Standard XSS payloads worked on vulnerable parameter ‘shop_country’ in a simple GET request. However, the exploitation by malicious actor requires extra steps to first trick the user to follow initial stages of setup (accepting terms and conditions) before executing a malicious link. It is worth noting that PrestaShop acknowledged this issue and worked on the patch. Please update to PrestaShop 1.7.6 release.
In both cases, these risks were omitted, not publicly disclosed. Most likely this user journey has never been security tested that thoroughly on this codebase.
To conclude, it is important to ensure that you are supplying all documentation for a white-box security test, thus allowing the testing company to correctly and in entirety get familiar with the product or solution and scope the test. It is also important that you consider all application flows to be tested. If you cannot afford to do so in a first round of testing, make note of the scope exclusion and request it to be tested the next time.
If you are wondering how to approach security for your product or company and which way may be the most cost-effective way, please also read this article which I wrote last year (https://www.computerweekly.com/opinion/Security-Think-Tank-Balancing-cost-and-risk-in-software-vulnerability-management)
Discovered by Alexander Drabek
CVE number: CVE-2019-11876
Discovery and PrestaShop informed on 7th and 8th May 2019
Vendor acknowledgment 9th May 2019
Discovery and Drupal informed on 7th and 8th May 2019
If you would like more information about our methods for scoping or testing, please contact us here and we will arrange a call or demo of our technical services.