In this lesson,
we're going to go through a couple of different ways
to look at web applications.
We're going to use Nikto, which is a vulnerability scanner.
We're going to use Burp Suite, which is an
interception proxy.
And we're even going to go through
and look at some SQL injections
and some hands-on injections.
So, let's go ahead and get started.
What I'm going to do first is jump into my lab environment,
and we're going to start with Nikto.
As I said, Nikto is a web application vulnerability scanner.
If you think about Nessus and Qualys and things like that,
those are used against your infrastructure,
servers, routers, switches, and hosts.
But if you want to look at a web application in depth,
you really want to use something like Nikto.
So, you're going to go into your terminal
and you're going to run the command nikto -host
in the IP of the host you're trying to scan.
In my case, it's 10.1.0.10.
Now, once you do that,
you're going to see some of the issues that were found.
For instance, you can see on this first line
that the server is an Apache 2.4.6 server
being run on CentOS.
Now, as you go through,
you can see there are some anti-clickjacking options
that are not present.
You could see some cross site scripting protection headers
are not defined.
You can see some X-Content-Type-Options is not set.
And as you go down,
you're going to see all the different vulnerabilities.
As you get even further down,
you're going to see things that say OSVDB,
which are some vulnerability database files
that are going to tell you exactly what was tested.
So, you could see that under 877,
there's an HTTP TRACE method that is activated,
and this suggests that the host is vulnerable to an attack.
And so as you go through,
you can identify each of these different things,
and then you can look them up, research them,
and figure out how to solve those issues.
Now, the next thing we want to do is test our website
and look at it from a probing perspective
for directories and files.
We can do this using a different plugin inside of Nikto.
So, I'm going to use nikto -host 10.1.0.10 -Plugins,
and then the plugin I want to use.
In my case, it's going to be a dictionary,
under dictionary:/usr/share/wordlists/dirb/common.txt.
When I do that, I'm going to be able to run a scan
for common file and directory names on that server.
Next, let's run a command
to find any files that require authorization to view.
I can do this by using nikto -host 10.1.0.10 -Display,
and the number 4.
Note, this will show me all of the files
that are now identified
that would've required authorization to view.
The next thing I want to do
is try to perform a credentialed scan
against that web application,
and I want to save that output as an HTML report.
Nikto can do this as well.
We're going to type in nikto -host http://10.1.0.10/dvwa,
which is the web application that I want to go after,
then -id and the credentials.
In my case, admin with a password of password.
And then I want to output that by using -o
and then /root/downloads/dvwa.htm,
and then -format and put it into HTML format.
So, I'll type in htm.
Once I do that, I'm going to now have that file
inside that root directory underneath the downloads folder.
If I want to see that, because it's an HTML file,
I need to open it using Firefox.
So, I'll type in firefox /root/downloads/dvwa.html,
and this will show me all of the information in that report.
Now, as I go through that report,
I can see all of the different issues that were found.
For instance, there's directory indexing not found,
there's configuration information
that could be remotely available,
and there's other things like that as we go through it.
For instance, this PHP reveal that's being shown,
where sensitive information is being displayed to the client
as they go into that application.
So, these are all just a quick summary
of some of the issues we found
with this vulnerable web application.
Now, the next thing I want to test
is I want to move beyond Nikto.
So, we've done Nikto
and we have some good baseline knowledge of how this works.
Now, let's move into Burp Suite.
Burp Suite is an interception proxy.
And so the first thing I need to do is configure it.
To be able to configure an interception proxy,
I have to set up my proxy on my web browser.
So, I'm going to go into my web browser,
and I'm going to type in about:preferences#advanced,
and then press Enter.
When I do this, it's going to bring up a page,
and I need to scroll all the way to the end of the page
and click Settings.
Once I click on Settings,
I now need to select
the Manual proxy configuration radio button,
and then type in the web proxy's address.
In my case, 127.0.0.1.
That's my localhost.
That's the machine where I'm going to be running Burp Suite.
Then, under the Port, I'm going to type in 8080,
which is the common HTTP proxy port.
And then, I'm going to check Use this proxy server
for all protocols.
So, anything running on this machine that uses the network
will use this local host as my proxy.
And then I'm going to click OK.
And next, I need to open up Burp Suite,
and I need to accept the default configurations.
Now, we're ready to start inspecting sessions
and header data.
To do this, we are going to use Burp Suite
to monitor and record those web sessions.
This will allow us to inspect it.
And if we want,
modify the data that's going between the browser
and the server.
This can include things like your headers, your cookies,
and your form field submissions.
Now, the first thing I want to do
is click on the Proxy tab
and then click the Intercept is on button
to toggle that intercept off.
Now, I want to arrange my Firefox and my Burp Suite windows
so I can see both of them as I'm going through this process.
So, you'll see I have them on the left and the right.
In Firefox,
I'm going to go to the website that I want to look at.
In my case, www.515support.com/dvwa.
And then, I'm going to log into that web application
using my credentials.
Now, as a regular user, I have usernames and passwords.
In this case, I have admin as the username
and password as the password.
Now, in Burp Suite, I can click on the HTTP history tab,
and this is going to list all of the different requests
that have been proxied while Burp Suite was on.
Now, if I select the GET row,
I can see the request here for dvwa.
Note the server's response here,
they're issuing a redirect to the login page.
Now, if I select the GET row,
requesting that dvwa/login.php form,
this is going to show me exactly what happened here.
I can go ahead and check
the output of the various tabs here.
Things like Raw, Headers, HTML, and Render.
And as I look at those,
I can see the browser's request and the server's response.
Now, you can see here
that the application has set two different cookies.
One is to identify the security level
that we're going to be issued
and the other is to set up a session ID.
Now remember, HTTP is a stateless protocol.
So, if I want to be able to tell who is talking
to my server,
I have to use cookies
or some other session management technique.
All right, now if I select the POST row,
I can see the information
that was submitted from my browser.
In here, you can actually view the clear text credentials
inside of Burp Suite.
So, I can see that the username was admin
and the password was password,
and that they use this user token
of this random long string.
Now, why could I see this credential information?
Well, because we use HTTP instead of HTTPS.
And so you could see why it's so important
that you use secure connections
when you're transiting information back and forth.
The next thing I want to start working on
is testing command injection.
And so to do this, I'm going to go into the browser
and select the Command Injection tab
in the DVWA web application.
Now, obviously, in a real-world experience,
the attack would have to spend a lot of time
mapping out pages and forms
and finding things through their reconnaissance,
but DVWA is built for us to be able to use this
with known sets of bad issues
so we can test things against it
and see what they look like in the field.
Now, when we do this, we see that there is a box here
that's going to allow us to put a command in.
Now, it's supposed to be used for the ping command,
but if somebody didn't program this right,
that means you might be able to run any command you want.
So, let's go ahead and try it.
All right, so I'm going to enter 10.1.0.1 in the box
and click Submit.
This is going to allow me to ping that device,
that web server.
Now, that works great.
But what if this person didn't do their coding right?
And instead of just issuing the ping command,
I could issue other commands maybe.
Well, let's try a couple of Linux commands
and see if we can do a command injection.
Let's try inserting ls and typing Submit.
What do we see?
Nothing, it didn't work for us.
All right, let's try something else.
Let's try typing in 10.1.0.1, like we did before,
and then put && ls.
What happens this time?
Well, there you go.
We got the ping that we are expecting,
but we also got the directory listing.
So we were able to do a command injection here.
Let's go ahead and try another one.
Let's try 1 && ps -e.
This will tell us if it's going to accept anything
with a number first and then going from there.
Well, that one didn't do anything.
Hm, let's try something else.
Let's try putting in 10.1.0.1 && ps -e, and click Submit.
Yes, that one worked.
It does the ping,
and then it shows me the processes
that are being executed here.
So, it is allowing me to do command chaining
as long as I start with an IP address.
Let's try some more.
How about 10.1.0.1 && netstat -tlnp, and then click Submit.
Is this going to work?
Yes, it is.
We are going to get that ping
and then the executing of that command
because we're chaining these commands together
inside this box.
It appears to me that all this box is doing is checking.
Did you put in an IP address?
And it's going to execute that by a ping.
And then if you use the &&,
you could put any command you want afterwards.
So, I might be able to access files.
For instance, what if I could go in there
and use 10.1.0.1 && cat /etc/password, and click Submit.
Look at that, we were able to get the ping
and then we got the password file.
Well, if we can get the password file,
let's go ahead and grab the shadow file.
Let's try 10.1.0.1 && cat /etc/shadow, and click Submit.
Now, unfortunately, reading the shadow file didn't work.
Why is that?
Well, because the shadow file has specific permissions on it
to protect it from things like this happening.
Now, the command cat /etc/shadow did work,
but it couldn't display the shadow file
because that shadow file is protected.
Now, to confirm this,
let's go ahead and check a couple more commands.
Let's try 10.1.0.1 && whoami.
This will tell us who we are actually operating as.
And in this case,
you could see we're operating as the user known as apache
'cause we're running it through the web server.
Let's go ahead and see if we can get some more information.
What if we did 10.1.0.1 && getent password 0.
What is this going to do?
Well, this is going to get us the root user,
which is user ID 0.
It's going to get their information from the password file
and display it to the screen.
Now, if we do this, we want to see
what the group is for that.
We could try that
by doing 10.1.0.1 && getent group and then root.
And when we do that,
you're going to see that we have the root user
is a member with group x and is the user ID of 0.
Next, let's go ahead and try doing some fuzzed input
and see if that's going to do anything for us.
So, what we're going to do here
is instead of just inventing different commands
to throw it this misbehaving inbox,
we can start doing a more structured approach
by sending in fuzz data.
This is a fuzzer.
And essentially, we can use Burp Suite as that fuzzer.
This will help us to automate a lot of this testing
instead of me sitting here
and typing in all these commands by myself.
So, let's go ahead and click on the SQL Injections tab.
And here, we're going to type a 1 in the box
and click Submit.
When we do that, we see what the function is supposed to do.
When you give it a user ID,
it's going to give you their first name and their last name.
In this case, admin and admin.
Now, in Burp suite, if I go to the HTTP history tab,
I can right-click on that last request
and click Send to Intruder.
Now, once I go to the Intruder tab
within the Intruder module,
I can select the Positions tab
and then click the Clear button.
Here, I'm going to select the character 1
following the id= in the first line,
and then I'm going to click Add.
Next, I'm going to click on the Payloads tab.
And from here,
I'm going to click the Load button and then browse
to /usr/share/wordlists/wfuzz/injections/sql.txt.
And then I'll click Start attack.
Now, what is this doing?
Well, what I just did was I selected
the variable that I want to change, that id=1,
and I want to start putting id=
whatever the lines are of this SQL file.
And so this is going to automate my attack for me.
So, as I go through,
it's going to go through and put each
and every one in there.
And as that attack progresses,
you're going to observe the Length column.
The unmodified input is going to return a page
that is 4868 bytes in length.
Now, if you look at the response with a length of 4809,
you're going to see they're basically blank.
While anything smaller
has returned an unformatted error message.
Now, if we want to sort the output by length,
we can click on the Length column
and then we can look for any response
that's larger than 4868.
For instance, I have one that is 5176.
This is a ' or 1=1 or "='.
Now, what does that look like to you?
To me, it looks like an SQL injection, right?
And if you look through this,
all of these different things being shown here
that are above that threshold of 4868
are different forms of SQL injections.
Now, I want you to look at the response
for anything with that single quote payload,
because again, this is a simple SQL statement.
And basically, if this form that we have on the DVWA
isn't doing input validation,
it's going to allow me to do these SQL injections.
All right, enough of that for now.
Let's go ahead and close the Intruder window
to stop our attack.
All right, so now that we know that this thing
is vulnerable to SQL injection,
let's take a look at the code itself
and do a manual analysis of it
so we can review that vulnerable code.
If I switch back to my browser
and I click on the SQL Injection page,
I can click it and then look at View Source.
When I do this, the source code is going to pop up.
When we look at that,
we're going to compare all levels by clicking
on that button.
Now, as we compare each iteration of the code,
we can see that the higher security code
has some input validation while the lower ones don't.
For example, you can see the is numeric function here
within this first if block.
Now, basically what this does
is any input that comes in is checked using if is_numeric.
And if it is numeric, it's going to process it.
If it is not numeric,
it's going to delete it and just ignore that.
This essentially is a basic form of input validation.
Now, this only is going to check this number, this input,
if it is a number,
because we're expecting id to equal some number,
and so we want to prevent anything else from being there.
So, if I put apostrophe, that would prevent this, right,
because it's not numeric.
Now, you'll notice at the bottom,
under the commented code here,
we also have this little validation statement
that's going to make sure only one result is returned.
So, if I put in number 1, I should only get the first entry,
the admin, admin.
If I put in 2, I should get that for the second user,
and not the third, fourth, and fifth user.
This should only give us one row at a time
from the database.
As you can see here,
that the data inside the row count has to be equal to 1.
If it is, get the values.
If not, we're going to ignore it.
So, that's the way that we can do
some basic input validation.
So, this is a good input validation method
to prevent an SQL injection.