Skip to main content

A9 Using Components with Known Vulnerabilities

Definition​

Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

Risk Factor Summary​

  • Score: 4.7
  • Attack Vectors Exploitability: 2
  • Security Weakness Prevalence: 3
  • Security Weakness Detectability: 2
  • Impact Technical: 2

Context​

While it is easy to find already-written exploits for many known vulnerabilities, other vulnerabilities require concentrated effort to develop a custom exploit.

Prevalence of this issue is very widespread. Component-heavy development patterns can lead to development teams not even understanding which components they use in their application or API, much less keeping them up to date.

Some scanners such as retire.js help in detection, but determining exploitability requires additional effort.

While some known vulnerabilities lead to only minor impacts, some of the largest breaches to date have relied on exploiting known vulnerabilities in components. Depending on the assets you are protecting, perhaps this risk should be at the top of the list.

Is the Application Vulnerable?​

You are likely vulnerable:

  • If you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies.
  • If software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries.
  • If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use.
  • If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, which leaves organizations open to many days or months of unnecessary exposure to fixed vulnerabilities.
  • If software developers do not test the compatibility of updated, upgraded, or patched libraries.
  • If you do not secure the components' configurations (see A6:2017-Security Misconfiguration).

Conceptual Attacks​

Scenario #1:​

Components typically run with the same privileges as the application itself, so flaws in any component can result in serious impact. Such flaws can be accidental (e.g. coding error) or intentional (e.g. backdoor in component). Some example exploitable component vulnerabilities discovered are:

  • CVE-2017-5638, a Struts 2 remote code execution vulnerability that enables execution of arbitrary code on the server, has been blamed for significant breaches.
  • While internet of things (IoT) are frequently difficult or impossible to patch, the importance of patching them can be great (e.g. biomedical devices). There are automated tools to help attackers find unpatched or misconfigured systems. For example, the Shodan IoT search engine can help you find devices that still suffer from the Heartbleed vulnerability that was patched in April 2014.

Example Attack Scenarios​

Prototype pollution attack:​

screenshoot from npm audit at Github Netflix/nerror Image from Github Netflix/nerror

In order to get a full picture of this attack check Explained attacks: Prototype Pollution in this guide

lockfile poison​

In order to get a full picture of this attack check Explained attacks: Prototype Pollution in this guide

How to Prevent​

There should be a patch management process in place to:

  • Check the dependencies tree. npm ls
  • Check for outdated dependencies. npm outdated
  • Remove unused dependencies, unnecessary features, components, files, and documentation. npx depcheck
  • Continuously inventory the versions of both client-side and server-side components (e.g. frameworks, libraries) and their dependencies using tools like Snyk.
  • Continuously monitor sources like CVE and NVD for vulnerabilities in the components and subscribe to email alerts for security vulnerabilities related to components you use..
  • Use software composition analysis tools to automate the process or CI process to review your dependencies.
  • Only obtain components from official sources (NPM, Github, Docker Hub...) over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component.
  • Monitor for libraries and components that are unmaintained or do not create security patches for older versions.
  • Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.
  • Define security policies about which components are allowed to be used in the organization
  • Use multi stage docker in order to use the minimum base possible like alpine once the image is built.

Hacking Playground​

References​