Beware of Malicious or Vulnerable Third Party Dependencies

Release Date: 4 Aug 2021 8952 Views

Rapid growth in third-party dependencies (including open-source libraries, packages and container images, etc.) has significantly changed the modern software development process. Most applications nowadays are built on a combination of in-house and external code. Public open-source repositories offer a place for developers to use, host and share software libraries, packages, container images, and other works with many useful and well-developed features. Although the use of third-party dependencies does improve the development efficiency and quality, the security risks of malicious code and vulnerability has created a backdoor for potential supply chain attacks and other malicious acts.

A report released by the Synopsys Cybersecurity Research Center in April 2021 has revealed that over 80% of codebases contained vulnerable open-source component in 2020^[1] and the trend of threat actors to spread malwares through open-source repositories. This in turn shows that with the common use of third-party dependencies, the software development and maintenance process has now become a target of threat actors.

Malicious open-source libraries and container images

Apart from exploiting code vulnerabilities, threat actors are trying to “create” one at the software development stage. One way is to populate package manager and container repositories with malicious code and images and there have been several examples of it in the past 12 months:

In June 2021, malicious cryptomining code was detected in multiple Python Package Index (PyPI) packages ^[2]
Since August 2020, several JavaScript packages in the Node package manager (npm) were found to be installing a remote access trojans (RAT) or opening a reverse shell on the developer’s machines ^[3]
In March 2021, at least 30 malicious docker images (with a collective 20 million download volume) in Docker Hub were used to spread crypto mining malware accounting for cryptojacking operations worth US$200,000 ^[4]

Though the above-mentioned threats were removed from the repositories once detected, it posed a significant security risk if developers had downloaded and used them in projects.

Typosquatting and Dependency Confusion are two of the common techniques employed by hackers to trick developers to download the malicious component:

1. Typosquatting

Malicious packages disguised themselves as official packages with a misspelled name, aiming to trick unsuspecting developers to inadvertently install those misspelled malicious packages. Examples are “Jeilyfish” in PyPI (a misspell of official package “Jellyfish”) and “electorn” in npm (a misspelling of official package “electron”). It relies on the typos or even copy & paste from the content provided by threat actors. The malicious codes will then be pulled into the project and deployed to the production systems without knowing.

2. Dependency confusion

Other than public repository, developers may host their own private repository for in-house custom code. However, threat actors can take advantage of the default behaviour of package manager to force download the malicious code published on the public repository, by assigning the malicious code with the same package’s name but a higher version number used in the private repository.

Unpatched vulnerabilities

According to OWASP, using components with known vulnerabilities is one of the top 10 web application security risks^[5]. Vulnerabilities range from cross-site scripting, code execution, denial-of-service, information disclosure, SQL injection and prototype pollution. In 2019, a popular npm utility library Lodash was found to have a serious prototype pollution vulnerability and affected millions of projects and large enterprises ^[6].

The majority of large open-source library’s developers fix security vulnerability timely. However, patching self-developed application usually requires additional times to test for stability before actual deployment on the production system. The issue becomes complicated when developers do not know the versions of all components used and are unaware of existence of the vulnerability, particularly for large systems which use many libraries or combine different container images.

Failure to keep component updated not only increases the risk but also makes future updates more difficult. As more projects have been built on the same vulnerable version of component, the testing time and difficultness of performing updates would increase over time.

Software supply chain attack and transitive dependencies

The recent SolarWinds and Kaseya incidents are examples of software supply chain attack ^[7][8]. The attackers injected malicious codes into a large number of end users’ system successfully by poisoning the software in the vendor’s environment. The vendors not only suffered from huge reputational damage, but also needed to put enormous efforts into following up with customers and recovering the business.

It is worth noting that even if the developer does not use those specific malicious or vulnerable components directly, as long as the component is bundled in some other packages that the developer is using, the concerned application may inherit the vulnerability and be affected by cascading effect. Called transitive dependency, it makes the detection and patching process more complicated without a detailed dependency tree.

Recommendations:

HKCERT reminds developers to be conscious of the risk and adopt the recommendations below:

Establish a security and vulnerability management policy to cover the selection, evaluation and update process of open-source libraries and images;
Integrate a secure software development framework (SSDF) into the software development life cycle (SDLC);
Only download third-party dependencies from official repository and verify to ensure compliance with security requirements;
Remove unused dependencies and always use a minimal image with necessary functions only;
Stay caution and beware of typo mistake when download or install any of third-party dependencies;
Review and update the inventory and dependency tree of all third-party dependencies regularly;
Use automated alert and patching tool for scanning vulnerability in third-party dependencies.