Content Management Systems are what you choose when you are not willing to build and to administrate a whole new front and backend for a website and if your content creators are not familiar with developing source code. While running your Joomla CMS there could come new demands in the matter of functionality or design from you or your users. The fast and easy way is to install a plugin that will do the magic. But that may lead to new vulnerabilities in your system. In particular, file uploads are a possible attack vector. In this article, we will talk about vulnerabilities through files and plugins.
1. Joomla CMS Security: 3 Facts a Developer Must Know
When developing and contributing to an open-source project, you should follow best practices, mind security, interoperability and the possibility of deprecated code. There are some ways to achieve these goals. The first step to a good piece of code is checking it for deprecated libraries and known vulnerabilities. You may do this by hand, or check it with a static code analysis like RIPS, which is now a part of SonarCube. You should also check your code with the help of CVE’s if possible. Moreover, you could also be a target for hackers if you are developing plugins for CMS’s. How? If the quality of your code is not state of the art in matters of security and vulnerabilities, your hard work could become an entry point for a Supply Chain Attack[1]. Apart from these two facts, you always need to know your configurations. The best code and the safest plugins can not save you from the aftermath of a wrong configuration. So now you may ask: ‘What to do with these responsibilities while developing and using plugins?’ We will come to that later in the article after an introduction of the most common vulnerabilities in the file upload. Because that is a thing that you may not control when using a CMS with more than one participant.
2. Common Vulnerabilities and File Uploads
No system should rely on security through obscurity. Especially an open-source project such as Joomla offers the possibility to analyze the source and abuse vulnerable code. As with every kind of user input file uploads are a potential attack vector. Joomla offers the possibility to upload files for authorized users by using the media manager. Per default user roles such as Manager and Administrator are allowed to upload. Besides the default roles, custom roles and groups with the associated rights are of concern as well. The Open Web Application Security Project (OWASP) points out that the consequences can vary. Exemplary consequences are complete system takeover, database/filesystem overload, client-side attacks, or server-side attacks. OWASP differentiates between two classes of problems [2]. The first class consists of file metadata problems, e.g, the path the file gets stored or the file name in general. The second class contains problems with the content or the size of the file.
One famous example is the ImageMagick flaw also known as ImageTragick. ImageMagick is heavily used as an image processing library and the foundation of language-specific bindings, including PHP imagick, Ruby’s rmagick and paperclip, and nodejs’s imagemagick[3]. So processing images on the web more often than not use this library. In 2016 a severe vulnerability was found, which allowed remote code execution ( CVE-2016-3714 ). Joomla extension around this time (Joomla 3.5) that used the popular ImageMagick instead of the GD Graphics Library could have been affected by this finding, by trusting, a, to be honest, well established 3rd party library.
The second example is about a severe Joomla vulnerability found in 2015. David Jardin, the team leader of the Security Strike Team, gave an interesting talk about it. This vulnerability is a creative chain of attacks. The first attack is a PHP Object Injection. A Bug in PHP causes to transform invalid session data into something that PHP considers valid. This enabled an attacker to manipulate session data and therefore inject forged objects into a serialized session. By using the Joomla disconnect handler that is called after a request is finished, the attacker was able to exploit a init function of an object of a library called SimplePie, which is not used anymore. SimplePie parsed a string as an URL as long as the string contains double quotes, without throwing any errors or warnings at all. The string in that case was PHP-code. SimplePie further used some caching functions, which used the PHP function assert. Assert then executes code. This concludes with an attacker being able to provide a forged request payload that gets decoded and then executed. This is also called a Remote Code Execution.
File uploads are potential attack vectors. Hardening the security of user input, e.g, images, text files, etc., is invaluable and absolutely necessary. The Joomla 4.0 release includes a remake of the media manager. A brand new user interface, an additional set of cool features and a challenge from the security perspective. As part of the Web Programming Weeks of the University of Applied Sciences Mittelhessen, we tried to put the upload function of the media manager through its paces. Chapeau, Joomla! You won this time. We tried XSS attacks, file bombs, encoding malicious code in image files etc, but nothing useful came out of it. Or did it?
Overall the Joomla core seems really safe, and the reality shows that it’s rare to identify severe vulnerabilities and it’s even rarer for the vulnerabilities to damage the users before the JSST has time to react. But what about functionalities that are not in the core?
3. The Responsibility Problem of Plugins and Dependencies
Nowadays, everyone is on the run for the newest, best, fanciest functionalities, usabilities and designs. The Users of Content Management Systems do not exclude themselves from these demands. But the integration of every possible requirement is impossible for the core projects in the CMS-World. The solution is a common one: Plugins. Administrators can install every plugin their users and wish to work with. This option brings a lot of individual customization with it and even more responsibility. While the Joomla-cms project is continually developed, tested and reviewed, plugins out of the project are not necessarily. In short, every plugin could cause a possible threat to the security of a running Joomla installation. With that in mind, the Joomla security team tried to implement a checking mechanism to test plugins. Using RIPS, which is now a part of SonarCube, they did static code analysis with the plugins. Through the fact that every plugin could be implemented by someone who does not have the time or knowledge to follow best practices for continuous development, the plugins could contain deprecated libraries. Deprecated code could or not could include exploits. The plugins could also be not well written in a matter of runtime, performance and efficiency. That all may lead to findings when running a code analysis. Nonetheless, that could also lead to many false-positive findings. So the allover problem is the mass of the false-positive findings which leads to a need for reviewing. The review needs to be done by hand to understand what the programmer did. Neither the Joomla security strike team nor the active core community has the capacity to do such reviews on every plugin that has a finding. Now the question stays, whose responsibility is the safety of plugins? In short, yours. If you are the admin of a Joomla based web appearance, it’s your responsibility which plugins you install and the aftermath is yours too. A solution for safe, and well-written plugins, without an amount of simple impossibly review work, could be decentral checking. If there was a way to give safe, and well-written plugins a batch, that would mark their quality, wouldn’t admins be eager to use them? That leads us to the idea of a plugin checker. The plugin checker would be embedded as a web app, where everybody could upload their plugins, to undergo a checking for deprecated libraries, exploits etc... An online code analysis. If a plugin passed the check, it could be admitted to a list of recommended plugins. The plugins in the list would be checked regularly by a cronjob. When falling out of the recommendation, the uploader would be informed via E-Mail. So the idea is to make security achievements for the developers.
4. Build-in Checking and Validation of Files
The file upload function and its file checking and validation capability are historically grown. The first versions only checked file extensions. Known formats such as .png, .jpg, .gif, etc., were checked. Later on, mime type checking was added. But mime type checking is a two-edged sword. It definitely is useful to have an extra value to check to determine the file format, but in reality, mime type checking is a guessing game and one cannot always trust the results. This is realization came from experience. Joomla had a vulnerability that enabled XSS. This vulnerability was an inconsistent interpretation of mime types. The PHP application interpreted a file as PNG, so did the webserver. But the browser interpreted the file as JavaScript. The file was a forged JavaScript file, which looked like a PNG. In retrospective and with the knowledge of modern security best practices, we were able to evaluate each extension type that is allowed by default. The conclusion is that the default extensions are a secure selection of extension types.
It is still possible to fool the extension and mime checking mechanism by forging files, which are made of the magic number and the corresponding file extension. But we think, because of the security context of the media manager, that this is not problematic. This only leads to broken image files saved in the /images folder of the Joomla installation. We tried to use the files in some way, but browser security headers, Joomla role system, etc., stopped us to do anything meaningful. In fig. 2 the attack is illustrated. The idea was that an attacker uploads an image. By using some attack launcher the administrator loads the image located in /images. To note is that the image’s path is predetermined since the filename stays the same. The image gets decoded and the code is run. Well, it didn’t work, good for Joomla!
A big thing are SVGs. SVG is a complex XML-based markup language. It is used for describing two-dimensional vector graphics. But it is also possible to include ¡script¿ HTML tags. This leads to possible XSS injections. If the SVG is sanitized, e.g., ¡script¿ tags are removed HTML injection could still be possible. As if this were not enough, SVGs also enable us to do the Billion Laughs Attack by using XML Entity Processing. A Denial of Service to go. “SVGs are not just images, but mini-applications” [4].
5. Take-Aways
5.1 Previous Vulnerabilities: Lessons Learned
We explained the Joomla RCE vulnerability in section 2. The JSST evaluated the process of handling this particular vulnerability and pointed out three realizations as lessons learned.
Creativity
The creativity of attackers is two-sided. The first is side is the initial exploration of a potential vulnerability. It often demands a good foundation of computer science skills, such as language specifics, security knowledge and application or domain knowledge. This enables an attacker to be able to find different little things to use as an attack vector. By chaining these findings together, the attacker can create powerful exploits. The other side is the imitators. They somehow get to know the existence of this exploit and simply apply it, most often not even understanding why it works.
Cooperation
To protect users, security teams and web hosts do have to work together. Informing web hosts about security issues is one task of the JSST.
Speed
The users have about 8 to 10 hours to patch after a security patch release. Usually, a big attack wave starts after this estimation and everyone not patching in time are vulnerable.
5.2 Pull-Requests and Security
Besides the typical application of the Two-man rule, e.g., multiple people reviewing a PR, the GitHub pipeline performs a static source code analysis for vulnerabilities, via RIPS. The pipeline fails if some major security mistakes are implemented. It is yet another security layer, so things you can not get enough of.
5.3 What’s next?
Since RIPS was taken over by SonarCube, an evaluation of the latter is in progress. But it’s always challenging to adapt to new tech. The Joomla codebase is quite big, that is more or less 430000 lines of PHP code and 49500 lines of JavaScript code, false-positive findings are hard to prevent. But to take every possible vulnerability serious one has to review the results of the findings. One task of the JSST is to make such tools applicable, realistic and useful, which is an ongoing process.
Another big task is the implementation of a supply chain attack prevention concept. A supply chain attack targets the distribution network. Someone could modify some trusted component in the supply chain. These modifications could alter the resulting product. In the case of information systems, this could be a vendor library that is used as a dependency in Joomla. The Update Framework (TUF) is a framework and specification. By adopting TUF Joomla could successfully implement a prevention system for supply chain attacks, which in turn allows us to take the next step: A secure automatic update system for Joomla.
References
[1] What is a Supply Chain Attack? — Check Point Software. (visited on 08/26/2021).
[2] Unrestricted File Upload — OWASP. (visited on 08/24/2021).
[3] ImageTragick. (visited on 08/25/2021).
[4] Mario Heiderich. The Image that called me - Active Content Injection with SVG Files.
