Skip main navigation

New offer! Get 30% off your first 2 months of Unlimited Monthly. Start your subscription for just £35.99 £24.99. New subscribers only T&Cs apply

Find out more

Threat Analysis

In this video, watch Paulo Silva explain the risks associated with including a component with known vulnerabilities in an application.
Welcome to Using Components with Known Vulnerabilities session. In this first part, we will focus on threat analysis. Since this topic is pretty much straightforward, we will briefly discuss it. We’ll also discuss how the system can be harmed, the impact of successful exploitation, and give you some insights to identify who may want to harm your system. Have you ever heard about dependency hell? If no, please check Wikipedia. Dependency hell can take several forms, and the most common in today’s software, and specifically web applications, is the number of dependencies of a single application. Recent statistics say that 80% of the code in today’s applications come from libraries and frameworks.
Application owners do not always understand the security risk dependencies represent to the overall security of their applications. The risk of vulnerabilities in this component is widely ignored and underappreciated. Dependency management has been for a long time a big challenge. This table gives you an overview of the top five most dependent upon npm package– the same technology used by our intentionally vulnerable application. Notice the number of dependent packages. Can you imagine how many applications will be affected by a single vulnerability in one of these packages? The request package, highlighted in red, was deprecated by its author and it is still being heavily downloaded– check the weekly downloads. I think you now understand how big this problem is. Let’s move on.
When you realise that your application is made of several building blocks, and some of them are third party software, you’ll have a good idea of the potential attack vectors. Nowadays, web applications rely on several free and open source components, developed and maintained by several individuals distributed on external registries but without any warranty. Some of these components are not well-maintained and others were even abandoned by their authors. Attackers may try to add back doors to popular components, contributing with some source code, which is not properly reviewed, and ends up delivered as part of the component. They can also publish their own malicious libraries or packages in the official registry, disguised as some useful functionality.
Attackers can also go after registry’s accounts, gaining control over popular components owner’s account. When this happens– and it already happened in the past– attackers can modify the component being delivered. It’s not easy to define the impact of using components with known vulnerabilities. Components– such as libraries, frameworks, and other software modules– run with the same privileges as the application– what may undermine application defences and enable various attacks and impacts. Its reduced vulnerabilities can be of any type. It can lead not only to severe data losses, allowing attackers to bypass authentication mechanisms, exclude privileges, or accessing arbitrary files, but also to full system takeover via remote code execution or providing access to remote administrative interfaces.
It is fairly easy to find already written exploits for known vulnerabilities. There are automated tools to test on vulnerabilities with available exploits in a target application. This makes the task simple, even for not-so-technical people. Most applications rely on third party code, either libraries, modules, or packages. Anyone contributing to such dependencies may introduce back doors. You’ll find this table in the last top 10. Pause the video and take your time to carefully read it. In the next part, we will exploit a component of our intentionally vulnerable application which has a known vulnerability.

In this video, you will learn about the risks associated with including a component with known vulnerabilities in an application.

You have already seen that there are common components used across many systems. Once a hacker finds a vulnerability in a component, all systems using this component have a greater vulnerability. In this video, you will learn about the prevalence of these attacks and the risk this poses to your system.

Reflect and share: It can be surprising to learn that there are components with known vulnerabilities that are still being used by many systems. What do you think can be done about this? For example, do you think users should be educated about the problem (like you’ve chosen to be!), or should there be greater controls in place?

This article is from the free online

Advanced Cyber Security Training: OWASP Top 10 and Web Application Fundamentals

Created by
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now