Threat Analysis

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.