USING COMPONENTS WITH

KNOWN VULNERABILITIES
There are new cyber vulnerabilities and threats emerging each day putting the users at risk but not
all of those are zero-days. Most of those threats occur due to the software dependencies like using
components such as libraries and frameworks which are previously known to be vulnerable, or
which become vulnerable later due to unpatched software fixes or updates not implemented on
time.

DESCRIPTION

Some vulnerable components (e.g., framework libraries) can be identified and

exploited with automated tools, expanding the threat agent pool beyond targeted attackers
to include chaotic actors. Virtually every application has these issues because most
development teams do not focus on ensuring their components/libraries are up to date. In
many cases, the developers do not even know all the components they are using, never
mind their versions. Component dependencies make things even worse.

It is a most common vulnerability types, with one of the reasons being that it is hard
to find. The attack surface is wide as any layer could be vulnerable. As stated above any used
component, everything between the core of the OS to libraries used by plugins, could have
known vulnerabilities making the site vulnerable.

Developers usually focus on securing their own code and often forget about the
code they have imported from others. In many cases developers are not even aware of all
the code that is running. This is mainly due to plugins which in turn import libraries which in
turn have their own dependencies etc.

EXPLOIT

When a vulnerability is published on the internet, someone often uploads a ready to

use payload which an attacker could simply download and use against the target. This means
that an attacker can use it towards the site without even knowing how and why it works.
Even when a PoC is not available, documentation about the vulnerability is easy to access, so
all the attackers would need to know is how to follow instructions.

However, there are of course also exceptions to this. Some vulnerabilities require
existing knowledge about the system, and if the component that is vulnerable is not directly
exposed to the internet, the attacker would need to figure out a solution to that as well.
MITIGATION

 Know your application and prepare a good documentation of all the components (OS, web
server, libraries, network components etc) and the current versions used by the application
and make sure it is well maintained.

 Implement regular monitoring and security assessments testing.

 Perform periodic Vulnerability assessment and Penetration testing both internal and
external to confirm the security of your application in depth.

 Deploy a proper patch management system and make sure the updates and security
patching are from trusted vendors only and remove unneeded or unused components for
hardening the application.

 Ensure that not only the components but the subcomponents are also not vulnerable and up
to date.

 Make use of OWASP’s Dependency Check to find if any of the components you use have a
publicly disclosed vulnerability.

 Deploy a Web Application Firewall for providing defence in depth.