[BreachExchange] Where’s Waldo: Third-Party Library Edition

[Destry Winant]

https://www.riskbasedsecurity.com/2020/01/21/wheres-waldo-third-party-library-edition/

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.

Pro tip: if you’re using JFrog Xray, your dev team is already
benefiting from VulnDB’s comprehensive third-party vulnerability data!

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.