Third-party components are omnipresent in web applications. Libraries, frameworks and other system components are used more and more, because they reduce costs and make development easier.
However, like any system, these third-party components may contain vulnerabilities that can be exploited in attacks on web applications. Furthermore, exploits that are discovered, and often made public, can have a snowball effect, compromising an entire web application, servers, database systems, etc.
In this article, we present these types of vulnerabilities through the prism of the OWASP Top 10, using attack scenarios. We also detail the best practices and measures to implement to protect against them.
A quick reminder about OWASP and the OWASP Top 10
OWASP is a non-profit foundation whose mission is to improve software security. It is made up of an active community that participates in the creation of various resources such as security guides and standards for a wide range of different technologies and contexts.
OWASP also proposes various projects such as ZAP, an open source interception proxy (an alternative to Burp), and the OWASP Top 10.
OWASP Top 10 and vulnerable components category
The OWASP Top 10 is a ranking of the 10 most common types of vulnerabilities in web applications. This ranking has been updated regularly since its first publication in 2013 until its latest version in 2021.
Below is a comparison between the 2017 and 2021 versions and the different categories of vulnerabilities identified:
Furthermore, even if the OWASP Top 10 does not provide an exhaustive list of all web vulnerabilities, it does give developers and cybersecurity professionals a good basis for testing and securing a web application.
And, as we can see from the graph above, the “vulnerable and outdated components” category has moved up 3 places (from 9th to 6th position). This trend can be explained by:
- The ubiquity of third-party components in today’s web applications. There are a multitude of components for an infinite number of use cases and a huge number of different languages. It is therefore possible to launch large-scale attacks with a high probability of success.
- The ease with which attackers can exploit this type of vulnerability. Indeed, as mentioned in the preamble, when exploits are discovered on a specific component, they are often made public with all the information on the flaws and possible exploits, which makes the task much easier for attackers (even novices).
What are the main risks associated with third-party components?
Developers are generally unaware of the availability of updates. As a result, some vulnerable components can remain on a production server for weeks, even months or years.
In addition, the turnover in technical teams and the lack of documentation do not help the fate of these third-party components, which tend to become obsolete. As a result, web applications that use these third-party components inherit more or less dangerous security flaws.
The exact nature of these vulnerabilities and the actual impact depends on the component affected, the way it is integrated into the application and the business context.
OWASP provides us with a few guidelines to indicate whether you are potentially vulnerable:
- You don’t know the versions of all the components you use, either on the server side or on the client side. Also, if you don’t know the versions of the components used by other components.
- The components are out of date or deprecated.
- You do not regularly scan for vulnerabilities.
- Components are only updated periodically and not according to current risks. As a result, a company may remain vulnerable for several weeks or months while waiting for the set date to update its components.
- Your developers do not test the compatibility of updated or corrected components.
The consequences of using a vulnerable component can be very serious, ranging from a simple XSS attack to full remote access to the server by exploiting a RCE. Let’s take a closer look.
Exploitation of vulnerable and outdated components in web applications
Swagger UI
Swagger UI is a library that is widely used to display interactive API documentation.
This library offers a rather interesting feature which allows the user to specify a url pointing to a yaml or json file and which will return to the user the specifics of the API, indicated in the file.
To do this, users simply need to add the url or configUrl parameter to the end of their Swagger url:
- https://my-swagger.com?url=https://evil/spec.yaml
- https://my-swagger.com?configUrl=https://evil/spec.yaml
Unfortunately, this functionality is vulnerable to reflected XSS injections on versions 3.14.1 to 3.38.0 of Swagger UI. The cause: Swagger UI itself uses a library called DOMPurify to clean up user inputs.
This library was created to help developers protect themselves against certain attacks such as XSS. However, versions of Swagger UI between 3.14.1 and 3.38.0 use versions of DOMPurify for which bypasses have been found.
Exploitation of a reflected XSS vulnerability
For our example, we have a vulnerable version of Swagger UI which is 3.14.2. On our server, we host a malicious yaml file renamed “xss.yaml”, the contents of which are shown below:
The red rectangle shows the malicious JavaScript payload that will be executed. The scenario is as follows: after hosting the malicious file on his server, the attacker sends the victim’s Swagger url to the victim, adding the url pointing to his server as a parameter.
This will execute the XSS payload and trap the victim. In the image below, in the first red rectangle, you can see the victim’s Swagger url, http://127.0.0.1, followed by the “url” parameter, which is none other than the url pointing to the attacker’s malicious yaml file.
The second red rectangle clearly shows that the payload has been executed. In this example, the payload simply displays an alert with the number 1, but in a real case we could do a lot more damage, such as stealing the victim’s authentication token.
Fixing the vulnerability
To fix this vulnerability, simply update Swagger UI to the latest version. However, if this is not possible, the DOMPurify library used by Swagger UI must also be updated to the latest version.
Apache Struts 2
Apache Struts 2 is an open source framework for developing Java EE web applications. Versions between 2.3.32 and 2.5.10.1 are vulnerable to RCE attacks, i.e. remote code execution on the server.
The vulnerability is believed to be caused by the Jakarta Multipart parser used by Apache Struts 2, which is a widely used framework and the vulnerability affecting it is extremely easy to reproduce, making this vulnerability very critical.
Exploiting a RCE (Remote Code Execution)
For this scenario, we deployed a vulnerable version of Apache Struts 2 (2.3.12) on an Apache Tomcat 7 server, as shown below:
Using a python script that is very easy to find on the Internet, we can execute commands on the server that hosts the application by specifying the url of the web application and the command we want to execute.
This will send an HTTP request to the application. The command is contained in an OGNL (Object Graph Notation Language) expression, which is itself injected into the Content-Type header of the request sent.
When the request is received by the server, the Content-Type header with the payload is analysed by Jakarta’s Multipart parser, which will trigger an error.
The function used to construct the error will interpret the malicious OGNL payload and the system command sent by the attacker will be executed.
Below, using the script, we recover the user and the contents of the /etc/passwd file:
We simply control the server.
How to fix this vulnerability?
As in the Swagger UI case, the most effective way of correcting this vulnerability is to update the framework to the latest version. If this is too costly for the company, it is also possible to change parser with the Jason Pells Multipart parser.
It is also a good idea to install a WAF to filter and analyse requests made to the server. In this way, injections of OGNL expressions can be detected and blocked before they reach the server.
GLPI
GLPI is an open source web application – written in PHP – for managing a company’s IT resources.
As well as providing an inventory of all the company’s resources, such as software and network equipment, GLPI also offers a support and financial management solution.
In September 2022, several critical vulnerabilities were discovered in GLPI, including one linked to the use of the htmLawed third-party library, whose purpose was to standardise the application’s HTML code. In GLPI versions 9.5.4 to 10.0.2, the version of the htmLawed library used embedded a test file htmLawedTest.php allowing an unauthenticated user to execute arbitrary code on the server.
Exploiting the RCE
To illustrate the vulnerability (CVE-2022-35914), we have deployed a vulnerable version of GLPI.
The htmLawedTest.php file mentioned above is accessible without authentication and allows an attacker to execute arbitrary code by manipulating the hook parameter directly in the interface, making the vulnerability easily exploitable:
The command specified as input by the attacker is executed on the vulnerable server as simply as this:
Among other things, this RCE vulnerability allows the attacker to read potentially sensitive files on the server, such as configuration files containing passwords. For example, the attacker can easily recover the access password to the database used by GLPI. As encountered during penetration tests, this password is often the same as the root password used to access the server via SSH.
How to counter this attack?
GLPI has corrected this vulnerability in version 10.0.3, so the best course of action is to update GLPI to this version or a higher one. If the update is not possible immediately, it is recommended to delete the htmLawedTest.php file or at least to restrict access to it.
In addition, and more generally, certain applications – such as GLPI – intended for internal use should not be exposed publicly, as this could unnecessarily increase the company’s attack surface.
Similarly, if an application is exposed directly to the Internet, it is necessary to restrict access to certain non-public parts of the application. For example, access rights to the /vendor/ folder in GLPI can be restricted to prevent it from being publicly accessible (assuming that GLPI needs to be exposed on the Internet).
How to prevent this type of vulnerability?
Generally speaking, to avoid being exposed to vulnerabilities caused by vulnerable and outdated components, it is essential to develop patch management processes.
These processes consist of :
- Removing unused components;
- Regularly taking stock of the versions of all your components, and their dependencies, i.e. the components they use;
- Keeping abreast of the latest major vulnerabilities and updating the components concerned;
- Only use components from reliable, official sources;
- Monitor components that are no longer maintained or that do not have patches for older versions;
- In this way, thanks to patch management, the security of an application will be guaranteed throughout its lifespan.
Authors: Lorenzo CARTE & Benjamin BOUILHAC – Pentesters @Vaadata