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.
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:
- 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 proxy suite. Should you need some help in installing some of these tools please check some of my earlier 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.
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.
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.
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.
What I have now done is encode the ../ to its HEX equivalent.
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.
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.
[**] [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:0x1F4
192.168.111.2:2780 -> 192.168.111.7:80 TCP TTL:128 TOS:0x0 ID:16806 IpLen:20 Dgm
***AP*** Seq: 0x805DCAAC Ack: 0xF13CBB87 Win: 0xFFFF TcpLen: 20
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!