An internal project by Conviso’s Consulting team, called ConsultingLabs, was created with the aim of exploiting vulnerabilities.
In one of its activities, investigating CWE-79 and CWE-434 weaknesses, a case study was made exploring a pre-existing vulnerability in Plone CMS, which allows uploading malicious files in version 5.2.4. It is worth mentioning that in a more recent version this CVE was already corrected.
Objective
The objective of this article is to demonstrate the importance of Threat Modeling in practice, because through it the security requirements to be implemented are built.
Therefore, the vulnerable environment, vulnerability identification, correction and especially threat modeling will be discussed in more detail, which could map the necessary requirements to avoid the existence of this vulnerability.
Test environment
Launch Vulnerable Docker
docker pull plone:5.2.4-alpine<br>docker run -d -p 8081:8080 plone:5.2.4-alpine
Start Docker with Patch
docker pull plone<br>
docker run -d -p 8082:8080 plone
Explanation of vulnerability
Plone is a content management system that uses the Python language and aims to build information portals on intranets, extranets and the Internet. In this research, Plone was used, but there are other types of systems that provide these same resources. An attacker could map relevant components and then make attack attempts according to their mapping. Tests were specifically performed on Plone’s image upload component, which in turn already had a CVE mapped to this vulnerable version.
About XSS, the most common attack carried out with cross-site scripting involves the disclosure of information stored in user cookies. Typically, a malicious user creates a client-side script, which performs some activity (like sending all cookies on the website to a certain email address). This script will be loaded and executed by each user who visits the site. Since the website requesting the script to run has access to the cookies in question, so does the malicious script.
During the tests, an SVG image was uploaded that had Javascript commands embedded, thus characterizing an XSS attack. [1]
Attack Steps
The first action was to create an SVG file and edit it to insert the following line:
<svg xmlns="http://www.w3.org/2000/svg" onload="alert(document.cookie)"/>
After creating the SVG file, the image was added to Plone as shown in Figure 2.
After the upload, while the Plone system was loading the image, it executed the Javascript code added inside the image, in this case, displaying an alert with the user’s cookie data, as can be seen in Figure 3.
Vulnerability identification (by tools)
In this case, the vulnerability was detected manually, but there are SAST type tools that could have helped in the detection, such as the one from Conviso Platform.
In Figure 4, it is possible to notice that, when checking the version 5.2.4 image, it shows the XSS vulnerability identified by the Conviso Platform SAST Engine. Additionally, other possible vulnerabilities can be seen with the interaction of the Conviso team (OffSec Team and Consulting Team) with Pentest activities, Code Review, and through the SCA Platform engine, and the other existing integrations.
Fixing the vulnerability
After the vulnerability was detected and the fix was discovered, the handling given to this vulnerability was verified. Therefore, a change was found in the “namedfile.py” file, where a filter was added so that SVG files were not executed by the server, as shown in Figure 5.
All fixes for this hotfix can be found at this link: https://plone.org/security/hotfix/20210518.
Preventing similar vulnerabilities
Below will be illustrated the mapping of threats by performing a Threat Modeling and thereby defining the security requirements necessary for these threats to be mitigated. (Note: Conviso Platform’s “Threat Modeling” product was used for this activity).
First the “Add Image” area was defined as an application component and then the possible attacks for this item. As can be seen in Figure 6, “File Upload” was inserted in the Architecture item – just as an example, it could be “Add Image” – and then the attacks “Stored XSS”, and “Upload a Web Shell to a Web Server” were added.
After adding the attacks, the requirements needed to mitigate the selected attacks were listed, as seen in Figure 7. It is worth noting that they are suggested requirements, so it is necessary to analyze and refine if they make sense for your application. In this case, the following requirements were raised.
Below, in Figure 9, one of the suggested requirements in more detail:
Conclusion
As seen in the exploration of this case study, threat modeling is a practice that enables a secure development cycle, because when identifying possible attacks, security requirements are automatically generated or created in a more intuitive way, thus avoiding several vulnerabilities in the applications and reactive actions.
References
Autores:
Danilo Costa – Appsec Consultant
Luciene Oliveira – Analista de Segurança da Informação
Tiago Zaniquelli – AppSec Specialist