Security risk on third-party packages
Software Development is a social art, it’s so cliche that it has to be true. This argument is strongly represented in communities such as StackOverflow, where developers help each other, sometimes sharing code and providing best practices and recommendations.
Another example of this comes out of the Open Source community where collaborative interests beat individual interests and where engineers share their ideas with the mission to challenge the Status Quo, help others to overcome similar problems, and create an environment of sharing continuous learning.
Renewed author, consultant, and teacher Clay Shirky has explained this feeling in a historic and highly recommended video from 2007 called “Clay Shirky on Love, Internet Style” Which I strongly recommend you to watch:
When it comes to collaboration, most of the programming languages nowadays provides a development model that I have called “Repository-Driven Development” meaning that the underlying technology provides a package management system in which the community can share code that addresses a given problem, then developers can pull it and add those libraries to their source code, making them more productive and avoiding them to reinventing the wheel.
With hundreds of libraries being published every month into these repositories, a valid question starts to show up: How secure is to use them?. Considering that Security involves three fundamental concepts: Confidentiality, Integrity, and Availability, development and engineering teams need to be diligent at the time of selecting these libraries to guarantee these principles.
What we have seen from a security standpoint is that threat actors are actively using these repositories to push highly obfuscated code wrapped into a library that promises to solve developer needs. They have been using the so-called typosquatting techniques, which consist of publishing modules that are very similar in name to an existing and popular library. We as humans can be misled to chose the wrong library when performing a search by name or by functionality.
When developers install those modules in their environments, malicious activities start including exfiltration and leakage of sensitive information such as ssh keys, secrets, passwords, and any other source of interest that could store sensitive information.
A few days ago, Sonatype security researches disclosed some NPM packages that contained malware, this is a great technical write up called “There’s a RAT in my code: new npm malware with Bladabindi trojan spotted”. By using typosquatting techniques, threat actors mimic legitimate NPM packages but including highly obfuscated code (base64 encoded payloads that are hard to decode because includes binary, compressed, or compressed strings), in this particular case, the packages ultimately launch the njRAT dropper written in. NET.
MITRE ATT&CK folks provide traceability for njRAT, which is identified by the ID S0385, and according to them, this Remote Access Trojan has been used by threat actors from the Middle-East.
Typosquatting techniques are not new in this ecosystem, ultimately humans make mistakes, and selecting the wrong package could be a common mistake. Back in 2017, I wrote an article covering this same modus operandi. In that particular case, the actors were not distributing malware but they were exfiltrating secrets to the attacker’s controlled domain.
What was interesting in that case, is that the attackers used a very similar source code that can be found in a book (check out the blog for having a better understanding and context).
The OWASP Top 10–2017 Most Critical Web Application Security Risks includes the A9:2017-Using Components with Known Vulnerabilities which provides insights on the security risks related to using third-party languages.
I strongly recommend you take a look at these security risks so you can have a better understanding of the impact on an organization. As cybercrime continues to evolve and ransomware attacks continue on the rise, we can see a lot of diversification in the way they perform initial access within an organization, and clearly, this modus operandi becomes somehow a low-hanging fruit for cybercriminals, by poisoning the registry of well-known package managers and if these operations are not discovered timely, the impact will be huge for organizations.
As we can see, the defender's industry is applying very interesting techniques to scan the registry and identity these suspicious patterns as soon as possible. Time is a crucial variable when it comes to detecting this activity in the open-source packages, however, threat actors are also improving their evasion techniques so even though we have diligent communities focused on detecting packages poisoned with malware, still organizations need to do a proper risk assessment on third-party libraries.
What you can do as a defender?
First off, defenders need to understand the security risk all this involves; that is that they can understand how these actors are using these techniques to deceive developers, with this mindset, every time a library needs to be added to the source code a better decision can be made.
The Center for Information Security (CIS) in his CIS 20 Security Controls 7.1 recommends having controls for actively managing software(inventory, track, and correct). Check out the CIS Controls 2 Inventory and Control of Software Assets.
Additionally, when relying on third-party packages you can follow these recommendations:
- Always use libraries from official sources, make sure the library is properly documented.
- Check out the package’s lifecycle: How often is it updated, how many contributors are actively working on it, what is the bug/fix ratio, what security issues have been raised.
- Check if there are security vulnerabilities associated with CVEs
- Remove unused dependencies, unnecessary features, components, files, and documentation.
- Perform source code review to identify these patterns.
- Make sure packages are updated.
