Vulnerable Third Party Package
Play Labs on this vulnerability with SecureFlag!
Description
A vulnerable third-party package is a system or application dependency that is no longer maintained and can present a security risk if exploited. While these packages may not pose a threat on their own, they are often susceptible to known security vulnerabilities.
Additionally, unmaintained third-party packages are wide open to potential supply chain attacks as their dependencies are not updated, providing opportunities for backdoor attacks to compromise the system.
The problem is so important that it is included in the OWASP Top 10 security risks. The A06:2021 sheds light on this issue, specifically focusing on the problem of vulnerable and outdated components.
Impact
An unmaintained software component will soon become insecure and a repository of vulnerabilities that attackers can exploit to compromise the system.
The impact of a vulnerability depends on the package and the specific exposure, and as a developer, you have little control over this. It’s important to note that a single outdated and vulnerable package in the software supply chain can pave the way for a backdoor attack on the system.
Scenarios
Heartbleed (CVE-2014-0160)
One of the best examples from modern history is the Heartbleed vulnerability. This vulnerability existed in the OpenSSL library for many years but was only discovered in 2014. It was also present in many different systems and applications, including the Linux kernel, Apache, Nginx, OpenSSH, and many more.
It took seven days from disclosure to patching, yet in 2017, three years after the vulnerability was discovered, over 180,000 servers were still vulnerable. Many systems and applications were not updated to the latest version of OpenSSL and, therefore, were still susceptible to exploitation.
Log4j (CVE-2021-44228)
Another more recent example is the Log4j vulnerability. This vulnerability was present in the Log4j library for many years but was only discovered in 2021. This package was used in many Java applications, including Minecraft, Jenkins, and others.
With a CVSS score of 10, which translates to critical severity, it allowed an attacker to execute arbitrary code on the system.
It is estimated that over 90,000 applications and 68,000 servers are still vulnerable to this vulnerability in 2022.
xz-utils (CVE-2024-3094)
In early 2024, a sophisticated supply chain attack was found in the xz-utils package that is commonly used in Linux distributions for data compression. The vulnerability was found in heavily obfuscated code that was introduced by a malicious project contributor.
The attack took advantage of dependencies throughout the Linux ecosystem, such as systemd and libsystemd to reach other services which relied upon them, such as OpenSSH. The vulnerability allowed attackers to execute arbitrary commands on systems using the compromised xz-utils version, risking sensitive data exposure and further exploits. Despite swift action to remove the malicious code, the extensive use of xz-utils and delays in updates meant that many systems, including those running OpenSSH, remained vulnerable until the issue was fully addressed.
Prevention
It’s vital to keep all packages updated. Updating to the latest version is always the preferred solution, but in some cases, packages may no longer be supported by their maintainers. In these instances, switching to a supported alternative is the best course of action.
Some package managers have built-in commands to check for outdated packages, such as apt-get upgrade --dry-run for Debian-based systems and mvn versions:display-dependency-updates for Maven-based Java applications.
Package managers also offer the option to pin exact or tightly constrained versions. Version pinning allows specifying exact versions of dependencies to enhance security by using tested, trusted packages. Pinning should always be complemented with a robust process to check dependencies and flag any vulnerabilities in these versions.
It is always recommended to use security dependency checker software or dependency scanning aspects of Software Composition Analysis (SCA) tools to check if dependencies are up to date and identify potential security vulnerabilities. These tools will compare the versions to a database of known vulnerabilities and alert you if you are using a vulnerable version, improving the overall security of your application or system and helping you meet compliance requirements. Dependency checkers are often integrated into Static Application Security Testing (SAST) software.
Also, encourage your developers and security analysts to keep up with any news about the packages ecosystem you use to be aware of any recently discovered vulnerabilities. They can do this by subscribing to mailing lists, reviewing release notes, and following the maintainers on social media.
Testing
Verify that all components are up to date, preferably using a dependency checker during build or compile time.
OWASP ASVS: 14.2.1
References
OWASP - A06:2021 - Vulnerable and Outdated Components Wikipedia - Heartbleed Wikipedia - Log4j