Welcome back. In our previous lesson, we covered
how to prevent authentication bypass. In this lesson, we're going to look
at finding vulnerable components. After this lesson, you will be able to use
the OWASP dependency-checker to find and verify if you have vulnerabilities in your
code because of an unpatched component. So let's dig it. There's a couple examples of this. Number five, we're not going to patch
just because it's in jQuery and patching it is just the same as patching
the second vulnerability which is a little bit more interesting. So, there's a vulnerability
in jQuery 1.10.4 that allows you to inject JavaScript
into the jQuery UI is dialog box. So, this comes up the XXS
comes up even though only this text box is supposed to come up. In 1.12 that was fixed. And as you can see just
the text box is coming up and they're telling us it's
the same exact code. So, that gets really interesting. And then obviously,
they use this vulnerability here and they cite CVE-2013-7285, but
we're actually going to do a little bit of a different comprehension
of our own code in a second. So I'm not going to click this link and
I'm just going to explain a couple things. So, on tap four of this module, it talks about the vulnerable
components that is inside struts and it has five criticals,
9 severs, and 0 moderates. So, we definitely know that WebGoat
is using multiple packages, some of the lessons require it. But let's take a look at how many
vulnerable packages we have. To do that, we're going to use a tool, Called dependency checker by OWASP. I can't spell dependency correctly. So dependency check is one
of OWASP flagship tools and it can be built into your CI/CD pipeline. So have whether you're using Jenkins or
Maven or whatever you're doing to do
your continuous integration and continuous builds, you can integrate
this dependency check into your code. And it will essentially give
you a build materials and it outputs all the various components and
modules that you're using. So, I installed it by running this
command since I'm running on a Mac. However, you can use it in an and
task, Maven Plugins, Cradles, etc. So, on our command line,
I'm going to go to do a Maven build but
before I do any of that, I'm going to stop this package or
stop my IDE. And I'm going to do a Maven package, which is essentially going to
create a WAR file for me. WAR file is a web archives similar
to a JAR, and actually in this case, it's going to create a JAR for
me, I apologize. And I'm going to ask for it to skip tests, because they take a very long time and
I know they're going to pass. I'm not really worried
about the tests breaking, I just wanted to build my library for me. All right, now that we have our JAR
file builds, going to clear the screen. And you can actually see
the JAR file right there and we can do our independency
check against it. Now, I've ran this command before so
I'm just going to use it. So you need to give it a project file. So it's going to create
a demo something HTML and they need to tell it what to scan. Good and run that. All right, and we can just simply open
up the demo file that I created so it's a dependency check report for
the demo project, since one demoing this. So here's our project name, and
we have a few vulnerable libraries here. But what I'm really interested
in is the extreme 1.4.7. And, if we go back to our WebGoat
instance, although it's shut off right now, you can see that there is a lot more
notable libraries that it reports against. Let's launch WebGoat. So the question becomes, how can we go about exploiting
this JAR that we have in here? So, there's two different
vulnerabilities under extreme 1.4.7. The first one is the CVE right here and
the second one is this CDE right here. So they both look really
interesting to me, but I'm going to open up
both of them in new tabs. So, I'm going to open up the most
recent one in the second tab and then finally the third tab. So, you can use denial of service
through an marshalling, it looks like. That is the vulnerability with the first
one, okay, or the most recent one. And the second one,
Based on this bug report. It looks like it's an XXE processing
which we did during our injection module. So it sounds like the 2016 one kind of allows us to do some basic XXE stuff. So let's look at the actual vulnerability. 449. And sure enough, it does allow for
an XXE vulnerability. So we're somewhat familiar
with XXE vulnerabilities. Let's give that a try. So I already typed up an XXE. And, if you actually launch, let's go
ahead and log in and I can show you. If you actually launch
any attacks against this. This is not like the comment section that
we did our XXE bond before where we kind of got some feedback, stuff we're being
posted nothing comes back in this example. So it's similar to the second example
of the XXE stuff where it was blind injections. So I kind of written an XXE
that I think will work and I'm going to put this in here. And, if we look at the injection
that I'm doing here is, I'm trying to load an example.txt file. This is the same file we made together
with the secrets on localhost port 9999. Now, if you're running your code
inside of a Docker container, this will not work simply because you
won't have access to localhost, right, you will but
it will not be your localhost. What I'm going to do is, I'm going
to run a web server on my desktop so that I can serve that file up. I'm doing it with Python because it has
a simple HTTP server built into it. And, with just this I can get
a simple HTTP server going. In fact, let me show you how that works. I can go to localhost, 999 example.txt. So if I launch it,
it's the same file that we had. This is a secret that no
one should be able to read. And if you notice, I get a bunch of
get calls here that I can look at. And every time I refresh it,
it gets the same file for me. So I'm going to clean out my terminal
window just to see if this works. If this code is truly vulnerable,
I should be able to cause this to call upon that
example.txt and load it. So if I hit go and sure enough,
it does reach out to get it. So we know we have XXE
through this extreme for XML parser that's going on here. All right, so the question is,
how do we go about fixing it? Obviously in our injection, we showed that once you've verified that
you have some sort of injection going on, you can essentially start
building your attack chain. And do more and
more malicious things with this. So the question is,
how do we go about fixing this? So I'm going to stop the video here. In a future video, I'll go over what you
need to do to attack against this and how we can make this actually work. Go ahead and give it a try and
I'll see you there.