The world of web application hacking is an enormous one, and also one that is constantly changing. Just how well does your IDS fare against it?
For many of us the world of web application hacking is pretty much
viewed as the Wild West. There is always something new and unexpected
happening. Be it the latest cross site scripting
(XSS) exploit, or a new encoding technique to bypass a network’s
defenses. With this constantly shifting environment it makes sense to
try and gain a grasp on what some of the fundamental problems are. After
all, this is vitally important knowledge for the system administrators
(sys admins) out there, as well as the network security people. You are
the people who will be administering and watching your network for
anomalous behavior. While it is difficult to gain expertise across the
whole realm of web app hacking you can certainly get a good grasp of
some of its domains. The one domain that we shall cover at a high level
in this article series is that of encoding.
What is encoding?
What is meant by encoding is the process by which information is taken from one format and then encoded
to another one. Take for example all of the words written so far in
this article. They are in plain ASCII format. What would then happen
were I to take them and encode them to a HEX based format? The exact
meaning of the wording would still be there, but they would now be in a
HEX format. Let’s do a quick example of this.
Figure 1
Now we can see in the screenshot that on the left hand side we have a
series of HEX values, whilst on the right we have the ASCII version of a
couple of sentences that I just wrote. They both say the same thing,
but are in different formats. So we can see that it really is pretty
trivial to take something and encode it to a different format.
Well with that example providing a visual display for us, how would one
actually encode a real web application hack, and what would it look
like? Good question, let’s go ahead and find out just that. What we
shall use as our example is the by now classic Directory Traversal
exploit. Much as you likely guessed by the two words themselves, what
this exploit will allow you to do is navigate to the parent directory of
a website, as typically this is used against websites. Let’s get to it
then.
Our analysis environment
The tools and programs that I will use to show some web application hacking, and possible detection are as follows:
- Snort
- Web browser
- Encoding tool
As you can see there is not a whole lot required in order to
successfully do some web application hacking, and detection of it, if
possible. You could also use an HTTP proxy in addition to a web browser.
Whatever your preference. Were I doing this for a client engagement
then I would be using the BURP HTTP proxyearlier articles.
Now what we shall do is start up Snort so that it is listening and
watching the packets as they arrive to the computer where I have the Apache webserver running. suite. Should you need some help in installing some of these tools please check some of my
Figure 2
You can see in the screenshot that I have invoked Snort and specified via the –i 2
switches which interface for it to listen on. This is because I am
running Snort and the Apache webserver in a VMware image. As such there
will be multiple NIC’s for Snort. We must tell Snort which one it will
be monitoring for us. Now we will see in the next screenshot a very
basic example of web application hacking, and as mentioned earlier it is
the Directory Traversal exploit.
Figure 3
So the Apache webserver is up and running. Let’s now give it the
Directory Traversal input in its original format and see what happens.
Before you do this please ensure that you have Snort running in order to
see what if anything that it detects prior to attempting the hack.
Figure 4
We see in the screenshot the ../ which is what a
Directory Traversal attempt looks like. Once you send this to the Apache
webserver you will notice that it itself won’t do anything, it will
seem as if it ignores it. We will look at shortly what it is that Snort
detected. Now let’s go ahead and encode it in a different format.
Figure 5
What I have now done is encode the ../ to its HEX equivalent.
Figure 6
Now when you go ahead and send this HEX encoded Directory Traversal
exploit to the Apache web browser you will once again note that nothing
happens. Yet again we will check to see what Snort saw a little later
on. Let’s try it again this time but with the UNICODE encoding version
of it.
Figure 7
Now go ahead and enter this new encoded version of the Directory
Traversal and see what happens. You will note that Apache gives back an
HTTP 404 status code. In essence it says that the URL is not found on
the server. So we have tried three different versions of the Directory
Traversal exploit and none of them worked. So on that note, lets check
what Snort noted.
C:\Snort\etc\log>more alert.ids
[**] [119:18:1] (http_inspect) WEBROOT DIRECTORY TRAVERSAL [**]05/31-10:18:51.262616 0:17:31:8A:93:7F -> 0:C:29:BA:DC:9E type:0x800 len:0x1F4192.168.111.2:2780 -> 192.168.111.7:80 TCP TTL:128 TOS:0x0 ID:16806 IpLen:20 DgmLen:486 DF***AP*** Seq: 0x805DCAAC Ack: 0xF13CBB87 Win: 0xFFFF TcpLen: 20
C:\Snort\etc\log>
No problems for Snort
Well with the Snort signature for WEBROOT DIRECTORY TRAVERSAL having
fired we can ascertain that this old and tired web app hack was indeed
detected by Snort. This was done in spite of having encoded the original
../ attack in various other formats. Now as I mentioned earlier this
Directory Traversal hack is a well known one. There is little
possibility that this would evade any modern IDS out there. That said,
the world of web application hacking is an enormous one. There are
plenty of other types of hacks out there to be worried about.
Part of the problem when it comes to web application hacking is that
many of these applications have not been suitably pen-tested, or even
gone through a code audit. As such they can certainly be vulnerable to a
myriad of attacks. Some of which are ingenious and others which are
surprisingly low end. One of the simplest ways in which to bolster your
knowledge of web application hacks is that of trying to recreate them
yourself. Nothing helps one understand better then by doing it oneself.
Once you have brought yourself up to speed on say SQL injection, then
you may want to do some while the IDS is sniffing the traffic. This will
give you an idea of just well developed the IDS signatures are for the
SQL injection threat, or whatever other hack it is that you are
recreating. Should the signatures be weak or non-existent then you will
want to write some up yourself, as long as your IDS solution allows it.
Well this was a very quick and dirty overview of web app hacking, but
hopefully it will have stirred your curiosity. Till next time!