• Abstract and Figures
• Public Full-text

Over 100 Bugs in a Row: Security Analysis of the Top-Rated Joomla Extensions Marcus Niemietz, Mario Korth, Christian Mainka, Juraj Somorovsky fi[email protected] Hackmanit GmbH Abstract like WordPress and Joomla. There exists a family of tools Nearly every second website is using a Content Manage- which, inter alia, allow researchers and penetration testers to ment System (CMS) such as WordPress, Drupal, and Joomla. scan CMS software (e.g., WPScan [4], JoomScan [10]) for These systems help to create and modify digital data, typically well-known issues. Although community-based projects like within a collaborative environment. One common feature is to Joomla make use of tools like static source code scanners, it enrich their functionality by using extensions. Popular exten- seems to be a non-trivial task to detect well-known vulnerabil- sions allow developers to easily include payment gateways, ities such as XSS and SQLi, as shown by security researches backup tools, and social media components. multiple times [29]. To provide an example, Joomla intro- Due to the extended functionality, it is not surprising that duced the usage of the code analysis tool RIPS in June 2018 such an expansion of complexity implies a bigger attack sur- [7, 16]. Although RIPS is explicitly designed to detect web face. In contrast to CMS core systems, extensions are usu- vulnerabilities like XSS, Joomla has officially announced 30 ally not considered during public security audits. However, security vulnerabilities within the first half year of 2019, and a Cross-Site Scripting (XSS) or SQL injection (SQLi) at- 12 of them were XSS issues [17]. tack within an activated extension has the same effect on On the Importance of CMS Extensions. Nearly every the security of a CMS as the same issue within the core it- CMS includes multiple extensions which add new function- self. Therefore, vulnerabilities within extensions are a very ality to the core systems. However, the CMS extensions also attractive tool for malicious parties. enlarges the attack surface. As an important aspect, the core We study the security of CMS extensions using the exam- of the CMS and the extension share the same privileges. Due ple Joomla; one of the most popular systems. We discovered to the missing isolation, a vulnerability in a popular extension that nearly every second installation of such a system also might have the same impact as a vulnerability within the CMS includes Joomla’s official top-10 rated extensions as a per se itself. requirement. Moreover, we have detected that every single Despite their security importance, CMS extensions are, in extension of the official top-10 rated extensions is vulnerable contrast to the CMS core systems, usually not covered by to XSS and 30% of them against SQLi. We show that our public security audits. To highlight this gap, we analyzed the findings are not only relevant to Joomla; two of the analyzed security of extensions from one of the most popular systems arXiv:2102.03131v1 [cs.CR] 5 Feb 2021 extensions are available within systems like WordPress or called Joomla. Drupal, and introduce the same vulnerabilities. Finally, we Our Approach. Due to the high number of nearly 8,500 pinpoint mitigation strategies that can be realized within ex- Joomla extensions, we restricted our focus to the top-10 rated tensions to achieve the same security level as the core CMS. and freely available extensions within Joomla’s official ex- tension directory. Moreover, we concentrated on the two top- 1 Introduction rated Open Web Application Security Project (OWASP) in- jection risks namely XSS and SQLi. Our aim is to answer the More than half of the Alexa top-1 million websites are using following research questions: a CMS [31]. Among these systems, WordPress, Joomla, and 1. How many Joomla installations have deployed the top- Drupal are the most popular brands with a combined CMS 10 rated extensions among the Alexa top-1 million web- market share of over 69%. It is therefore an important task to sites? analyze their security. These CMSs are frequently audited by third parties due 2. Are Joomla extensions vulnerable to the well-known to their importance, especially widely deployed software attacks XSS and SQLi? If so, what is the root cause of 1 such security issues and what can we learn from them? Reflected Cross-Site Scripting. The first step of a reflective XSS attack is usually to send attack vectors defined by the 3. Can we assume that at least one top-rated and maybe attacker to the server via an HTTP GET or POST request. vulnerable extension is always activated within Joomla After analyzing the server response message, the attacker installations? If so, does a vulnerability within an exten- checks whether the attacker’s code was (partially) displayed sion have the same importance as a vulnerability within and therefore reflected. If this is not the case, the attacker can the CMS core? try another testing code; otherwise, the attacker will abort the If extensions are a tool which is always available and acti- attack on the given resource. vated within a CMS, this would imply that we should always The successfully executed testing code can show characters consider extensions with the same priority as the CMS core. that are necessary for the attack, for example if < or " are not Otherwise, an extension might be the weakest link of a com- filtered by the server. In the case of an HTTP GET request, plex chain if it is vulnerable against attacks. the attacker can then prepare a link pointing to the vulnerable Empirical Study. We detected that all analyzed extensions web application with a malicious JavaScript code embedded are vulnerable to XSS and 30% of them are vulnerable to in the query string. In the event of an HTTP POST request, a SQLi. We responsibly reported and disclosed 103 vulnerabili- prepared HTML form can be used, which is auto-submitted ties across multiple CMS’s whereas 86 vulnerabilities were as soon as the attack page is loaded. within Joomla extensions. By investigating extensions which Stored Cross-Site Scripting. As another server-side vulnera- share the same code and, therefore, the same vulnerabilities bility, stored XSS occurs when the attack vector can be stored for multiple CMSs, we identified 11 vulnerabilities within persistently in the vulnerable web application (e.g., malicious WordPress extensions and 6 vulnerabilities within Drupal code inside a log file or database). Each time a victim visits extensions. the part of the web application where the vector is saved, it is Contributions. Overall, we make the following contribu- executed. tions: DOM-based XSS. Contrary to reflected and stored XSS, the • We detected that all of the top-10 rated Joomla exten- cause for DOMXSS lies in the browser of the user itself; for sions are vulnerable to XSS and 30% of them are vulner- example, client-side JavaScript code provided by the server. able to SQLi. This JavaScript code takes some input of the client and at some point uses it at a sink such as innerHTML. This can • We show that 40.9% of the Joomla installations within result in the injection of arbitrary HTML or JavaScript code the Alexa top-1 million websites include at least one of and therefore XSS. our tested top-rated extensions and are, thus, vulnerable to the discovered attacks. 2.2 SQL Injection • We developed an open-source tool for detecting XSS vulnerabilities in web applications which use metadata An SQLi occurs when improperly sanitized user input is used within media files. in the construction of SQL queries. The problem arises usu- ally when the whole query which was constructed by the • We identify possible root causes of the detected vulnera- application is submitted to the SQL server instead of the bilities and demonstrate generalizability by evaluating query with placeholders for the parameters (e.g., prepared that extensions which are available for multiple CMSs statements [13]). Therefore, the SQL server cannot distin- also have the same security vulnerabilities. guish between the input of a trusted and a malicious user; for Artifact Availability. In the interest of open science, we example, selecting another database although just an integer have published our tool Metadata-Attacker as open-source was expected. Hence it simply parses the query and executes online. it, which in the end can lead to an SQLi if an attacker was able to insert arbitrary statements. 2 Foundations 2.3 Joomla 2.1 Cross-Site Scripting Our tested CMS called Joomla uses a strict Model-View- We consider all three XSS variants that are mentioned Controller (MVC) architecture. Joomla’s extensions can be ei- as OWASP top-10 injection threats as relevant: re- ther a module, component, plugin, template, or language [18]. flected XSS, stored XSS, and reflective DOM-based XSS Beyond the applications base directory, there are common (DOMXSS) [20].1 folder paths for every Joomla installation and its extensions. Additionally, unless explicitly changed or replaced, each 1We left out persistent DOMXSS [26], because one of its requirements is to have another XSS to write into the persistent client-side storage. This is Joomla installation contains a robots.txt and web.config. covered by seeking for reflective XSS and DOMXSS. txt file which contain identifying strings. Some native com- 2 ponents are delivered with identifying eXtensible Markup an XSS attack vector. To detect DOMXSS vulnerabilities, Language (XML) files. Hence it is possible to identify a we are using the methodology provided by di Paola [8]. By Joomla installation by requesting some of those identifying reusing the provided regular expressions as search patterns, files. we looked for sources (e.g., document.location) and sinks (e.g., document.write) within the Document Object Model (DOM) that could introduce DOMXSS vulnerabilities.

Load more

  10

Copy Link