Where’s Waldo: Third-Party Library Edition
January 21, 2020 • RBS
During software development, your team should be able to confidently pick the right third-party libraries while developing.
Everything is becoming connected. As your car, dishwasher, and refrigerator become part of the “Internet of Things”, it becomes increasingly difficult to maintain the security of a product, and calculate its true cost of ownership.
The days of vendors shipping solely their own code are long gone and as products are developed, the reliance on Open Sourced Software (OSS) and third-party libraries is the norm. As software engineers and developers are well aware, one product can contain over a hundred bundled third-party libraries. Despite the convenience, developers and decision makers need to be aware that they are very likely to inherit security issues by incorporating third-party components.
Inheriting Security lssues
Organizations may assume that third-party components have been analyzed for vulnerabilities and are safe to use in commercial products, but unfortunately this often isn’t the case. Even if a library has been heavily audited and deemed low-risk or safe, there are generally three common opportunities for malicious actors to use third-component code against unsuspecting developers:
- The third-party library natively contains a vulnerability, or via a third-party dependency it uses.
- Inserting malicious code into a legitimate library: Anyone who downloads and integrates that library with trojaned code then becomes vulnerable, typically in the form of remote access.
- Creating their own version of a library and inserts their malicious code: likely forked from the original, the bad actor renames it to appear very similar to the legitimate one.
As ZDNet recently reported, two Python libraries were removed because they were discovered to contain malicious code. In this article we are going to highlight the last method mentioned and examine the details.
Jellyfish’ vs. ‘JeIlyfish’
We’ve probably all at some point stumbled onto a domain set up by malicious actors to look like the one you were looking for, whether we know it or not. We occasionally see something similar occurring here too related to third-party software. One of the removed third-party libraries mimicked the popular ‘‘jellyfish’ library (this is the legitimate one) in the following way:
The fake library replaces one “L” with a capitalized “i”. In crunchtime situations, a developer might not catch this and use the fraudulent library, compromising security and putting their customers at risk. In this specific situation, by using this OSS library, malicious attackers would be able to steal SSH and GPG keys from infected products.
Python3-dateutil vs. python-dateutil 2.8.1
The second library that was removed exemplifies another issue involving third-party libraries – they aren’t always actively monitored. Even organizations that implement a strict Software Development Lifecycle (SDL) might not apply the same standards to third-party components.
Software development is generally focused on quickly delivering a working product, not taking the time to practice secure coding or even tracking the security issues associated with each third-party library used. So a developer who is under pressure to complete a product might just trust the community to presumably provide safe and reliable code.
What can go wrong? Well, the user that uploaded these two libraries preyed on that exact line of thought. Although the python3-dateutil library did not contain its own unique malicious code, it did contain the fake ‘jeIlyfish’ library, which would still result in the ability to steal SSH and GPG keys. The important take-away here is that the malicious jellyfish library had already found its way into another, more popular library.
A Few Good Devs
Thankfully, the fake python3-dateutil library had only been available for two days before it was discovered and removed. However, the fake ‘jeIlyfish” library had been publicly available for nearly a year. It wasn’t until German software developer Lukas Martini reported this issue to the legitimate dateutil developers and the PyPI security team that these fake libraries were removed.
Because of Lukas Martini, the DevOps landscape is a bit safer place. But organizations need to face up to the reality – it’s not enough to rely on a few good developers to monitor the security of third-party libraries.
This leads us to a common security dilemma that organizations face; resources are scarce. Organizations need their dev teams to do their job, and innovate, not to play “Where’s Vulnerability Waldo” whenever they are designing a product.
The Number One Solution for Third-party Libraries
As your security team knows only too well, monitoring vulnerabilities in third-party libraries is a painful process. There are a multitude of libraries to monitor, and a vast array of sources to track. Monitoring bug tickets, pull requests, changelogs, release notes, and commits for one project can be daunting; imagine doing it for a hundred libraries used in your product? For the many organizations that monitor third-party libraries in-house, this is an overwhelming and extremely time consuming prospect.
As many of our clients know, VulnDB provides a dependable solution. Not only does VulnDB have over 220,000 public vulnerabilities (including over 72,000 not found in CVE/NVD), it also monitors and tracks vulnerabilities for over 2,000 third-party sources.
By using VulnDB, you can free up resources and allow your teams to focus on the products and features, while maintaining better security. Our team proactively seeks vulnerability disclosures and provides comprehensive, actionable data in a standardized format.
Curious to know whether the libraries that you are using are already being monitored in VulnDB? Hit the button below, and we would be glad to show you a sneak peek of the vulnerabilities contained within, and which sources are actively monitored. We also frequently work with our clients to expand those sources according to their needs.