Exploiting the Bash Vulnerability CVE-2014-6271,
also known as Shellshock.
All right.
So we're now getting started with the Linux exploitation
section of this course.
And the first vulnerability that we're going to be exploring
is the Shellshock vulnerability.
Now, the interesting thing about this vulnerability
is it was probably one of the biggest vulnerabilities that
affected Linux over the last, I would say,
over the last 15 to 20 years, and for a good reason.
And again, the reason that makes this vulnerability
so dangerous or critical in regards to a Linux system
is the fact that it essentially allows an attacker
to remotely execute arbitrary commands on the Linux target.
And the exploitation of this vulnerability
really involves two services-- one of them is Apache,
and the second one, of course, is Bash.
All right.
So let's learn more about this vulnerability.
Shellshock is the name given to a family of vulnerabilities
in the Bash shell since version 1.3, which was released,
I think, somewhere in the '90s.
So again, it really affected a huge number of Bash versions
after version 1.3.
So this vulnerability essentially
allows an attacker to execute remote arbitrary commands
via Bash, consequently allowing the attacker
to obtain remote access to the target via a reverse shell.
And that's where it primarily gets its name from,
so Shellshock.
That tells you that in there somewhere,
or rather, this vulnerability allows an attacker
to get a shell on the target system.
The Shellshock vulnerability was discovered by Stéphane
Chazelas--
I hope I'm not mispronouncing that--
on the 12th of September 2014 and was made public
on the 24th of September 2014.
So again, given the actual critical nature
of this vulnerability, patches were released soon after.
And of course, companies and organizations as well as
individuals were actually informed
to update their versions of Bash as soon as possible.
However, given the current fragmented nature of the Linux
world and the various distributions
available out there, the patching or the updated
packages were added to repositories
based on the actual distributions release--
the actual release cycle.
So if a distribution had a slower release cycle,
maybe after every six months, then packages could--
rather those distributions could actually
be releasing the updated patches for Bash very, very late.
However, you had the ability to update it manually.
And that's one of the great things about Linux.
This vulnerability really isn't very common anymore.
But it's very important that you actually learn about it
and get an idea as to how to exploit it.
And this will really tie into the web application penetration
testing course on INE as well as the eWPT certification.
So learning about command injection, in this case,
is very, very important.
Now, what is Bash?
If you've never used Linux before,
Bash is essentially a *Nix shell.
*Nix is essentially an abbreviation for Unix-based
operating systems, and Linux is a Unix-based operating system.
So Bash is a *Nix shell that is part of the GNU project and is
the default shell for most Linux distributions.
So whenever you install, really, any distribution--
Ubuntu, Debian, Arch, Linux, Fedora--
by default, the default shell is going to be Bash.
Now, what is a shell?
Well, a shell is essentially a command line interface.
So on Windows, you have your command prompt,
and on Linux, you have your various shells,
and Bash is the de facto standard for most distribution.
So again, this vulnerability really
did shake up the whole Linux industry in regards
to vulnerabilities.
Now, the Shellshock vulnerability
is caused by a vulnerability in Bash,
whereby Bash mistakenly executes trailing commands
after a series of characters.
And these characters are really down to the fact
that there is a vulnerability within Bash
in regards to the environment variable function declaration.
Now, I won't get into the actual nitty-gritty
of this vulnerability and how it works.
All that you need to know is that if these characters are
input into Bash, really, any other commands
executed after these special characters will
be executed by Bash.
Now, again, given the fact that this vulnerability primarily
or really exclusively affects Bash,
the vulnerability really only affects Linux as Windows does
not utilize Bash as it is not a *Nix-based operating system.
So this vulnerability really was pertinent only to the Linux
operating system.
Now, in the context of remote exploitation,
Apache web servers can be configured to run CGI scripts
or shell scripts that are vulnerable to this attack.
And you might be asking yourself, well, I'm
not really understanding what's going on here.
You're saying the vulnerability is related to Bash,
or it's a vulnerability within Bash,
but how does that tie into CGI scripts?
Well, CGI, which stands for Common Gateway Interface,
CGI scripts are used by Apache to execute arbitrary commands
on the Linux system, after which the output is displayed
to the client.
So if you're running a web server,
an Apache web server, and you're hosting
a web application irregardless of whether it's
a PHP or HTML or anything like that, you can create or develop
CGI scripts to essentially obtain information
from the system.
So, for example, if I wanted to get the current time
on the Linux server, I could use the CGI script
to essentially execute the time command
and then redirect or display the output on the actual website
or the web page.
So again, many web servers or many websites
actually utilize this functionality to limiting--
to varying degrees.
And again, you don't see it anymore now
for obvious reasons, primarily because if the attacker is
able to execute the CGI script and in the case
of this vulnerability, pass in this special set of characters
as well as additional commands that you would like to execute,
he could potentially use this vulnerability
to execute arbitrary commands that could be malicious.
So CGI scripts are used quite a bit on Apache,
and they're very, very useful.
And of course, you'll see exactly how
they're used during the practical demonstration.
So coming down to the actual exploitation
of this vulnerability, in order to exploit this vulnerability,
you will need to locate an input vector or script that allows
you to communicate with Bash.
That's really the crux of this vulnerability.
Now, in the context of an Apache web server,
we can utilize any legitimate CGI scripts
accessible on the web server.
And because they are interacting with Bash
or getting Bash to execute some commands,
we can utilize or send a request with this particular CGI script
and get those special characters inputed as well as
any other commands that we would like to execute.
So whenever a CGI script is executed,
the web server will initiate a new process
and run the CGI script with Bash.
So whenever we make an HTTP request for that particular CGI
script, the web server will initiate a new process
and run the CGI script with Bash.
So we can essentially input the special characters
that I highlighted in the previous slide
within one of the HTTP headers.
The most effective technique is to actually input those
or inject those parameters or characters
within the user-agent HTTP header
and then specify the other commands
that we would like to execute after those characters.
So in terms of exploitation, as I said,
we can do this both manually and automatically.
Manually, this can be done really
easily by the use of a proxy.
So we can use the Burp proxy.
And in terms of automating this particular attack,
we can also utilize an MSF exploit module.
And in both cases, I'll be showing you
how to obtain a reverse shell or a Meterpreter session,
respectively.
All right.
So now that we have an idea as to what this vulnerability is
and how it can be exploited, let's get
started with the practical demonstration
side of this video.
And this video already has a lab environment attached to it.
So you can start it up, and you can follow along
with the techniques.
So I'm going to start up my lab environment,
and I'll see you within the lab environment.
All right.
So I'm back within the lab environment.
And in this case, you will not be provided with the target IP,
but that can easily be obtained by opening up your terminal.
I'm just going to open that up and maximize this,
so you can see what's going on.
If you type in ifconfig and take a look
at the interface Ethernet 1, this
is your IP address here or the IP address of the Kali Linux
system.
The target IP address is going to be the next IP
address within this subnet.
And of course, in your case, the subnet
is going to be different.
All you need to do is just change the 2 to a 3,
and that's the target IP.
So we'll just copy that there.
And I'm going to form an Nmap scan on the target
to identify whether we have an Apache web server running.
So I'm going to say nmap, and we'll perform a service version
detection scan.
And I'll paste in the target IP, so I'll change the 2 to a 3,
and I'll hit Enter.
And I'll give this a couple of seconds to complete.
All right.
So the Nmap scan is complete.
And as you can see, on port 80, the target
is running an Apache web server.
So we can actually confirm that.
I'm just going to copy the target IP right over here.
I'm going to open up my browser.
And let's actually confirm whether we have a website
or a web server running.
So there we are.
I'll hit Enter.
And as you can see--
let me just maximize this.
You can see that the website is currently under construction.
However, if you pay close attention,
there's a piece of text here that
doesn't look to be rendered in HTML
or doesn't seem to have any CSS attributes associated with it.
And this essentially tells us that the website
will be online in 0 days, 23 hours, and 57 minutes.
Really, really cool.
But how is this being done because it
looks like it's very dynamic, and it's
being done on the server side?
Well, this is being accomplished through the use of a CGI
script.
So if we view the actual source of this page
and take a look at where that particular-- at where
that particular output is being displayed,
you can see there's some JavaScript here.
And we can see that it actually executes a CGI script called
gettime.cgi.
And the CGI script is stored in the root of the web server,
which means we can access it.
It's publicly accessible.
So we can say, gettime.cgi.
All right.
So and you can see, it just displays the actual information
that we got on the website.
And that means that the web server has
a CGI script that we can use.
And again, this CGI script is parsing in commands to Bash
or is executing commands with Bash.
And what we can do is utilize this as our input vector.
However, we also need to check as
to whether this particular server
or whether this particular system is
vulnerable to the Shellshock attack or vulnerability.
And that can easily be done with Nmap.
And the way we can do that is by saying Nmap and then utilizing
an Nmap script.
So I'm going to say nmap, and we're
going to perform service version detection scan.
I'll paste in the target IP.
We're going to say script equals, and in this case,
we're using the Shellshock script, so shellshock.
And the actual name here is HTTP shellshock.
There we are.
And then, we need to specify the script arguments,
and the script arguments for this particular script
are essentially utilized to specify where
or the actual CGI script that we're testing.
So I'm going to say script arguments.
And then in double-quotes, I'm going to say HTTP,
and these are the script arguments, so http-shellshock.
There we are, and then we specify
shellshock.uri to specify the actual URI of the CGI script.
In this case, the CGI script is under the root of the web
server, and the name is gettime.cgi,
and we can then close the actual quotation there.
And we can hit Enter, and I'm just
going to wait for this to complete.
All right.
The Nmap script scan is complete.
And as you can see, it gives us the basic information
we got previously.
However, the output for the http-shellshock script
tells us that this target is vulnerable.
So you can see http-shellshock vulnerability state
is vulnerable and exploitable.
It provides you with the actual CVE right over here.
And this web application might be
affected by the vulnerability known as Shellshock.
It seems the server is executing commands injected
via malicious HTTP headers.
All right.
So that means we can utilize the CGI script and inject our own--
we can essentially inject the actual characters,
the special characters, within HTTP headers.
And in this case, we will be injecting them
in the actual user-agent header.
So in order to do this, what we're going to do
is we are going to open up the Burp proxy.
But before we do that, this particular lab environment
has Mozilla Firefox already configured
with FoxyProxy, which is a plug-in that
allows you to automatically switch between proxies.
And a Burp Suite profile has already been created for you,
so just click on there.
That means that all traffic will be
redirected to the Burp proxy.
We can then open up Burp Suite by clicking on the Kali menu
and heading over to web application analysis and Burp
Suite.
And we'll give this a couple of seconds to start up.
This is a temporary project.
Next, we're just going to use the default configuration.
And we're going to give this a couple of seconds to start up.
All right.
Disregard the actual message there.
And we're going to click on Proxy
and make sure that intercept is set to on.
I'm just going to afford these requests here.
And then, we can request or make a GET request
for the gettime.cgi script.
So I'm going to say reload.
And you can see it's going to be intercepted within the proxy.
And as I said, we are going to be
injecting the special characters in the user-agent HTTP header.
In order to do this, we can send this particular request
to the repeater.
And I'll then click on the Repeater tab,
and we can get rid of the user agent information here.
And we can replace that with our own--
with the special characters.
And in order to do this, we're just
going to paste or type them in.
So we start off with two brackets,
and we then have curly braces.
And within the curly braces, we are
going to specify that we want a colon and semicolon.
And then we're going to close the curly braces.
And we're then going to specify another semicolon,
and then we're going to say echo.
I'm just going to type that in correctly, so
echo and echo, again, so echo semicolon, echo semicolon.
And then we can execute our own commands.
So we can say /bin/bash -c.
And in this case, let's try and print
out the contents of the password file on the Linux system.
Of course, you can execute other commands.
So I'll just say cat /etc/passwd.
And let's see whether we can enumerate that information
and test whether this actually works.
So to actually send that request with a repeater,
let me just expand the window here.
We can just say send, and you can
see that this will actually display
the output of that command.
So I'm just going to open up Burp again here,
and there we are.
So you can see that we specify we wanted to access
the contents of the file cat /etc/passwd.
And you can see that is executed,
and we get the output right over here.
So the password file on Linux essentially
contains a list of all user accounts.
So it looks like we have a syslog account, a nobody
account, as well as a backup account,
and the root account right over there.
All right.
So that essentially verifies that this vulnerability
does indeed work.
Now, what if we wanted to gain a reverse shell on the target
system?
How would we go about doing that?
Well, we can utilize Bash to essentially connect
to a listener on our Kali Linux system.
So in order to do that, we're going to set up
a listener with Netcat.
So I'm going to say Netcat -nvlp.
And I'm going to listen on port 1234.
I'm going to Enter, and it's going
to listen on that port for the connection when it is executed
or when a connection is made from the target system.
I'm then going to open up Burp Suite.
And within this particular-- within the request field here--
let me see if I can actually zoom in here, so Burp.
I'm just going to zoom in.
All right.
So I've been able to zoom in, so you can actually
see what's going on here.
And you can see that this was the command
that we specified earlier on.
And what we're going to do is we are just
going to replace this particular command here
because we are going to be connecting
with Bash to our listener.
And in order to do this, we are going to say bash -i.
And we are going to connect, so I'm
going to just output this or redirect the output.
And we are then going to utilize the dev/tcp binary, so dev/tcp.
And then we need to specify our Kali Linux IP and of--
remember, in your case, it's going to be different.
So I'll open up a new tab here, and I'll say ifconfig,
and your IP address is going to be the IP attached
to the interface Ethernet 1.
All right.
So I'll go back into Burp, and I'll paste that in there.
And let me just make sure that that is formatted correctly.
There we are.
And then, I need to specify the port that we're connecting to
on our Kali Linux system.
In this case, it's port 1234, and then we
are just going to say 0 redirect the output and 1.
There we are.
And we can essentially just hit Forward or Send,
and we should get a reverse shell on our Netcat listener,
and we do.
So you can see we get a connection from the target,
and we're currently logged on as the daemon user @victim-1.
So I can say, who am I?
And I can also enumerate the information
regarding the distribution.
So I can say cat /etc/*issue or cat /etc/*release.
So you can see, we're running Ubuntu 14.04.6.
And uname -a.
All right, and we are.
So you can see that gives you the kernel information,
et cetera, et cetera.
All right.
So that is how to exploit the vulnerability manually using
the Burp proxy.
What we're now going to do is take a look
at how to exploit this vulnerability
with the Metasploit framework.
So I'm just going to open up a new tab here.
And we'll start up the PostgreSQL Database Service.
And I'm also going to start up MSF console,
and we'll give this a couple of seconds to start up.
All right.
So that is started up.
And we can search for the actual name of the vulnerability.
So I can say shellshock, and we have
two modules that we can use.
First of all, we have the auxiliary module here.
I'm just going to zoom out.
So let me just zoom out here, so you can actually see that.
So we have the auxiliary module which
will tell you whether the target server is vulnerable.
And then we have the exploit module right over here.
All right.
And I'm just going to copy that there, use, and paste.
All right.
So you can see Apache mode CGI Bash environment
executable or execution.
And then, we can clear the terminal
and show the options here.
And in terms of the options that you need to specify,
you need to specify the target or rather
the target IP address as well as the port
that the web server is listening on.
In this case, it's port 80, so that's fine.
So ideally, we only need to specify the target IP,
which, in this case, I'm just going
to copy from my web browser.
That is right over here.
So I'll just copy that there.
And what I'll do is I'll just disable
or get rid of Burp Suite right now because we don't need it.
There we are, and I'll also disable the Burp Proxy,
so turn off.
And you can see we can still request for that CGI script.
So I'm going to say set RHOSTS to the target IP.
And I'm just going to get rid of the HTTP option there,
and I'll hit Enter.
And we then need to specify the target URI.
That is essentially the path to the CGI script.
So I'll say set, and we're going to say TARGETURI,
and we're going to set that to gettime.cgi.
All right.
So once that's configured, I can hit Exploit.
There we are.
Looks like it works, and we get a Meterpreter session
on the target system.
So again, sysinfo.
We'll pretty much get exactly what
we got on our reverse shell.
So there we are.
It's running Ubuntu 14.04, and you now have access
to the target system.
And of course, the next logical step
would be to elevate your privileges.
But we'll get there when we get there.
So this is going to conclude the practical demonstration
side of this video.
In the next video, we will be taking a look
at how we can exploit FTP, or rather, a Linux
server running FTP.
All right.
So I'll see you in the next video.