Third-party code is reusable software that has been developed by an external entity to be either freely distributed under an open-source license or sold to software vendors to be used in their platforms.
Although using third-party software brings many benefits, such as new functionality for a platform at reduced development costs and reduced user acceptance testing effort, every new piece of code adds an additional attack surface to an application that malicious actors can potentially exploit. Not only can it introduce vulnerabilities due to poor code, but its implementation and integration into existing applications may also add further issues. Third-party code should be implemented carefully and treated as if it was part of the application’s core code, as it is no different when it comes to a potential attack.
Many third-party packages, plugins, and add-ons, both proprietary and open-source, have been affected by vulnerabilities in the past, impacting the data of thousands of organisations worldwide.
The fact that a third party developed a piece of software does not make it any more reliable or secure. Whether an attack is performed against an external component or the core application code, at the end of the day, what will be impacted is the application and its data, along with the organisation’s customers, brand and reputation. Therefore, third-party code should be treated with as much caution as in-house written code.
So, what are the common types of third-party code? built-in functionality and plugins.
1. Built-in Functionality
Implemented as part of the core application, normally, users cannot opt-out of the functionality. If affected by a vulnerability, it can only be fixed by waiting for a patch from the third-party provider or by adding additional security controls on top of the core application code.
They are part of almost every piece of software in existence, as a large percentage of the code written in most applications nowadays is open-source code. This could be in the form of open-source libraries, CSS stylesheets, or HTML editors embedded within a web page.
What makes them popular? They are often open-source and free of charge, making them an appealing solution to vendors.
The fact they are coming from a third-party provider gives the vendor a false sense of security, assuming security best practices and testing are already being employed by the provider. They often add functionality that would otherwise require a large amount of effort in both development and testing to create from scratch. Solutions written by reputable third-party providers can sometimes be more reliable and will require less ongoing maintenance.
What makes them so dangerous? Third-party software and libraries often are not updated regularly, meaning if a vulnerability is discovered, it may take a while to be properly patched. The addition of third-party code is often poorly tracked, to the point where vendors are not even aware it is being used. When the vendor tracks it, it may not necessarily be disclosed to the public.
Since these are often installed directly onto the web server and become part of its core code, it makes them even more dangerous. Vendors must often rely on the third-party provider writing secure code, but ultimately there is no guarantee this is the case.
2. Plugins/Add-ons
Plugins are usually application-specific and not part of the core application. They can normally be added/removed by end-users as required. They are usually specifically built as an add-on or additional functionality for existing software instead of generic software.
Customers can easily fix issues by temporarily disabling or removing the vulnerable component until a patch has been released to address the issue. Plugins can be available for Browsers, Web Applications, and Windows/Linux/Mac OS applications.
What makes them popular? They are often free or inexpensive as they are developed by either the vendor or independent developers, making these very appealing. They can easily be installed/uninstalled and updated through the vendor’s platform. Often coming from the vendor’s store, it makes them look reputable to the eyes of customers. They are often built for a specific purpose or address a specific customer issue or need that the vendor can’t/won’t address themselves. They are quite flexible and can often be developed for Browsers, Web Applications and Windows/Linux/Mac OS applications.
What makes them so dangerous? Plugins are often written by independent and/or inexperienced developers, making the code more likely to contain vulnerabilities. For the same reason, the projects are often abandoned and no longer receive updates, leaving vulnerable software with no available updates.
Platforms sometimes employ poor practices to review and vet plugins and add-ons created by the community due to the high number of submissions or negligence. It is often trivial for attackers to identify what plugins a certain application is using, and since vulnerabilities are publicly disclosed, this can make exploitation rather trivial.
What are the consequences of a third-party code vulnerability?
Information Disclosure
Disclosure of sensitive and/or customer information, such as personally identifiable information (PII), individually identifiable health information (IIHI), educational information, financial information (credit card numbers, banking information etc.). The severity of this issue depends on the type of information the application is storing and how sensitive it is.
Denial of Service
Denial of service can render the vulnerable application inaccessible to end users, therefore creating major business disruptions, including brand and reputational damage, financial loss and more. This could be a temporary attack, or it could last several days if critical infrastructure is affected.
Code Execution
Remote code execution allows malicious actors to execute arbitrary code on the vulnerable system, potentially compromising users, applications, databases, and even internal infrastructure. This is probably the most concerning of all as it can give the attackers the ability to carry a wide array of attacks while remaining undetected.
How can you identify potential vulnerabilities?
- Executing code or commands, for example, through a scheduled task or an administrative console, could be exploited to run malicious code.
- Accessing local files stored on the server could be used to disclose information or even achieve file access.
- Communicating with the database to gather or modify information, as it could be abused to access unintended data.
- Uploading files onto the server’s physical disk could allow for malicious files to be uploaded to obtain gain remote code execution or perform social engineering attacks.
- Forms or fields that are not properly sanitised, used for injection-type attacks.
- Importing/exporting data in and out of the system may expose the application to injection attacks or access unintended information.
- HTML editors that allow users to write content using HTML code, as they could potentially expose the application to cross-site scripting vulnerabilities and social engineering attacks.
Potential vulnerabilities are not limited to the functionality listed above. No matter how harmless the code or functionality used might seem at first sight, especially with large libraries, it can always carry critical issues.
What to be done to best prevent issues in third-party code?
- Establish a baseline and process for every third-party software that is introduced into the organisation, including performing a risk assessment to establish the risk associated with implementing a certain piece of code.
- Make sure the code you are implementing comes from a reputable provider.
- Know what the third-party code you are implementing does, if it is accessing sensitive data or performing critical functions, so you may consider using an alternative solution if needed.
- Perform periodic testing against all third-party code being used, regardless of whether the provider claims it is already being conducted on their end.
- Consult various vulnerability databases such as CVE, NVD and VulDB and check whether the component you are about to implement is currently affected by vulnerabilities or has been affected by vulnerabilities in the past (as this may be an indication of future compromises).
- Ensure you are already using best practices within your organisation such as strong encryption (both at rest and in transit), multi-factor authentication, firewalls/IDP/IPS, and enhanced logging, as this can help greatly in reducing the impact that vulnerabilities in third-party code can have on your organisation.
Below are two recent case studies that highlight how common vulnerabilities are in third-party code.
Case Study: TinyMCE
TinyMCE is an open-source rich-text editor that is used in web applications. It can assist users in creating HTML content through an easy to use interface without the need to know how to code. It does not just provide HTML capability. It also comes with several additional functionalities, such as a file manager/uploader, an image gallery, and a spell-checking tool that make the end-user experience easier.
It is being used by over 600.000 sites, according to Wappalyzer, has been implemented by a large number of CMS vendors, and it comes by default with a large number of open-source web applications. It is rarely updated once installed as part of a web application. If you used content management systems in the past, you have probably used TinyMCE without realising it.
What was the vulnerability?
TinyMCE version 5.2.1 and earlier was affected by a self-reflected (and in some cases stored) cross-site scripting vulnerability. This is a type of vulnerability that allows attackers to inject arbitrary client-side (JavaScript) code into a field, which when loaded by a user, would trigger the malicious payload. An attack like this can have various consequences, the most common being session cookies theft, resulting in an attacker taking over a user’s session.
When TinyMCE is implemented in its classic editing mode, the stripping and sanitisation logic of TinyMCE (implemented through its “HtmlSerializer” API), which had implemented protections against cross-site scripting attacks, could be bypassed using nested and non-terminated HTML tags.
This issue was later fixed, although many sites still have not updated their TinyMCE version and therefore are still vulnerable, as when a new release of the component is out, developers need to manually update it on the webserver to install the patch.
What was the exploitation?
As an example, when opening a “<textarea>” tag, the serialiser would not start stripping cross-site scripting payloads until a closing “</textarea>” tag was found, therefore allowing attackers to inject a <img> tag with arbitrary code included in an “onerror” event, in order to exploit it.
The following is an example payload, which when inserted would trigger a harmless alert box on the web browser:
<iframe><textarea></iframe><img src="“ onerror="alert(‘TML Stored XSS’)">
Through this exploitation, it would normally only be possible to obtain self-reflected cross-site scripting (which would require the victim user to manually enter the payload in the HTML editor), although depending on the application where TinyMCE is being used, it could be possible to turn this into a stored injection by saving the payload (for example in a blog post) and having users visit it (assuming the site did not employ other XSS protection mechanisms).
What was the resolution?
The easiest way to fix this issue is to simply update the TinyMCE to the latest version, as this issue has been fixed in versions 5.2.2 and 4.9.10 onward. According to the provider, updates to the component should not incur any issues with the editor if already implemented.
Additional cross-site scripting mitigation mechanisms can be implemented to prevent this and other similar attacks, such as filtering/whitelisting of characters or encoding user-provided input.
Web Application firewalls can also help mitigate cross-site scripting and other injection-related vulnerabilities that may be affecting an application or its third-party code.
Case study: WP Super Cache
WP Super Cache is one of the most popular caching plugins for WordPress, which helps improve the loading performance of the site. It generates static HTML files from a dynamic WordPress site which are then served by the web server, instead of processing the heavier and more resource-expensive WordPress PHP scripts.
It has been installed on over 2 million WordPress implementations since its release, therefore exposing a large number of sites and organisations.
In the WordPress plugin store, WP Super Cache has an average user rating of 4.5 stars, implying it is trustworthy. Being an add-on of WordPress, it can be easily disabled by site Administrators when required. On newer versions of WordPress, plugins are automatically updated, and therefore most sites would not be exposed to the vulnerability for a very long time.
What was the vulnerability?
WP Super Cache version 1.7.1 (released on 31st Jan 2020) was affected by a remote code execution vulnerability, which is a type of vulnerability that allows attackers to execute arbitrary code or commands on the remote, vulnerable server.
This can result in the application and its database being compromised, as well as the entire server and any other sites hosted on it. Additionally, it could allow an attacker to run commands in order to communicate with internal resources that would otherwise not be accessible externally.
Potential attackers need to be authenticated to the application in order to exploit this vulnerability, although credentials could be obtained through other attacks such as user enumeration and XMLRPC brute-forcing.
Version 1.7.2 was released on 16th Match 2021, addressing the vulnerability through a patch, meaning that sites using the vulnerable version were potentially affected by the exploit for over a year.
- The advanced section of the settings page used for the WP Super Cache plugin contained a “Cache Location” field (cache_path variable) that was used to specify the location of the cache configuration file.
- The cache configuration file (wp-cache-config.php ) is used by the plugin to determine how to perform caching within WordPress, for example, which files should be cached and where to cache them.
- This field failed to properly validate user input, as when adding “’;” to the beginning of the field, it allowed attackers to inject arbitrary PHP code into the wp-cache-config.php file.
- As shown in the vulnerable code, the plugin was only validating whether the path provided for the configuration file was not empty - it was not performing enough sanitisation to ensure it was a valid path.
What was the exploitation?
- Because the vulnerability allows code to be written to the wp-cache-config.php file, this can be used to obtain remote code execution on the target host in various ways, such as using a PHP reverse shell or any of the PHP functions that allow system commands to run and output their result.
- The following payload can be injected into the file to easily gain remote command execution:
- ;system($_GET[13]);include_once \'wp-cache-config.php\’;’
- Through this simple line of code that uses the “system” PHP function, whenever the wp-cache-config.php file is accessed through a GET request, and a “13” parameter is sent, its value will be executed as a system command.
- The screenshot below shows how the payload is injected into the cache file:
This can be automated through a Python script that will do the following:
- Authenticate to the WordPress site
- Ensure the vulnerable version of the plugin is installed
- Retrieve the _wpnonce parameter, which is necessary to issue requests
- Create the wp-cache-config.php file
- Execute given commands by providing them as values for the GET request parameter
A proof-of-concept script I wrote that can be used to exploit this can be found at the following GitHub repository can be found here.
This particular script should work in most WordPress implementations unless the “system” PHP function has specifically been disabled in the php.ini file. In that case, similar functions such as exec, pass-thru, and shell_exec can be tried, or a PHP reverse shell can be injected.
The automated script can be seen in action on the right-hand side.
What was the resolution?
The developers of the plugin issued a patch to fix this vulnerability by adding additional input sanitisation in order to ensure the value provided for the cache file location corresponds to a valid path; it is a valid string. Luckily, newer versions of WordPress automatically update plugins when a new version is available, meaning developers do not have to manually update them when a vulnerability is fixed.
Here is the code that was applied by developers to fix the vulnerability:
Organisations can benefit greatly from using third-party code and libraries, although these should always be implemented with security in mind through both the company's internal security policies (such as vendor questionnaires, risk assessments and code review) as well as industry standards and best practices. Discover our Offensive Security Services to learn about our multi-layered defence approach through various security tools and frameworks.
If you liked this article, you may also like:
Privileged access in the new world
