Part 2 Explanations
Video Activity
This lesson starts out with a definition of the term components. In this context, components refer to the application frameworks, libraries, or other software modules integrated into an application. Almost every application is easy to exploit. A Java Code sample is presented; this particular one relates to 3rd party DLL loads and JAR files. Finally...
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Description
This lesson starts out with a definition of the term components. In this context, components refer to the application frameworks, libraries, or other software modules integrated into an application. Almost every application is easy to exploit. A Java Code sample is presented; this particular one relates to 3rd party DLL loads and JAR files. Finally, participants learn about a case study with Adobe Flash, which allowed hackers to gain full access of a victim's machine.
Video Transcription
00:04
Hello and welcome to the side. Very secure coding course.
00:08
My name is Sonny wear, and this is Awash Top 10 for 2013
00:13
a nine using components with known vulnerabilities. So first we'll take a look at a definition for this category.
00:22
The term components in the title of this category
00:26
refers to application frameworks, libraries or other software modules integrated into an application.
00:34
Such components are usually written by 1/3 party.
00:38
This category references using thes components when they may have malicious code or security weaknesses within them. Now, if we take a look at the A WASP chart for a nine using components with known vulnerabilities,
00:55
we can see that the attack vector exploit ability is
00:59
average.
01:00
Also, we can see that the impact is moderate.
01:04
Now, if we take a look at what's said about the security weakness, AWAS states the following
01:12
Virtually every application has these issues because most development teams don't focus on ensuring their components or libraries are up to date.
01:26
In many cases, the developers don't even know all the components they are using. Never mind their versions. Component dependencies make things even worse. If we take a look at our first code sample. This is actually from Java.
01:44
This is a static block that is loading 1/3 party DLL.
01:49
Now it could be that this DLL is from a vendor and was purchased or could certainly be a dll from an open source. But in either case, it really needs to be scanned or att least
02:07
verified in some way
02:09
that it is free of vulnerabilities.
02:15
One way to atleast identify if vulnerabilities air present is to search for the name of the DLL
02:23
on the C V s s or the C V e website,
02:27
the National Vulnerability database references C V E numbers
02:32
and within those TV e numbers will be a CVS s score.
02:38
We're actually going to take a look at how to do this in the demo, and you will have a lab assignment to do that as well. But the point here is that many times as developers, we blindly trust
02:53
the accepting of third party code
02:57
and immediately loaded into memory as this is being done in the static block.
03:04
One of the thing I want to make note of is the use of jar files
03:08
in a lot of
03:09
Java applications where the code has been written over several years. We can reference jar files of open source packages that are actually very out of date.
03:24
This is commonly done not out of any malicious intent, but just negligence. There are newer versions of those jar files that we should instead be using. And really, it just takes some discipline to go through that list or go through your palm file
03:45
and go ahead and update all of those dependencies. Now the next code sample that we have is from C Sharp.
03:53
This is importing vendor libraries
03:57
and in this one were actually
03:59
having the using statement import a vendor library. What we need to do in this case if we don't have access to the source code as we do in an open source version of a library,
04:13
is to actually challenge the vendor, the third party where we purchased this library
04:17
to share vulnerability scans or provide some sort of security posture statement
04:24
that ensures that their library or libraries are clean of any security vulnerabilities. Now the case study is on Adobe Flash. This is a vulnerability in adobe flash that came to be known
04:36
through the hacking team breach.
04:40
This vulnerability can actually allow an attacker full control of the victim's machine. If we take a look at the details in the C B E,
04:51
we can see that there's a C V E number referenced here.
04:57
2015 5119
05:00
And what state is that? Adobe Flash player, And it gives the version And earlier versions for Windows, Macintosh and Lennox have a successful exploitation that could cause a crash and potentially allow an attacker to take control of the affected systems.
05:20
So we could actually look this up and Google the CVI number to find out more details and regards to its CBSS score severity and affected modules.
Up Next
Instructed By
Similar Content
