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.