If you would like to read the other parts in this article series please go to:
- SPIKE and BURP for real world computer security usage (Part 1)
- SPIKE and BURP for real world computer security usage (Part 3)
- SPIKE and BURP for real world computer security usage (Part 4)
In part one of this series on usage of HTTP proxies we covered some relevant background material like why they are useful, and the need to have a packet sniffer running. What we shall now do in this part is actually use an HTTP proxy. Read on to find out more on how you can use this very useful tool.
HTTP Proxies Part II
Right then! We have covered the relevant background material in part one, and it is now time to get web app hacking. A quick word on my lab setup first that is used here. I have an Apache web server with a scaled down version of my website on it, and no special hardening done to Apache. There is also the SPIKE HTTP proxy running on Windows XP, and these are all running within VMware. With that said I fire up SPIKE itself by navigating to its directory and inputting the “runme.bat” batch file. Once that is done I now enter the IP address of the Apache web server in the URL bar and up the site comes as seen below.
Figure 1
Don’t forget that you needed to do a few changes to your web client before invoking SPIKE. This was covered in part one in case you forgot to do it. Now that you have the website displayed in your browser as seen in the screenshot above we can view SPIKE. This is done by inputting the following in the URL bar, http://SPIKE/ Please see the below noted screenshot for what you should be seeing.
Figure 2
I came across what may be a SPIKE bug when I was writing this article at this point. The older sites that I have checked with the SPIKE proxy were still residing in the UI (user interface) memory. This was after I had run the “cleanup.bat” file that was supposed to flush this old stuff out. Anyhow if you want to have a nice clean interface like the one seen in the above noted screenshot just surf to the below noted path;
c:\SPIKEProxy\spkproxy\spikeProxyUI>
Once there simply delete the directories by hand as such;
rmdir /S /Q dir_to_be_ deleted
It turns out this was not a bug, but rather a feature so that you could do some offline analysis should you choose too. Once the above is done you will have a clean slate to work with. This is much easier as you will not get confused by old data that you may have worked on before. Alright then let’s get back to using SPIKE. Referring back to the screenshot above we will now go and click on the “Delve into Dir” hyperlink. Once you have done so you will notice three directories listed there. Those are the directories that SPIKE parsed when it received the web site page. Let’s now take a look at the “img” directory via the same hyperlink used earlier ie: “Delve into Dir”. You have probably noticed already that we are now burrowing our way deeper into the data that we received once we accessed the web site on the Apache web server.
Getting to the nitty gritty
Once you have clicked on the “img” directory link you will see two gif files and one jpeg. Now go ahead and click on the very top one ie: bg3.gif via the “Delve into Dir” once again. Now that you have done that you are presented with some other options.
Figure 3
Now it is at this time that you will notice what I would consider the core of an HTTP proxy like this one. You now have the ability to rewrite requests and reissue them. First things first though. Let’s now click on the “Print Request Info” and take a look at what our browser sent when it connected to the web server to get the homepage there.
Figure 4
From the above noted screenshot we can now see exactly what was sent from the web client to the web server. From the top we have the web servers IP address and its port number. There is no SSL offered, and this is followed by the actual HTTP GET request and what was requested. In this example is the “bg3.gif” and after it the Host IP address. Following that is the User-Agent string which identifies the web client browser type. The rest is fairly self-evident. Should you not be sure of what you are seeing then I would suggest you read up on HTTP here. There is one thing of interest I will draw your attention to here. That is the “If-None-Match” field seen in the above noted screenshot.
There is a series of numbers and letters assigned to this value. This value is what is known as the ETag and has to do with caching. This ETag value is generated by the server and is applied to resources on it such as gif’s and the such. That way if a browser such as mine requests something, it may discover that it already has a cached version of it. I did indeed have a version of this gif which is why the web server responded with a HTTP status code of 304 Not Modified. That means that the gif I have is still the same as the one presently on the web server and that the web server need not send another one as it can be accessed via the cache on my local computer. You would see the below noted information in the DOS prompt that ran the “runme.bat” in to start up SPIKE.
Response Header:
HTTP/1.1 304 Not Modified
Date: Sun, 19 Feb 2006 16:39:55 GMT
Server: Apache/2.0.54 (Win32)
Connection: Keep-Alive
Keep-Alive: timeout=15, max=98
ETag: “222a-ab-4096dbdf”
Now back browse all the way back to where you were presented with the three various directories of “img”, “css”, and “_directory_”. From there click on the “Delve into Dir” for the “_directory_”. Then click “Print Request Info” and see what is there. It is a standard request for the page itself. Now let’s check out the “rewrite request” hyperlink. This, as mentioned earlier, is one of the core components of an HTTP proxy. Via this you can modify almost every part of the original request to the web server.
Figure 5
Now I went in and made a simple modification to the GET request that was viewable by going to the following from the screenshot below.
Figure 6
From there click on “Delve into Dir” and then to “Rewrite Request”. Once there change the “GET” to “HEAD” in the “Verb” section. Now go on down to the “Body args” section and enter “having some fun”. Once done simply hit “Submit Query”. You will note in the tcpdump output below that the SPIKE HTTP proxy did indeed rewrite the request to our specifications. Excellent! You are now on your way to the wonderful world of web application security. We will break the article at this point.
13:38:29.828125 IP (tos 0x0, ttl 128, id 6305, offset 0, flags [DF], proto: TCP
(6), length: 362) 192.168.1.108.1610 > 192.168.1.104.80: P, cksum 0xe1af (correct), 2856622211:2856622533(322) ack 3348334422 win 64240
0x0000: 4500 016a 18a1 4000 8006 5cc8 c0a8 016c E..j..@…\….l
0x0010: c0a8 0168 064a 0050 aa44 9883 c793 8756 …h.J.P.D…..V
0x0020: 5018 faf0 e1af 0000 4845 4144 202f 2048 P…….HEAD./.H
0x0030: 5454 502f 312e 310d 0a48 6f73 743a 2031 TTP/1.1..Host:.1
0x0040: 3932 2e31 3638 2e31 2e31 3034 0d0a 5573 92.168.1.104..Us
0x0050: 6572 2d41 6765 6e74 3a20 4d6f 7a69 6c6c er-Agent:.Mozill
0x0060: 612f 342e 3020 2863 6f6d 7061 7469 626c a/4.0.(compatibl
0x0070: 653b 204d 5349 4520 352e 303b 2057 696e e;.MSIE.5.0;.Win
0x0080: 646f 7773 204e 543b 2042 6f62 290d 0a41 dows.NT;.Bob)..A
0x0090: 6363 6570 743a 2069 6d61 6765 2f67 6966 ccept:.image/gif
0x00a0: 2c20 696d 6167 652f 782d 7862 6974 6d61 ,.image/x-xbitma
0x00b0: 702c 2069 6d61 6765 2f6a 7065 672c 2069 p,.image/jpeg,.i
0x00c0: 6d61 6765 2f70 6a70 6567 2c20 2a2f 2a0d mage/pjpeg,.*/*.
0x00d0: 0a41 6363 6570 742d 4c61 6e67 7561 6765 .Accept-Language
0x00e0: 3a20 656e 2d75 730d 0a43 6f6e 6e65 6374 :.en-us..Connect
0x00f0: 696f 6e3a 204b 6565 702d 416c 6976 650d ion:.Keep-Alive.
0x0100: 0a49 662d 4d6f 6469 6669 6564 2d53 696e .If-Modified-Sin
0x0110: 6365 3a20 5361 742c 2032 3020 4175 6720 ce:.Sat,.20.Aug.
0x0120: 3230 3035 2032 303a 3235 3a35 3020 474d 2005.20:25:50.GM
0x0130: 540d 0a49 662d 4e6f 6e65 2d4d 6174 6368 T..If-None-Match
0x0140: 3a20 0d0a 436f 6e74 656e 742d 4c65 6e67 :…Content-Leng
0x0150: 7468 3a20 3136 0d0a 0d0a 6861 7669 6e67 th:.16….having
0x0160: 2b73 6f6d 652b 6675 6e3d +some+fun=
There will be several future articles on the use of SPIKE and BURP. In them I will highlight a real world example of using these HTTP proxies to try some web application hacking. I look forward to seeing you then. Remember, I always welcome feedback. Till next time!
If you would like to read the other parts in this article series please go to:
