"Exploiting a vulnerable Apache Tomcat Web Server."
In this video, we are going to be taking a look at how
to utilize the Metasploit framework,
more specifically the Metasploit framework
exploit modules, to exploit a vulnerable Apache Tomcat web
server.
So first and foremost, what is Apache Tomcat?
Apache Tomcat, also known as Tomcat Server,
is a popular, free, and open-source Java servlet web
server.
It's typically used to build and host dynamic websites and web
applications based on the Java Software Platform.
Now, the Apache Tomcat web server
utilizes the HTTP protocol to facilitate
the underlying communication between the server
and the client.
So it operates like a typical web server
and utilizes the HTTP protocol.
Now, Apache Tomcat utilizes or runs
on TCP port 8080 by default. So that's
one of the key distinguishing factors
or elements between a normal web server like Apache or Nginx,
that will typically run on port 80, and if-- or in the case
of an SSL certificate being installed,
will run on port 443.
But with Apache Tomcat, Apache Tomcat runs on port 8080.
So you might be a little bit confused here,
because you're hearing about a web server called Apache,
all right, and then you're hearing about a web server
called Apache Tomcat.
So what's the difference here?
Well, the standard Apache HTTP web server
is used to host static and dynamic websites or web
applications, typically developed in PHP.
And as I said previously, the default port
for a standard Apache HTTP web server
is going to be either port 80 or port 443.
Now, in the case of Apache Tomcat,
the Apache Tomcat web server is primarily
used to host dynamic websites or web
applications developed in Java.
So that's the key difference here, all right?
So the Apache Tomcat web server is primarily
utilized to host web applications or applications,
for that matter, that have been developed in the Java
programming language, whereas the standard Apache HTTP web
server is used to host either HTML or PHP web application.
So that's the key difference here.
Now, given that it hosts Java applications as well
as dynamic websites built with Java,
that opens it up to multiple types of vulnerabilities.
And in the case of Apache Tomcat version 8.5.19,
or any version below version 9, is vulnerable to a remote code
execution vulnerability that could potentially
allow an attacker to upload and execute
a JSP upload, which is essentially a Java Service
Page--
that's what JSP stands for.
So an attacker could essentially upload and execute
a JSP payload in order to gain remote access to the target
server.
So we can utilize a pre-built Metasploit framework exploit
module to exploit this vulnerability
and consequently gain access to the target server.
Now, in the case of this particular practical
demonstration, we are going to be
utilizing the lab environment.
So you can start it up, and we can
begin with the practical demonstration.
And you're going to see how Apache Tomcat differs
from a standard Apache web server
and how we can essentially exploit an Apache Tomcat web
server.
So I'll see you in the lab environment.
All right.
So I'm back within the lab environment.
And as you can see, it provides us
with the target IP address, which is very handy.
And of course, in your case it's going to be different.
But all you need to do is just copy it,
because we'll need it in a few seconds.
The next thing I'm going to do is open up a terminal here.
And I'm just going to maximize it and increase the font size
so you can actually see what's going on.
We now need to start up the PostgreSQL database
service, which can be done by typing
in service postgresql start.
That's going to ensure that we can
interact with the Metasploit framework database
and consequently create workspaces and store
data within those workspaces.
We can then launch the Metasploit Framework Console.
So we'll give that a few seconds.
We are then going to create a workspace, as we usually do.
And we're going to call it--
we are just going to call it Tomcat, because we're
exploiting Tomcat.
So I'm going to hit Enter.
We now can set our global variable for the RHOSTS value.
And we're going to specify the target IP.
This will, again, save us time whenever
we're loading any modules, as the RHOSTS
value will be set globally for any modules that we load.
So I'm going to hit Enter.
If we check our workspaces, you can
see we are currently utilizing the Tomcat workspace.
So the first step will essentially
involve port scanning and enumeration,
because we need to identify whether Apache Tomcat is,
indeed, running on the target system.
That can be done through the use of the db_nmap command, which
will perform an Nmap scan within the Metasploit framework
console, and consequently store the Nmap
results into the Metasploit framework database
within our current workspace.
So I'm going to perform a SYN scan.
We also perform some-- we also want
to perform some service detection as well as
the operating system detection.
We can then paste in the target IP and hit Enter.
And that's going to take a few seconds to a few minutes.
So I'm just going to wait for this to complete.
All right.
The Nmap scan is complete.
And as we can see from the actual results
here, that the target system is running Windows, and more
specifically either Windows Server 2008
R2 or Windows Server 2012.
And on port 8080, we can also see
that we have Apache Tomcat version 8.5.19, which,
as we know, is vulnerable to a remote code execution
vulnerability.
So now that we've identified that,
we can clear out terminal.
And of course, you can always access these services
on the target system that we just
performed an Nmap scan on by typing in the services command.
And as you can see, we get that information there.
So what we're going to do is search
for the actual exploit module that we
can use to exploit this specific version of Apache Tomcat, which
can be done by saying search, and we're
looking for an exploit module.
We can then specify the actual name
of the module, which in this case,
we know is going to be Tomcat.
And then we can specify the actual module name here.
And this is the exploit module, we are going to be utilizing.
So this is a Tomcat remote code execution exploit
via the JSP upload bypass.
And we can copy this module here, or rather,
the module name, and specify that we want to use it.
So that's currently loaded.
We can then clear out the terminal
and show the options for this particular module.
And as you can see, we need to specify the target IP
address, which is done because we
set the global variable for the RHOSTS option,
and we specified the target IP.
The RPORT option is set correctly.
And if we open up our browser, we
can actually confirm that we have Tomcat running.
So if we paste in the actual target IP, which in this case
is 10.2.20.126--
and of course, in your case it's going to be different--
and we of course, try and access port 8080,
we should see that we have Apache Tomcat running
on that port.
And so that's confirmed.
And the target URI is at the root of this particular web
server.
So we don't need to specify any other directory where Tomcat
is installed, as it's installed on the root of the web server.
Now, you can see another piece of information
is not provided here.
And that is the payload that we can
utilize to obtain a reverse shell or a Meterpreter session.
All right.
So if we click on the info command,
that'll give us an idea of this particular exploit
and what it does.
So it says that this exploit module uploads
a JSP payload and executes it.
So what this means is that, again,
it will upload a JSP file, which, again, is, as I said,
is a Java Service Page payload, which means we cannot utilize
a Meterpreter payload out of the box,
and we instead have to utilize a Java JSP shell payload,
which we can specify.
As for the targets that we can run this on,
we can run this on a Windows--
we can run this on a Windows target, which
we know is the case, or a Linux target in the event
that Apache is running on both--
on either Windows or Linux.
In our case, we'll leave it as automatic.
And we can specify the payload by saying set payload.
We can then specify this is a Java payload.
And then the name of the payload is jsp and shell--
so this is a nonstaged payload--
bind TCP.
All right.
And we're going to be taking a look
at how to get a Meterpreter session once we've
gained access.
So I'm going to hit Enter.
If we show the options now, you can
see that we need to specify the LPORT option.
So that's the port of the Kali Linux system
that we want to essentially listen on
for the remote connection or the reverse connection.
And then the RHOST--
or rather, the actual LHOST option.
And in this case, it's specifying the RHOST option,
which is the target address, and which is already
specified for us there.
And then we also need to specify the shell command, which
will allow us to specify the system shell to use.
And given the fact that the target system is running
Windows, we can set the actual shell
we want to use to CMD, as Windows utilizes CMD.
So we can hit Enter.
And we can run this particular exploit module.
So I'm going to let it run.
As you can see, it says uploading payload.
If that doesn't work, we can terminate--
we can actually terminate the execution there and run it
again, as this particular exploit
module will take a few tries in order for it to work.
And as you can see, it says, uploading payload,
payload executed, start the bind TCP handler
against our actual IP address here, or in this case,
the target IP.
And we get a command shell session on the target system.
So if we hit Enter, you can see we now
have a command prompt session on the target system,
not a Meterpreter session, but we can still
run Windows commands.
So we can type in dir or systeminfo.
Or we can actually get our current privileges
by typing in the get user ID command.
But because we're not working in a Meterpreter session,
we will need to run the whoami command.
And as you can see, we have NT authority system privileges,
which means we have the highest privileges
available on a Windows system.
However, this is not a convenient way
of accessing the target.
We typically want to obtain an Meterpreter session because
of all of the functionality that Meterpreter affords or provides
to us.
So because this is a command shell session,
we can put it in the background using the Control and the Z
keys on your keyboard.
As you can see, that's going to tell you,
do you want to put this into the background?
We're going to hit Yes and hit Enter.
If we list out our sessions, you can
see that we have the actual session here.
However, the type-- the actual type of payload
is specified as Java Linux, which
means even if we try and actually change or upgrade
our shell into a Meterpreter session through the use
of a built in post exploitation module, this will not work.
So what can we do here?
And this is where the technique that we actually
covered during the client-side exploitation section
will come into handy.
And that is the technique of generating payloads
with MSFvenom.
So what we're going to do is generate a Meterpreter--
a Windows Meterpreter payload with MSFvenom
and then upload it to the target through our command shell
session.
And we are then going to execute it on the target system.
And we should receive a Meterpreter session
on our handler.
So we'll also have to set up a handler.
All right.
So in order to do this, we want to persist this MSF console
session.
So we are going to open up a new tab within the terminal here.
And on our desktop or our current working directory,
which is under root, we are just going to say msfvenom.
And before we do that, we actually
need to get the IP address of the Kali Linux system
here, which we can do by typing in ifconfig and heading over
to the Ethernet 1 interface.
So we can copy that IP.
And then we can say msfvenom, specify the payload
as a windows/meterpreter/reverse_tcp.
Of course, you can utilize any of the Meterpreter payloads--
Meterpreter payload types in regards
to the architecture and the protocol that you want to use.
In this case, we're utilizing reverse TCP.
We then need to specify the Kali Linux IP address where
the handler will be listening.
And that's, of course, specified through the use
of the LHOST option.
We then specify the LPORT option.
In this case, we are going to utilize the port 1234.
And then the format is going to be exe.
And we'll output this into a file called meterpreter.exe.
We hit Enter.
That's going to generate the payload for us.
So we'll give that a few seconds.
Once the payload is generated, you can see that we have it
here.
There it is, meterpreter.exe.
We actually need to transfer this meterpreter.exe payload
onto the target system.
So how can we do this?
Well, one of the techniques that we can utilize
is the technique of setting up a web server on the Kali Linux
system to host this file and then download
the file on the actual target through an in-built Windows
utility, because, as you know, we don't have a Meterpreter
session.
That's what we're trying to establish.
So we can set up a simple web server
within our current working directory
to host the meterpreter.exe payload
by typing in sudo python -m.
And we're going to utilize the python m--
or rather, the actual simple HTTP server module that's
afforded to us by Python.
So we're going to say SimpleHTTPServer.
And we're going to host this on port 80.
We hit Enter.
As you can see, it's going to tell you,
serving HTTP on the Kali Linux IP on port 80.
So if we head back to our first tab
here, where we have access to the actual target via command
shell, we can interact with the session by saying sessions 1.
And if we hit Enter, you can see we are currently--
we currently have a command prompt,
and we are working within the Tomcat 8.5 directory, which
is perfectly fine in our case.
So in order to download this particular meterpreter.exe
payload from the Kali Linux system or the Kali Linux web
server that we have set up, we're
going to utilize an in-built Windows utility called
certutil, which can allow us, in this case,
to download files from remote systems.
So we're going to say certutil, and then we
are going to utilize the URL cache flag as well as the file
flag.
We then need to specify the actual web server IP
address, which in this case is the Kali Linux IP.
So we'll just copy the Kali Linux IP
that we specified there.
And then we want to paste that in there.
And the name of the file that we're downloading
is meterpreter.exe.
We then need to provide an output file that is, again,
going to be-- or rather, an output file name for the file
that we're downloading.
So we're going to say meterpreter.exe.
So we're just going to maintain the same file name.
We then hit Enter.
As you can see, it's going to tell you,
certutil URL cache command completed successfully.
If we type out the contents of this directory,
you can see we have the meterpreter.exe payload
downloaded successfully.
Fantastic.
So we can now terminate the web server
that we set up by using the Control and C keyboard
combination.
And once that is done, again, we need
to set up our handler to receive the connection once we
execute our interpreter payload on the target system.
So in order to do this, we can create a simple Metasploit RC
script, which we covered.
And in order to do that, I'm going
to use the Vim text editor.
So I'm going to say vim handler.rc.
And within this, we are just going
to say we want to use the multihandler.
And then we're going to set the payload
to windows/meterpreter/reverse_tcp.
We're then going to set the LHOST option to the Kali Linux
IP and then set the LPORT option to the port
that we specified when we were generating
our payload with MSFvenom, which in this case was 1234.
And we're just going to hit run so that we actually
run this particular multihandler to wait for the connection.
So I'm going to write and quit with Vim to save this file.
We're then going to say msfconsole -r
to load the resource script and say handler.rc.
That's going to set up our listener for us automatically.
You can, of course, go through the process of doing this
manually, but it's always good to, again, utilize
the various automation techniques
that we've learned so far.
So as you can see, it says use multihandler,
set the payload to windows/meterpreter/reverse_tcp.
It sets the Kali Linux IP as the LHOST option and the port,
and it starts the reverse TCP handler.
So we can now execute the meterpreter.exe payload
on the target system by moving onto our first tab
and then specifying the full stop
and forward slash or backslash command,
and then specifying the name of the file
that we want to execute.
In this case, it's meterpreter.exe.
We hit Enter.
As you can see, it's executed successfully.
And if we head over to our second tab,
you can see that we get a Meterpreter session opened
on the target system.
So we're going to wait for that to actually open up.
As you can see, the Meterpreter session opens up.
And we can type in sysinfo, and we now have a Meterpreter
session on the target system.
And if I type in get user ID, you
can see that the permissions we have available
are NT authority system, which are the highest
level of privileges.
And of course, we've been able to obtain a Meterpreter session
by utilizing an exploit module that
did not allow us to specify a Meterpreter payload.
So that's how to utilize all of the techniques
that we've learned so far in regards to creating
or generating payloads with MSFvenom.
And of course, you've learned a few new techniques
like how to transfer files from a Linux system
onto a Windows system through the use
of the certutil utility.
So we've gained access to the target system
by exploiting the Apache Tomcat web server.
And then, we of course, utilized our knowledge
of generating payloads to generate a Meterpreter payload,
transfer it over to the target, set up our handler,
execute the payload on the target through our command
shell session in order to receive a Meterpreter session,
which is much better than having a command shell session.
So that is going to be it in regards
to the practical demonstration for this video.
In the next video, we are going to be
exploring the process of exploiting a vulnerable FTP
server.
More specifically, we're going to get
into the process of exploiting services on Linux systems.
So we're going to start off by exploiting a vulnerable FTP
server.
And then we'll take a look at some of the other services
that we can exploit.
So I'll see you there.