Welcome to the Hacker House Hands On Hacking web theory
module.
We're now going to cover all of the theory around the web
and web servers in particular.
So if we think about the technologies
we've looked at so far, these are all external perimeter
technologies.
These are things that most organizations would have.
So open source intelligence.
Making use of public presence, public information.
DNS servers.
Everybody's using domain names or something.
Email.
Most people are sending and receiving emails.
But also web as well.
People are often using websites.
They have a very visible web presence.
They have some web server that's hosting information
or interacting with it.
So this is all very focused on the technology
that enables us to use the web.
So the World Wide Web, or the World Wide Web
of vulnerabilities, as it's sometimes referred to,
are the common internet services that we often
see when we're using our web browser.
So they typically operate on ports 80 and 443.
however, in practice, they are found on pretty much any port.
So don't just rely on those two ports.
You'll find them all over the port range.
And so Hyper Text Transfer Protocol
is defined in RFC-2616, and that is the way in which we transfer
this textual represented information,
that's hyper text or HTML markup language.
Basically, we would transfer it through this this protocol.
It's describing how we transfer these pages to each other.
So the content that it might render
is the rendering content.
So things like JavaScript, Flash.
These various rendering technologies.
XML, HTML, and other feature-rich content as well.
Things like Web 2.0, AJAX, asynchronous XML requests,
and various other feature-rich technologies
that you would find such as Flash.
So we are going to look at a typical web server.
We're going to look at typical web server in a common web
server environment, exposing various common weaknesses.
And the type of setup we're going to look at
is a LAMP setup, commonly known as the Linux,
Apache, MySQL, and PHP.
It's one of the most commonly-used development
or deployed stacks in the wild.
Linux, Apache, MySQL, and PHP.
What we're going to look at is something
called the 3-tier architecture.
And the 3-tier architecture is the most common web application
architecture in existence.
And that is that it has a client tier.
Your client tier is your web browser,
the thing that's rendering these pages.
And then you have your web application tier.
And that's your web server that's hosting these pages
but also your application server that's maybe running some code,
doing some things in the server to keep track of what you're
doing on the site.
And then that will query a database tier, or a data store,
a back-end data store.
So that's the 3-tier architecture
that most people try to envision when
we approach a web application.
And there are variants to this.
It's not the only one that exists.
But this is a very common one, the 3-tier architecture.
Likewise, there's a number of common softwares
which are used.
So we have Apache, which is a very commonly-used software
package for hosting web pages and websites.
NGINX and IIS.
These are three of the most commonly-used web platforms.
And they are common software that power the web servers.
And these servers, they leak information about themselves
in the headers.
So when you connect to these servers
and you make valid web requests to them,
you'll actually find that information
will leak back and come back from those requests.
It's headers, things like this server Apache argument.
And you can actually enumerate various extensions
and technologies that web servers support.
Because they may they may have been extended.
They might not just have been designed
to render web pages to send you content for your rendering
of pages.
They may, in fact, have been designed
to do more capabilities.
They might have better extensions and technology.
So you can actually interrogate the web server
using the options verb and identify
any kind of technologies that might of use.
Equally, there have been a number
of vulnerabilities in these kind of common web applications
software packages.
We can see, Apache had a number of exploits in 2002 and 2007.
Apache-nosejob and the lovingly not safe for work
named SSL overflow.
And you also have this NGINX vulnerability here.
A chunked stack overflow that was exploited.
A brilliant exploit by a guy named [? Saul Bou, ?] I
believe.
And then they've got these Microsoft IIS exploits,
WebDAV overflow.
And again, some of these really old attacks
like Unicode Path Traversal.
These are basically CVE numbers.
These describe the vulnerability within that software package
that we could use to maybe run commands.
And some of these numbers here have
been ways in which you could run commands on a web server
through the misuse of vulnerabilities.
So a number of common bugs to look at that
are interesting there.
So Uniform Resource Identifier.
Used to identify a resource on a network.
In fact, you probably should be quite familiar with them,
because if you go to a website like http://,
you're actually using a Uniform Resource Identifier anyway.
And the way that these Uniform Resource Identifiers work
is that we describe the protocol of a scheme in which we're
accessing the network resource.
Then we give the user a password @host port,
and then there's this path.
And they query and fragment parameters here.
And if you think about path, what that path is doing is,
it's referring to a file on that server
or a file in that environment or a file
in that piece of software.
And then it's got that parameter equals variable.
And that parameter equals variable is in fact arguments
to a program that's being run on the server.
So this is in fact a server-side script
which is running some program, it's
running some code on a remote server.
And it's using this as input.
So the parameter equals variable is
the arguments that are being given so that remote code.
And if we were to change those arguments
and mess around with some of this Uniform Resource
Identifier, otherwise known as a URL,
you would basically find that you
could change these parameters.
And it's something known as HTTP parameter tampering.
HTTP parameter tempering is a way of changing these arguments
and trying to get the program to do things
that it's not supposed to do.
When you make a request to a website-- hopefully,
you're all familiar with what one of these looks like,
but this is a HTTP get request.
Inside of here, we can actually see this is the client.
It's making a request to the server.
It's making requests to this website.
And it's giving the server some options about what it supports
and what kind of software it is.
The server is then going to reply
and the server says, oh, hey.
Here is the page you asked for and all
of the other bits of options and some information
from the server.
Of particular interest to us is the fact
that it contains the server string of Apache.
So we know it's likely an Apache service.
And then also some various security options
that might be set, which shows that it may be a slightly
security-aware site, or that it has other bits of information
as well.
XMLRPC that might be of use for us to do a probe on
and having it explore from.
We also have HTTP methods and verbs.
So if we look at other requests there,
we can see we're making a simple get request.
We're telling the server to get stuff.
Well, there are other methods or verbs you can use.
You've got GET, HEAD, POST, PUT, DELETE, TRACE,
OPTIONS, and CONNECT.
And in fact, GET, HEAD, and POST,
if I was looking at a production web server in a production
environment, I would expect it to only reply
with GET, HEAD, and POST.
I would not expect any other additional technology
to be enabled.
However, in this case, you can say GET, request the resource.
HEAD for authentication.
POST to send some data.
And that's really all that you would expect, really,
in a production environment.
However, things like PUT and DELETE
can be used for interacting with files
on the server maybe trying to delete files or load files.
Using things like TRACE, you can actually
try to see debugging information.
OPTIONS you can use to probe the server
and see what technology it supports.
So GET, HEAD, POST, and OPTIONS are probably
the three you would expect in a production environment.
Anything else is probably superfluous to requirements
and may be susceptible to some bugs.
And again, CONNECT is a way of using a web server as a proxy
to connect to another site.
So cookies.
Sadly, not the edible kind.
But cookies are used to store session state and information.
They're used by web servers to keep
track of things that are happening
at application layers.
Keep track of clients further up the technology stack.
So cookies contain variables.
So if you change your website preferences--
you can go to a website and you change English to French,
these cookies contain the variables
that you specified previously, the information that you
set on that server.
And these security flags that can
be enabled to prevent these cookies being
abused by some attacks.
And they're sadly not edible, but cookies
are way of keeping session state,
keeping information, keeping data about a visited client.
And they're called cookies.
Equally, web crawlers, or bots, a web spider, or a web robot,
is the process of crawling a site,
opening up every Uniform Resource Identifier,
or every URL--
open up every URL, access every page that it can see,
parsing through all the rendering content,
through all the markup language.
And then try and extract out all of the references
to images, to files, to directories.
And to then basically build a map of that website
by crawling the website to identifying any content that
might be visible.
So robots are used to search websites and crawl the content
and find what can help there.
They check a file called robots.txt for instructions
on what not to look at.
So they'll check the robots.txt file,
which might tell them not to mirror the /admin directory,
for instance, or the /secretstuff directory.
So if we were an attacker and we requested that file,
we might learn some areas of a website
that perhaps the administrator doesn't want us looking at.
So we'll go and look at them.
Another way, instead of just crawling a website
is that you could also guess hidden content
in a semi-intelligent way.
You could actually conduct some brute force attacks
against the file names and directories
and identify any non-indexed content.
For instance, by going to our website and doing /test,
/test/1, /test/2, /test/3 over and over.
Or look for common file names. /docs, /read, /readme,
things like that.
So just by guessing, by doing brute force, by guesswork.
As I said before, all good things
come to those who brute force.
So there are various tools you can use.
You can use dirb on the command line.
Or a product by OWASP, which is a tool
called DirBuster, which is a full-featured graphical client
that can do the same job.
And it's just basically guessing content through file names.
So back in 1997, around this time when the internet just
used to be a big cesspool of people's Lycos and Tripod home
pages, where it was just a little man digging up
the road with his little spade, and everyone
had a guest book that nobody filled in
or had 500 entries that were mostly made up friends--
but basically, the internet was a mess.
And it didn't look really good.
So we have a technology called Common Gateway Interface,
which was a way that we could run programs on web servers.
And that was how people were making guest books.
They were making little pages.
And it became very popular with Perl programmers at the time.
And these Perl programmers started
creating CGI applications to do things
like guest books, guestbook.pl, and various other counters
and things like that.
And because these were Perl programs,
it was found that a lot of these kinds of CGI applications
were vulnerable to commands.
Because you're effectively running
commands on a remote server.
And just by having some kind of configuration
or being able to send your own arguments,
you could sometimes subvert these programs
and make them run your input as well.
So you could generate dynamic web content taking arguments.
And it's still around today.
You see the Common Gateway Interface, or CGI,
still exists today.
It predates things like PHP and ASP.NET,
but you find it in a lot of embedded systems.
You find it in a lot of appliances.
You find it in all kinds of technology stacks.
It's just a way in which a lot of things have kicked around.
Shell scripts, perhaps, for monitoring purposes.
So you still see the Common Gateway Interface.
It's still something we come across,
even though it's been around forever.
So as an alternative to that, what happened was,
PHP, the server-side scripting language--
is an interpreted language that's
interpreted by a thing called the Zend engine.
And it was ad-hoc-ly developed until 2014.
People started writing PHP as a kind of, let's make the web.
And it just ad-hoc-ly sprung together
with all kinds of different functionalities.
Huge libraries, loads of functionality.
And it's widely used to implement sites
these days with dynamic content, et cetera.
And it often contains juicy data and its config.php.
And obviously, because it was very ad-hoc-ly developed,
and it was thrown together in such a way,
it has lots of vulnerabilities.
There's been lots of mistakes made.
And it's got quite a myriad of different attacks you can use.
Java servlets are an alternative to the PHP and ASP.NET.
They are written in Java.
And you might have something like Apache Tomcat, which
is a Java servlet container.
And something like Apache Tomcat will basically
take these Java applications, these Java servlets,
as compressed applications in WAR files.
And these are just zip files where they're bundled together
web content with various servlets
and application code that can then run in this kind of Java
container environment.
And this Tomcat is the application
that's used to deploy these Java containers.
And of course, it contains management interfaces,
ways to help you deploy and interact with it.
And that's been known to be full of various bugs and attacks.
In fact, it's such a big problem that the Apache Tomcat product
had to re-engineer the way that it taught people
to install its products.
Because people were installing it and not securing it,
so that they had to revert that so that people were installing
it secure by default by making them pick stronger user names,
things like that.
Strong passwords.
So it's out of the box.
It's had a very long history of being attacked.
So HTTP authentication is a way in which you could password
protect a web page.
So if you were connected to a web page,
and you get a little prompt up, it's part of the HTTP protocol
that you could send a challenge response header, or just
a basic request to actually get a prompt on a user's screen.
They type in a username and password,
and that would then append an encoded username and password
and send that authorization or that information
as part of the web header to be able to request that content.
And RFC-2069 is one for digest authentication.
This is a challenge response.
But you can actually take-- when it's a basic authentication,
you can actually take that encoded string there,
and you could decode it as its simply not encrypted at all.
It's just an encoded thing.
You can decode that back to the username and password.
When people began publishing technology on the web,
they didn't all start using different ways of doing it.
We had various attempts at trying
to get file transferring onto websites very correct.
So people will use things like-- you'll
find all the time-- file transfer protocol to just
simply copy contents onto web services files.
People are often using content management system as a way
to manage their content.
If you've got someone working in the marketing department,
they might just manage it through a web interface
and click Publish.
And then it will go onto the press feed.
So they'll be using something like a content management
system to do that.
They could be using FrontPage extensions,
although much more rarely seen today.
This was when Microsoft had the brilliant idea that everybody
would like to write web pages in its flagship Office
suite, Microsoft Word.
So they created a FrontPage extension,
which allowed you to write your web page in your Word document,
click Publish, and send it on with an application called
FrontPage.
And it was a terrible idea and largely a flop.
But basically it was around for some time.
So there were extensions that exist
that you could use with it to upload files onto content
and publish onto web servers.
Also, much more widely used is the Web Distributed Authoring
and Versioning system, which is WebDAV.
Out.
WebDAV is built into most operating systems.
And it adds additional HTTP verbs
that allow you to upload and download files
from a server when it supports it.
And WebDAV can be used from the command line.
And you can often find the presence of WebDAV
by querying the options.
And in fact, if you query the options,
you'll see whether there's any other extensions or technology.
But uploading files, publishing content onto websites,
there are a number of technologies
that tried to make that process easier for people.
And therefore, we try to misuse those easier processes
and see whether we can abuse them.
So a proxy.
A proxy is a way of forwarding one request
from one web server to another.
These can have authentication on them.
Hopefully, we're all aware of what a proxy is.
I'm hiding currently behind seven proxies.
And if you were to go to these proxies,
you may be prompted with authentication
to be able to connect through those proxies.
And then also, you might have some open proxies,
which are proxies which anyone can connect through and use.
And then you have the reverse of that,
which is what's known as a reverse proxy.
And this forwards requests from the web
into an internal server.
So it does it in the reverse.
It connects you from the outside to a host internally.
So that's a reverse proxy.
And obviously, when you find proxies,
you can do things scan through them.
You can use them to hide your identity, as I said before.
I hide behind seven proxies.
Good luck catching me.
So there you have Webmin.
Webmin is another utility.
It's a web application that is sometimes found commonly
on Linux servers.
Very popular in North Korea for managing their web style Linux
estate.
But Webmin is an application that's used.
It's for people who don't like Linux.
It allows you to shut down the computer
or control the computer, do basic tasks
or update the computer, et cetera, all through the comfort
of a web application.
And it will largely runs as root.
So that's the Webmin interface for use of interest.
Equally, you'll come across something called a Web
Application Firewall.
And this is slightly different to how a traditional firewall
works, which is how I hope most of you
are aware of how firewalls work.
It's why we need the reverse shells,
so that we can connect through firewalls.
And basically, if were you to try
to connect to a web server on a non-web port,
the network layer would block you, hopefully,
and say, you can't come through here.
However, if I was to make a request to the web server
port that wasn't malicious and just requests the web page,
it would pass through the network firewall,
through the web application firewall,
and reach the web server, and I'd get my web page.
And the idea is, if I can change that
and made a SQL injection, for instance,
and put a SQL injection attack, it
would go through the network layer firewall.
But then the web application firewall
would spot that it was a SQL injection attack
and not send the request to the web server.
So people often use these, mistakenly believing
that they're fixing a vulnerability by just
putting a WAF in front of it.
And it's kind of a bit of a joke,
because you can usually encode your request in some way,
or try to figure out a way to bypass that application
firewall and reach the target server
and still exploit the vulnerability.
So Web Application Firewalls.
Things to be aware of.
You'll often come across them when you're
scanning sites and systems.
So what goes in a web application hacker's tool box?
Well, there are various things.
You'll need all of these various different tools.
So if you're going to start hacking web servers
and websites, you're probably going
to need a web browser, because you're
going to want to see what's running on those sites.
You're going to need some tools for interacting
with that server.
Curl, wget.
Some things for requesting content from it.
You need at intercepting proxy to change that web
browsers requests and response.
And you can use man in the middle proxy, which
is a free open source tool, or a commercial product
which has a free offering as well called burp.
And there's some web spiders to do some crawling.
So netwox.
Again, you could use some tools in burp.
Web Application Scanner.
I want to do some automated web app scans
with a tool like Skipfish.
And again, content discovery.
I'd want to use something like DirBuster or dirb
to try and find hidden content.
I'd also want to do a CGI scanner or a vulnerability
scanner.
And a very popular tool for doing this by Rain Forest Puppy
is called Nickto.
And you could simply run Nickto to basically run a CGI
scan against the database.
There's various web extension tools, as well.
WebDAV, FrontPage extensions, FTP.
You might want some database attacking tools like SQLMap
if you're going to attack the 3-tier architecture,
but we'll cover databases in the later module.
You're also going to need some exploits or some
what are known as shells, or PHP shells, ASP.NET shells.
If you hack a web server, and the web server
is using ASP.NET, you're possibly
going to get a way to upload some code.
You're going to need to upload some ASP.NET code
to interact with that server.
So you're going to need some exploits and some tools
like that.
We'll look at some of those.
And we're going to look at some tunneling utilities as well.
How to use and misuse proxies and use them to chain
and hide behind the seven proxies using
a utility like proxychains.
So this is an example of man in the middle proxy.
It's a traffic intercepting proxy.
It's my preference for a proxy, because the man in the middle
of proxy, it's open source.
It runs in the console.
And it's written in Python.
You can script it and modify and do cool stuff with it
I quite like it, but it has a bit of a steep learning curve.
And it's not very user friendly or intuitive.
So alternatively, you could use Burp Suite.
OWASP top 10.
You'll come across the OWASP top 10.
There's no point reinventing the wheel.
But the OWASP.org website is full of absolutely useful
information of all kinds of different vulnerabilities.
And they continually update what they consider the top 10
types of attacks.
And overwhelmingly, number one seems
to be injection-related attacks that result in exposure
of data on websites.
And so there you have the OWASP top 10,
and you can read through their website, which
gives you numerous examples of application layer attacks.
But for this module, we're really
going to focus on more of the infrastructure side of things.
We're going to look more at the web server, the web server
technologies, and less at the application layer,
although we'll do some of it, because we're
going to do a web application module later on in this course.
So just for the moment, I want you to familiarize yourself
with the OWASP top 10.
Be familiar with that website, because it's
got some brilliant resources on there.
It's a great one to browse through when you get to web
applications and web servers.
So kinds of vulnerabilities you might see.
Things like Directory Traversal Attacks.
If we go back to our example where
we looked at that fubar.PHP, you might see a request for us
to access a file from a web server.
You might see some attempts to load resources
from external locations that will access things.
You might see something like file=somefile.txt.
And a Directory Traversal is basically
a weakness that allows you to access files or content
outside of an application's intended scope.
So for instance, if we changed somefile.txt to dot dot slash,
dot dot slash, dot dot slash, dot dot slash,
dot dot slash, dot dot slash, et cetera, slash password,
we could potentially expose the password file of a system
through a Directory Traversal vulnerability.
And so if you find vulnerabilities like this,
you want to get that config.PHP file, configuration files,
because if you dig around in those,
you might find some passwords and juicy bits of data.
So that's what you want to look for when
you find those kinds of things.
Equally, Command Injection Vulnerabilities
are, as we said before, the number-one way
in which websites are breached today
is still injection attacks.
And command injection attacks, arguably
some of the most damaging.
They are happy when you have PHP or CGI that runs commands
directly on the server.
And you need to be very wary of this thing called
an un-sanitized command lines.
And to quote somebody, they are land mines.
So basically, PHP or CGI will run commands on a server.
And if they're not sanitizing the command line,
you could potentially inject your own commands.
And that's been described by somebody
as being a bit like a land mine, and I agree.
So you've got these special characters
that you could potentially supply
that can be used to inject extra commands to a system.
So you've got a pipe, a semicolon, a back tick, a tick,
an ampersand, left brackets, and right brackets.
They're all quite dear to me, and I love them all equally.
But in particular pipes and ticks
often result in causing commands or breaking out of the command
and causing things to be done.
There are also some shell variables or built-in variables
in the scripting languages you might want to use,
such as $IFS.
If you can't add a white space, maybe you can just type $IFS,
and it will add a white space to your command for you.
Various other little tricks that have
been developed over the years.
So various shell variables might help you.
Command injection usually allows for interaction
with the web server and therefore, potentially
access all of the web application data
and information that's stored on it.
So you have CVE-2014-0160.
This is Heartbleed.
We discussed Heartbleed in an earlier module,
and we demonstrated how to use Heartbleed to extract memory.
There's another cool feature of Heartbleed
that you could also use it to potentially recover
the private key from a server and decrypt SSL traffic
by having access to that server's private key.
And the that worked was that if that server used
something called RSA, you could actually
search in memory for some of the prime numbers associated
with that certificate and extract that key information
and generate the private certificate
by doing an RSA factorization.
You would factorize the prime numbers
in from that memory dump and basically,
get back the private key.
So Heartbleed.
Another vulnerability you might see again.
Another vulnerability we'll come across
is something like shellshock.
Shellshock is a vulnerability in something called GNU/Bash.
It's a shell interpreter.
And the original CVE for this was CVE-2014-6271.
However, there were numerous variants for the shellshock
attack, because it was then finally patched
in version of Bash 43-027.
And these variants of the CVEs basically
allowed it to do the same thing.
But it was a command injection type of vulnerability.
So if you were to do nx equals and then supply this string,
it would actually cause the command
echo vulnerable to be run.
And what you wouldn't expect is for that to happen,
because nx equals is actually a variable assignment.
So you're doing x equals 1, 2, 3.
That wouldn't necessarily mean that it's going
to run the commands 1, 2, 3.
It's doing an assignment.
So because this vulnerability happened
when you were assigning variables that caused command
execution, it resulted in a command injection vulnerability
known as shellshock.
And it's possible to trigger this on web servers
when Bash is being used with the Common Gateway Interface.
So you can also use this attack against that.
It's not the only way in which shellshock manifests itself.
It can be found in FTP services.
It can be found all throughout anywhere
that uses Bash as a command interpreter.
But this is just a very common way that it's found,
is in CGI scripts.
And indeed, I've found, and Hacker House
has published exploits against, Trend Micro, where
they had shellshock vulnerabilities in some
of their security appliances.
So you do see it in things like that.
Security appliances, embedded devices.
You do see it out there and in the wild.
So a good one to check for.
Another one.
ImageTragick.
ImageTragick was another command injection vulnerability
in the ImageMagick library.
And this one just essentially meant
that if you tried to convert images in something like PHP,
you could cause commands to be run by having malicious input
inside of those images.
And we'll look at ImageTragick in a real world vulnerability
context and see how to exploit it in a real situation.
Equally, when you hack a web server
and you get onto a server, unlike the mail server module,
it's not likely you're just going to be root.
You're not just going to get in and breach it and suddenly
be root straightaway.
You're going to likely need to escalate your privileges
by doing something called Privilege Escalation Attack,
because often the web server is not
running with root privileges.
So you will need to obtain, or you will want
to elevate privileges, to root.
So you can do that through vulnerabilities
or misconfigurations in the server that you could exploit.
And sometimes it's really simple tricks like sudo su
will work and allow you to gain elevated privileges.
So it's important to check for vulnerabilities
and misconfigurations in servers that could
be exploited by an adversary.
Things like sudo su.
You.
And again, you'll need to maybe use a Privilege Escalation
Attack or an exploit.
One such exploit you might come across
is not a derogatory term, dirty cow,
but instead a Dirty COW as in a COW
which appears to have been covered in some kind of paint.
And this is a copy-on-write race condition in the Linux kernel.
And the Dirty COW exploit was added in Linux kernel 2.6.22
when it was released in 2007.
And up until its discovery in 2016,
it was present in most kernels released after that date.
And there's a number of public exploits available for this.
And it works as a race condition that
allowed you to overwrite privileged binaries
or privileged memory, and effectively gain
root permissions on the server.
So that's Dirty COW.
CVE-201605195.
So that concludes the Hacker House theory for this module.
And what we're going to do now is,
we're going to go into the practical for this session
and begin doing these various attacks
and making use of some of these tools.
So I'll look forward to seeing you in the practical.
You'll need to download our ISO modules from the website.
So make sure you've got the hh-webserver V1.
And make sure you've got your resource guide ready.
And then we'll proceed and go through the practical elements
of this module.