In this lab, we're going to be practicing
utilizing a tool called ZAProxy, ZAP proxy, if you will,
put up by OWASP.
It's a great tool for scanning web apps and websites,
and it will run some vulnerability scans for us.
Let's get it set up.
We'll jump into our VM environment.
Start off by identifying our network, and let's
just run nmap scan on that guy.
There is 0 in there for the network.
It should be the same IP address with a dot three.
We'll just validate.
And it's correct.
Dot three comes back with HTTP and MySQL server,
and this is our machine, the dot two.
So let's grab that.
It's got port 80 open.
Let's check it out.
And we have bWAPP, another OWASP tool,
great for learning about some web bugs, which
is what we're doing here today.
And we can see that we've got credentials here
for bee and bug.
And we've played around with this site
before and other labs.
What we haven't played with much is the different bugs
that are part of this.
For example, there's HTML injection
reflected in this case.
So if you put in j m, hit go, and it prints it out here.
But we also see that it's up here in the URL.
So if I were to, say, Josh, changing the URL,
it reflects down here in the HTML
as well, which is pretty neat.
But what I really want to show you is ZAProxy.
So ZAP-- and it's loading up.
That is fine.
It's an older version, but it hasn't changed much.
It does not get the same sort of love
that some of our owned tools get.
We'll put in our URL, and we want to enable the HUD.
And we'll launch it, we can launch in Chrome or Firefox.
We're doing this manual explore in OWASP ZAP.
It's a neat tool, there's a lot of options here.
I went with the quick start.
This is a great way to get--
to jump into things and manual explore is neat.
So we're going to launch it with the heads-up display,
with the HUD, and it opens up and gives us the HUD.
And there's a whole tutorial to go through.
You can install ZAProxy on your own device
if you wanted to, again, practice with it,
and this bWAP is also installable locally,
but we're going to go through it in this lab here.
So let's continue to target.
You can see different things show up on each side.
There's already this login.php.
It's got X-Frame options header not set.
And that might matter to us, it might not.
Some of these alerts, again, might matter, might not,
it's kind of up to you.
You can start the spider, you could see the tree of sites.
You can run the Ajax spider and/or an active scan.
We will get into these.
They're kind of neat and powerful.
And there's different attack modes,
and you can watch them all here from this HUD.
Well, let's play around and let it capture some information
because as we navigate around, it adds sites here.
So we'll log in, and we can even go back and see, hey,
we did a post for this login.
And we can use that later.
We'll just bounce around a little bit.
Look at this HTML injection reflected and watch as it gets
added to our tree, to our list.
And we can go through several of these,
go through the drop-down, look at the post.
This one is a little different, but it's, again,
reflected HTML injection with a post request instead
of a get request.
In this case, because it's a post,
it didn't pass it as variables in the URL.
I think if we captured it, we would see here our post
would have that information.
This is not Wireshark, it's not capturing
all of our information in that same way
to make it easily viewable.
But we'll go through what that actually does in a little bit.
And we can just continue to bounce through some of these.
After the post, we could look at stored for the blog.
So what happens if you store some things, nothing too crazy
that identified us as bee since we're logged in.
Some of this, again, is fairly straightforward
and it's not in and of itself malicious.
This HTML injection that's stored for the blog,
not necessarily, yes, malicious, but it is-- it could be a bug,
might not be something that was intended.
Let's check out some of this SQL injection,
or SQL injection, if you will.
And let's search for Joe.
And hey, this works.
What happens if we do or 1 equals 1.
We'll play around with that in a little bit.
Just wanted to show what it's supposed to do.
You type in Joe, it does a search, comes up with GI Joe.
We'll play more with what the outcomes are
going to be in a little bit.
Once we, again, get into--
what's going on in this back end?
We're just doing some manual navigation around,
and that is storing up all of these sites that we visited.
The sites that we visit are going
to then be part of what we're looking for.
So that is pretty good right there.
I'm going to go find this login, the post login.php.
Yes.
And what I'm going to do here is include in context.
This is important.
We want to set context, and we'll
set it as default context, and that's fine.
And over here on the left, we're going to choose authentication,
and we can do form-based authentication.
And we can select which form, we'll
go over here to the right, and tell it
that we want that same form that was from post login
we actually logged in.
It was, see, bee and bug, this was the post data.
So we want that.
We're going to choose something different here.
Username parameter.
It says login, so we'll go with login.
And then there's this Regex pattern identified
in logout response message.
And for that, we'll just put login with a capital L.
When we log out, it will show up as login,
if that makes any sense.
And that's important because we--
we're about to set things up, so automatically
checks for some things for us.
So telling it-- a Regex pattern to identify whether it's
been logged out or not is important
because then it will try to log back
in and do a few other things.
Let's go back to that--
or rather I will in just a second.
Didn't get forced-- this forced user mode disabled,
wanted to turn that on.
I forgot to include users, so bee and bug.
And that is important, we need that checked.
There you go.
Now that, that is checked, we can click up here
and the forced user mode enabled, so now it's enabled.
There we go.
That'll help us out.
Important steps.
Now we go back, and this whole site I'm
going to include in context, in that default context.
So now it shows everything after--
just the URL is going to be included.
Hit OK on that.
Now that we have the context set,
that context having the login.php without
authentication and our user, going to go back to the full
URL--
I'm sorry, I guess the root URL.
We're going to attack and we're going to spider it.
We keep the default context and we'll pick a user.
We had set bee in there as a user to use.
So that is all good to go.
And recursive is good, and we will start the scan.
This is going to be a pretty quick scan.
What it's doing is it's spidering out.
You can see now we've got the spider in all of our sites
there.
What it did is it walked through the whole site
and included all of those pages in our list here.
Since our context includes everything
from the root of just the IP address, now all of these
are in our context.
That is helpful.
And we can see that we found 201 URLs.
So that is pretty neat.
You can even see how they were found if you wanted
to go through all these URLs.
We've done directory and file busting in the past.
Well, we just use a spider to do all that for us.
And it practiced, it used the credentials
that we gave us and did get requests and post
requests to find all that.
Pretty neat.
Well, now back to the root here and attack,
and we're going to do an active scan.
And we'll pick bee as our user.
Everything else we will leave as the default,
and we will start this scan.
All right, our scan is complete.
I changed the window around a little bit,
so it's easier to read things.
But we came across three highly critical alerts, three medium
and three low, and some informational-- let's actually
look at the alerts.
There's a tab here.
14 alert types.
First one's going to be cross-site scripting,
and it's persistent.
And you can go into detail about it here.
I'll talk about it.
What we just did was very similar to when
we ran that Nessus scan in a previous lab in this pathway.
This is one tool for utilizing both directory enumeration
as well as scanning for vulnerabilities.
It'll scan what it knows.
It'll scan how it knows.
You don't want to put all your eggs in one basket.
Hitting things with ZAP might be out of scope,
it might be too much, It might break things.
Knowing what tools are in scope and what you're actually
getting out of them and what you're actually providing
to your client is important.
So whether you're going to run Nessus,
whether you're going to do this all manually, use a proxy,
use Burp Suite, whichever it is, you need to scope that out
properly, understand what your tools are doing,
and then be able to utilize these findings,
these alerts, and put them into a useful report.
Whenever we came across directories, be it
with Dirb, or DirBuster, GoBuster, or BURP, or ZAProxy,
we want to take that information,
store it somewhere, maybe manually go
through each of the sites that we come across.
If this is a web app pen test and you're
expected to find things in each of those websites,
then you want to make sure you do all of that.
But let's look at what these alerts now mean.
So cross-site scripting, persistent alert.
And if you don't know what cross-site scripting is,
it's an attack technique, involves
echoing an attacker-supplied code
into a user's browser instance.
It gives us a URL where it was vulnerable.
So let's navigate there.
This is the browser that is running the HUD.
And we see here that there's a place to do HTML injection.
And it tells us if we use this code here
that it will do something.
And did it freeze.
There you go.
Added to scope.
Now it's in scope, not sure why it
wasn't including in scope before for the HUD, but it's in.
Threw in that code that it got right out of ZAProxy,
and we run it and we see we get an alert box with the number 1
inside.
And it was an alert with 1 inside.
So that makes sense.
So this page is vulnerable to that, also included entries
for us.
So that's-- taking what we found,
doing a proof of concept, we can also look over here,
in the HUD, those same three high ones show up here.
So we just did that htmli stored.
We go look at this cross-site scripting reflected.
Now that says we did something on the site and we saw it.
This one, it's another technique.
So you can go to--
we can replay this one in the browser, which is kind of nice.
It'll take us right there, and boom,
it ran the SQLI with a get request,
so it utilized the code in the URL and it gave us the alert.
Let's go into the last critical one that we have here.
It is the SQL injection.
And we'll just click on it, navigate there.
And so SQL injection may be possible.
The attack is this ZAP or 1 equals 1.
So I'm going to copy that code, and then we'll navigate here.
And we can replay this in the browser.
We didn't get anything.
We searched for ZAP and then this comment plus and 1
equals 1, that's what--
this is a URL encoding for equals.
If we replace this and with or, like it showed us,
and then we run it again, now we've done some binary math,
really.
So we put it in an or gate, and if either one of them is true,
then the whole thing is true.
If the whole thing is true, SQL is going to spit out everything
that we've got.
Haven't really gotten into SQL injection what it's doing,
but that's what this is.
So we searched for ZAP.
And then what we also did is do search for ZAP,
also search for anything else that's true.
1 equals 1 is true, it evaluates this true.
If your SQL input is not sanitized
to not take any extra characters,
then this is what you're able to do.
We spit out the whole database.
And it's not, in this situation, terribly important,
but depending on what your input is, perhaps
it's a place to input data, to be stored,
or maybe it's a e-commerce site.
So when you go to the search, if you're able to inject SQL,
maybe you get access to things that you weren't supposed
to have, including possibly usernames, passwords, customer
information, all of those would be very, very bad
for your e-commerce site to leak through SQL injection.
And so that's how we can use both the alerts here
from ZAProxy or through the HUD here.
It's a neat tool, it's a very helpful tool.
If you're getting started and you're not
super familiar with how all of this works,
this is a great introduction to everything
that is web app penetration testing.
Hopefully now that we've gone through some of the basics
and you've seen how a tool like this works,
if you come across a website, you can run a few basic steps
and maybe learn some information to include in the report.
This is not a full web app penetration testing course.
We are going to go through some more tools,
but at least you will have something in your toolbox
ready to go.