Welcome to using components with known vulnerabilities session.
In this first part, we will focus on threat analysis. Since
this topic is pretty much straight forward. We will briefly discuss.
It will 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 dependents.
Is of a single application. Recent statistics
say that 80% of the golden, today's applications
come from libraries and Frameworks.
Application Warner is not always understand the security risk
dependencies represent to the overall security of their
applications. The risk of vulnerabilities in these components
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,
and Bam 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
outer 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 realize 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,
develop and maintain 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
one malicious libraries or packages in the official registry
disguises. Some useful functionality. Attackers
can also go after Registries accounts, gaining
control over popular components wonders 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 defenses
and enable various attacks and impacts. It
reduce. Vulnerabilities can be of any type. They can lead.
Not only to severe data losses allowing attackers to
bypass authentication mechanisms exclude privileges or
accessing arbitrary files, but also to fools
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 known vulnerabilities with available exploits in
a Target application. This makes the task simple,
even for non. 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.