Web Application Vulnerability Scanning with WMAP.
So now that we've taken a look at how to identify
or how to scan and identify vulnerabilities on Windows
and Linux systems through the use of the Metasploit
Framework, as well as Nessus, we can also move or turn
our attention to web applications
and how to identify vulnerabilities
within web applications, as well as the web server
configuration.
And this is where WMAP comes into play.
So first and foremost, what is WMAP?
WMAP is essentially a powerful feature-rich web application
vulnerability scanner that can be used to automate web server
enumeration, as well as scan web applications
for vulnerabilities.
Now when I'm talking about vulnerabilities,
I'm simply referring to common vulnerabilities
like SQL injection, so on and so forth, right?
And as I said, it can also be used to automate web server
enumeration.
So if you remember during the enumeration section
of this course, we explored the process
of utilizing various auxiliary modules to enumerate
information from a web server.
Well, WMAP can essentially automate that process
and can do everything for us without us having to again,
load and utilize those modules.
So it really, really is awesome.
Another great thing about WMAP is
that it's available as an Metasploit Framework
plugin, which means it can be directly loaded
into the Metasploit Framework and comes part
of the Metasploit Framework package, which means you don't
need to download the module or the plugin
and then transfer it into the plugins module.
It already exists within the Metasploit Framework plugins
module, which means all that we need to do is just load it in
and we can use it.
And finally, the WMAP plugin is also--
or rather, it can also be integrated with the Metasploit
Framework database.
So all the results from our vulnerability
scan on a particular web application
will be stored within the Metasploit Framework database.
So it really, really is awesome.
Now in terms of the lab environment
that we will be using, we will be using the same lab
environment that we utilized during the web server
enumeration video in the enumeration section.
And if you remember, we were able to enumerate
quite a lot of information.
However, we weren't able to detect any vulnerabilities that
can be exploited.
And this is where vulnerability scanning comes into play.
So we'll be taking a look at how to identify vulnerabilities
within the web server configuration,
as well as the web application that's being hosted on the web
server with WMAP.
So I'll see you in the lab environment.
All right, so I'm back within the lab environment.
And the first thing we want to do
is, of course, identify the target
IP, which can be done by typing in ifconfig, hitting Enter.
And we're interested in the ethernet 1 interface,
and this is our IP address.
The target IP address is going to be on the same subnet
under the IP address 192.157.89.3.
So it's always going to be on the third IP address
on this subnet irregardless of what the subnet is.
So again, the IP will change within your lab environment.
The only thing you need to do is change the 2 into a 3.
So we'll copy that.
The next thing we want to do is start up the PostgreSQL
database service.
So I'm going to say Service PostgreSQL Start.
That will start up the database service
so that we can interact with the Metasploit Framework database.
And once that is done, we type in MSFConsole
to launch the Metasploit Framework console.
So again, we'll give that a few seconds there.
All right, so the first thing we want to do
is set up a workspace for all our work and for our scanning
so that all the data is separated from any other hosts
that you're working on.
So we'll say Workspace Add and we'll just
call this web_scanning right?
Just to keep things nice and simple.
There we are.
So we're currently within that workspace.
The next thing we want to do is set up some global variables
for the RHOST values so that we don't
need to, again, set the RHOST value whenever
we use a new module.
So I'm going to again, specify the IP and, of course,
change the 2 into a 3.
We hit Enter, and that should set up the global variable
for the RHOST option so that again, we
don't need to type in the target IP
whenever we're using a module.
All right, excellent.
So we can load up the WMAP module by typing in Load
and then WMAP.
Once we hit Enter, it'll tell you
the plugin is successfully loaded-- there we are, WMAP.
And in order to use it, what we can do is simply type in WMAP.
And then, of course, underscore, and you
can use Tab or to completion to list out the various commands
that you can run.
All right, so we have the WMAP Modules command,
we have Nodes, Run, Sites, WMAP Targets, WMAP Vulnerability.
So we can utilize any of these.
However, because we're doing this in a structured way, what
we want to do is firstly, take a look at our sites.
Because we want to add a site as our target.
So I'll open up the documentation
for the WMAP Sites command.
I'll hit Enter.
So this particular command is used to specify a site.
So we can use this to add a site that we want to scan.
You also have the ability to delete sites.
And again, that is in the event that you
want to delete another site or a site that you're done with.
And then of course, you can list out the available sites
and then display the structure.
In our case, we're going to add our sites.
So I'm going to say WMAP Sites.
And we'll say Add.
And to do this, we can type in the IP address right over here.
So I'll again, type in the target IP address there.
So WMAP Sites A, hit Enter.
That's going to say Site Created.
We then need to set up our target, right?
So we can open up the WMAP Targets, the WMAP Targets
command, and we can open up the documentation.
This allows us to specify the target URLs
that we want to again, perform a vulnerability scan on.
So we can define the target site.
So it's very simple.
We can either use a V--
Virtual Host URL space Virtual Host et cetera.
And we can also define the target IDs
if we want to change up the various IDs
for the various targets.
And that, of course, is in the event
that you have more than one target configured, right?
Because whenever you perform a scan,
the scan will go through all the targets in the order
that they are sorted.
So it'll start off with target 1, 2, 3, et cetera.
And then you can also clean out your targets.
So again, if you want to start afresh
with a new list of targets, you can use the Clean option
to delete your current list.
So to add one, we're going to say wmap_targets.
And we're going to specify the T option.
And because we're specifying the URL now,
we need to say HTTP, because we know the target server or web
server is running on port 80.
And of course, we'll change the IP to a 3 at the end.
And then you can specify a specific directory
that you want to scan for, but in our case,
we are starting off just basically within the root
of the web server.
So we're actually targeting the web application itself.
And we hit Enter, so that's going
to say WMAP Targets has been added.
And we can then, again, check our sites
by saying WMAP Sites and L. That will list them out.
You can see that it's going to show you
the sites that you've added and the port and protocol,
as well as the pages in forms that it's currently scanned.
This will be enumerated once we perform the scan.
You can also, again, do the same for targets.
So we'll say WMAP Targets, and then, of course, L, hit Enter.
As you can see, this will also display
the target IP, the port where the SSL has been configured.
And then the path if you've specified a specific path
that you want to perform the vulnerability scan on.
All right.
So as I mentioned previously, WMAP
utilizes the in-built Metasploit Framework auxiliary modules
to perform vulnerability scanning.
And of course, they are very useful in identifying
various vulnerabilities.
Now, in order to actually define or to set up
the specific modules that we want to use based on the target
web application, we need to utilize a specific command
here.
And that command is the WMAP T option or WMAP Run T option.
And what this will do is it'll essentially
check for the various auxiliary modules that would essentially
makes sense, or rather would be useful in regards
to our targets.
It will search for only the modules
that again, will be able to enumerate information
from all targets.
So it's not going to use any other type of auxiliary modules
that may be target the IIS web server.
So again, we can do this by saying WMAP.
And then under that, we'll say Run.
And then open you can open up the documentation for the WMAP
Run command.
And as you can see, this will show
you the all enabled modules for your particular target.
And in our case, we haven't done that yet.
So the next step would be to do that.
And then once we've done that, it's
going to say we can use the E option to launch the profile
modules against all matched targets, right?
So no profile will run all enabled modules
and so on and so forth.
So we'll type in WMAP Run and T to show all enabled modules.
And then we're just going to wait for that
to load the WMAP module.
So we'll give that a few seconds.
All right, so once that is done, as you
can see it will display all the auxiliary modules that
will be used to, again, perform the vulnerability
scan on our target based on our target configuration.
So you can see it's going to tell us
39 WMAP enabled modules loaded.
And for example, SSL testing-- because our target does not
have an SSL certificate-- it's going to disable SSL modules.
And then under Web Server Testing,
it'll give you an idea of the various auxiliary modules
it will use.
For directory brute forcing, it will again, do the same thing.
For unique query testing--
so this is for SQL Injection and HTTP Traversal--
these are the modules it'll use, which
can be very helpful in identifying SQL Injection
vulnerabilities, so on and so forth, right?
So in order to run our vulnerability scan
against the target, all we need to do
is type in wmap_run and then E. And because we're
using our current profile, we'll hit Enter.
As you can see, it's going to use
all WMAP enabled modules, which in this case, was about 39.
So the same thing there.
And you can see it's going to start testing the target.
And it says right over here, there's no SSL certificate.
And then it begins performing its checks
using the various auxiliary modules.
So for example, we get the web server version
by utilizing the HTTP version auxiliary modules.
So you can see that this pretty much
automates whatever we did during the web server enumeration
video.
And in this case, I'll actually show you
how to use this information to identify or detect
specific vulnerabilities that we can then exploit, right?
So it will run all the enabled modules and right over here,
it's now at the file and directory brute force stage.
So it's going to utilize all of the modules there
to essentially detect and identify
various directories on the web server,
as well as various files on the web server.
So this is going to take a few minutes.
I'm just going to wait for it to complete.
All right, so the scanning is complete.
And as you can see, there's quite a lot of information
that's output.
And all of this information, again, is quite important
and we'll get to that in a second.
So we start off with the results at the beginning here.
You can see that under the various HTTP enumeration
modules, we also have one here called the Auxiliary Scanner
HTTP Options module, which will essentially
check for the enabled HTTP methods, or rather--
yeah, exactly.
The HTTP methods allowed on this web server,
we can see that we have a GET HEAD
POST, which is interesting, and we'll get to that in a second.
And of course the Options method.
So with that-- and again, the POST method
is particularly important, but we'll get to that in a second.
You can see it also goes through the robots.txt file.
And in this case--
and you can see that we find the data
and secure directories that we were
able to find during the web server enumeration video.
And we targeted the secure directory
because that actually had an authentication form.
However, we were not successful with our brute force.
In this particular case, we will be targeting the data directory
because that one looks interesting.
And we'll actually take a look at how
to identify whether we can do anything
malicious with that directory by taking
a look at the various HTTP methods
that are currently enabled for that directory.
So we'll get to that in a second.
The other information displayed here
is really just the version information.
So you can see Apache, the version of Apache.
And then it performs the file and directory testing.
So we're able to identify the various directories on the web
server.
So we have data downloads, doc icons, et cetera.
We also have the secure directory, as well as
a few others here.
And we then move on to the file brute force.
So these are all the files that it
was able to find on the target web server.
So we have index.html Desktop PHP.
So nothing really interesting there.
And then we have the HTTP, the auxiliary module here.
Auxiliary Scanner HTTP, HTTP PUT.
You can see that in this case, it
targets the default route of the web server
and it tells us the file doesn't seem to exist.
However, we'll actually come back to this particular module.
So I'm actually just going to copy it because we can actually
use this module to test a few of the allowed HTTP methods.
And because we have the POST method, which is very,
very interesting and is very similar to the HTTP PUT
method-- we'll actually test that in a few seconds--
you can see that essentially goes through all the modules
here.
And in this case, we can see it's
not vulnerable to SQL Injection or anything like that.
You can also list out all of the vulnerabilities
that WMAP was able to detect by firstly typing WMAP
and then underscore vulnerabilities.
And then if we open up the documentation
for this particular command, you can
see we can list out all the vulnerabilities using the L
option.
So if we hit Enter, these are all the vulnerabilities
it was able to find.
And in this case, it's mostly just directories here.
So you can see we have the Pro directory,
and then, of course, all of the other ones here.
So these are really not vulnerabilities.
However, if we take a look at the output,
the most important piece of information
that we are able to identify here
is the various HTTP options available
or that can be used on this web server.
And as I said, we can utilize the HTTP PUT auxiliary module
to actually test whether or not we can upload or put
a file within a directory.
And of course, this is not a safe method
to actually have on a web server or to have configured on a web
server because attackers can potentially
use it to upload malicious files or they
can use it to deface a website.
So in this case, what we'll do is
we'll just go back to the bottom here
and we will essentially just say Use and paste
in the module Auxiliary Scanner HTTP, HTTP PUT.
However, before we actually do that, if we again,
use the HTTP Options module--
and then if we show the options here,
you can see that the target IP has
been configured because of the global variable we set.
If we just hit Run on the default directory,
you can see for the root of the web server,
it currently says that we have the GET HEAD POST options
methods.
So what we can do is let's actually use the HTTP PUT
auxiliary module to test various directories on the web server
to see whether we can actually put a file
within that specific directory.
So again, if I say Show Options, you
can see that the current action is set to PUT.
So we can either PUT or DELETE a particular file or resource
from a web server.
And then the file data is specified here.
And in this case, what it's doing is
it'll try and put a file called MSF HTTP PUT TEST.TXT.
And then the actual data within that particular file
will be MSF Test File.
And the path is set to the root of the web server
so we can just hit Enter and run a quick test.
As you can see, the file doesn't seem to exist.
The upload probably failed.
All right, so that means that the root of the web server
currently doesn't allow us to utilize the PUT method.
So we can actually change that to the Data Directory, which
looked very, very interesting.
So again, if we set the path here to Data
and then we hit Enter and then Run,
you can see that it says the file was uploaded successfully.
A-ha, so we've been able to again, test that vulnerability
and then exploit it.
And in this case, we have the ability
to upload or to actually put a file within the Data Directory.
And that's probably why it was set up.
And in this case, what we're doing is
we're essentially exploiting a poorly configured web server
or web application for that matter.
Now the HTTP PUT and POST methods
are fairly similar in that they allow us to essentially create
a new resource or are used to send or submit data
to a web server.
And of course, you should be familiar with them
if you've worked with HTTP, the protocol.
In this case, what an attacker would typically
do is they would essentially utilize
this vulnerability or this misconfiguration to upload
a web payload here, right?
So they will essentially specify the file name and the file data
and they'll upload a web payload to the target web server.
And then they'll set up their reverse listener here,
a Meterpreter listener.
And then whenever they'll browse to that particular directory
and to that particular file, then that particular payload
will be executed.
And consequently, the attacker will actually
receive a reverse connection if they actually configured
a reverse shell payload.
So in our case, what we can do is we can actually test and see
whether this file has actually been successfully uploaded
to the target by saying [? Curl, ?] pasting that,
and then hitting Enter.
And as you can see, it displays the content of the file here.
Just disregard the actual syntax formatting here.
You can see it says MSF Test File.
So let's try and change this up a little bit just
to confirm that this is the case.
So I'll just clear that out and if we show the options here.
What we'll do is we'll change the file data.
So I'm going to say Set File Data right over here.
And we'll put it within two quotation marks.
And we'll say, "this does work."
And we'll then hit Enter.
And we then want to set the file name to something else.
So I'm going to say Set File Name to maybe something like
this_works.txt.
Hit Enter, and lets hit run.
And as you can see, it says File Uploaded.
And we can test and see whether that actually works by again,
utilizing [? Curl ?] and then pasting in that there.
And as you can see, it says "this does work."
So we now have been able to identify a vulnerability
by of course, performing a vulnerability scan
with the WMAP plugin.
And in this case, we've been able to successfully again,
test a vulnerability or rather exploit
it to ensure that we actually have a vulnerability
that we can work with.
And as I said, this particular vulnerability
can be extremely harmful because an attacker can essentially
upload any malicious file.
And that file could consequently provide them with access.
Now in our case, we don't have a browser so I actually cannot
showcase this.
But it would work fairly similar in that I would essentially
just upload a PHP Meterpreter module here.
And once that is uploaded, I simply
need to navigate to the URL right over here on my browser.
And once that is executed, or rather the PHP module
is executed, what will happen is I will get a reverse shell.
So you can utilize WMAP to identify
all sorts of vulnerabilities within a web application.
And again, when we're talking about specific web applications
or third party solutions like content management systems,
we'll be exploring how to identify vulnerabilities
within those web applications and how they can be exploited
during the exploitation phase.
For now, all I wanted to really cover
was the process of utilizing WMAP because it
can be very, very helpful.
And in our case, we only were able to find one vulnerability
because this particular target web server has really just
been configured to highlight a few of these techniques.
So that is going to conclude the practical demonstration.
All right, so that concludes the vulnerability scanning
section of this course.
In the next section, we'll begin exploring
[? BlindSide ?] attacks.
And furthermore, we'll be taking a look
at how to generate and encode Windows and Linux
payloads with MSFvenom, as well as
exploring how we can inject payloads into Windows
portable executables.
So I'll see you there.