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 2)
- SPIKE and BURP for real world computer security usage (Part 4)
Within the confines of this article we will use everything that I have written about, and apply it to a real world scenario. Specifically playing with a Firefox web browser field I thought might lead to some interesting results. Read on and follow along with me as I have some HTTP proxy fun!
SPIKE and the real world
I have written a fair amount recently over what HTTP proxies are, their uses, and specifically about the SPIKE HTTP proxy. Further to SPIKE, I will also write about the BURP suite in the near future to round out the HTTP proxy series. It is always good practice to try your web application hacking with a couple of different proxies as your results may vary. This is why I will devote an article to setting up and using the BURP suite. Well you will recall that using an HTTP proxy is all about testing web applications, and trying to circumvent security measures. Whether that be SQL injection due to poor server side filtering, or the bending of the HTTP protocol itself, an HTTP proxy will do it all.
It is always helpful I find to try and take lessons learned and if possible apply it to a real world scenario. Having just learned new theory, it should always be tested in as realistic an environment as possible. To that end we will wrap up our look at SPIKE with a true to life case of web application testing. To whit, last year I was doing some lab work when I just happened to notice what I thought was something rather odd in a Firefox web client request. Please see the below noted packet’s bolded and underlined portion.
10:35:36.275250 IP (tos 0x0, ttl 128, id 52101, offset 0, flags [DF], proto: TCP (6), length: 493) 192.168.1.100.2502 > 192.168.1.107.80: P, cksum 0x6d9b (correct), 468268059:468268512(453) ack 3224989207 win 65535
0x0000: 4500 01ed cb85 4000 8006 a965 c0a8 0164 E…..@….e…d
0x0010: c0a8 016b 09c6 0050 1be9 341b c039 6e17 …k…P..4..9n.
0x0020: 5018 ffff 6d9b 0000 4745 5420 2f20 4854 P…m…GET./.HT
0x0030: 5450 2f31 2e31 0d0a 486f 7374 3a20 3139 TP/1.1..Host:.19
0x0040: 322e 3136 382e 312e 3130 370d 0a55 7365 2.168.1.107..Use
0x0050: 722d 4167 656e 743a 204d 6f7a 696c 6c61 r-Agent:.Mozilla
0x0060: 2f34 2e30 2028 636f 6d70 6174 6962 6c65 /4.0.(compatible
0x0070: 3b20 4d53 4945 2035 2e30 3b20 5769 6e64 ;.MSIE.5.0;.Wind
0x0080: 6f77 7320 4e54 3b20 426f 6229 0d0a 4163 ows.NT;.Bob)..Ac
0x0090: 6365 7074 3a20 7465 7874 2f78 6d6c 2c61 cept:.text/xml,a
0x00a0: 7070 6c69 6361 7469 6f6e 2f78 6d6c 2c61 pplication/xml,a
0x00b0: 7070 6c69 6361 7469 6f6e 2f78 6874 6d6c pplication/xhtml
0x00c0: 2b78 6d6c 2c74 6578 742f 6874 6d6c 3b71 +xml,text/html;q
0x00d0: 3d30 2e39 2c74 6578 742f 706c 6169 6e3b =0.9,text/plain;
0x00e0: 713d 302e 382c 696d 6167 652f 706e 672c q=0.8,image/png,
0x00f0: 2a2f 2a3b 713d 302e 350d 0a41 6363 6570 */*;q=0.5..Accep
0x0100: 742d 4c61 6e67 7561 6765 3a20 656e 2d75 t-Language:.en-u
0x0110: 732c 656e 3b71 3d30 2e35 0d0a 4163 6365 s,en;q=0.5..Acce
I was lucky in that I was sniffing my own connection while doing some testing and noted the above highlighted portion. This was rather odd I thought as I had never really seen these “q=…….” values before. Well after a bit I was able to track down just what these things meant. It turns out that it was simply Firefox’s way of indicating the web client’s preference for specific mime types. The “q” was simply a weighted character between 0 and 1 which was used to show a preference for a specific mime type. For example a “q=0.9” would indicate that a specific mime type was the most preferred type. Conversely a “q=0.1” would indicate a least preferred mime type.
It’s all coming together now
Well I thought this way of communicating a mime preference to be pretty neat actually. I contacted a colleague of mine though who also did web application testing to bounce this new discovery off of. After our chat it was decided that some testing should be done. We both found it curious that the “q” value was a weighted one with values ranging from the aforementioned 0.1 to 0.9. What would happen if for instance one was to enter a rather large integer value, or for that matter a large negative integer into this HTTP web client field? A good question indeed we thought! With that in hand we decided to test it out on two web servers to gauge their response to some unexpected stimulus.
First up on my hit parade was the IIS 5 web server for testing. The installation of the IIS web server has been covered before by me, so I won’t go over it again. Right then, on with the HTTP proxy madness! Doing this kind of experimenting is very much what you should be trying to do. It allows you to test out various hacking tools, and also polishes up your networking protocol knowledge. You can see in the screenshot below the “q” values that Firefox sent to the IIS 5 web server.
Figure 1
What would happen were I to resend this to the IIS 5 web server with some very large integer values in as the “q” weight? To enter the large integer value you would simply click in the appropriate field as noted in the above screenshot and simply enter a long series of numbers. Let’s take a look at the IIS 5 web server side response when it received this unexpected field. Please view the packet capture below.
10:35:36.290875 IP (tos 0x0, ttl 128, id 140, offset 0, flags [DF], proto: TCP (6), length: 1464) 192.168.1.107.80 > 192.168.1.100.2502: P, cksum 0x6835 (correct), 3224989207:3224990631(1424) ack 468268512 win 63787
0x0000: 4500 05b8 008c 4000 8006 7094 c0a8 016b E…..@…p….k
0x0010: c0a8 0164 0050 09c6 c039 6e17 1be9 35e0 …d.P…9n…5.
0x0020: 5018 f92b 6835 0000 4854 5450 2f31 2e31 P..+h5..HTTP/1.1
0x0030: 2032 3030 204f 4b0d 0a53 6572 7665 723a .200.OK..Server:
0x0040: 204d 6963 726f 736f 6674 2d49 4953 2f35 .Microsoft-IIS/5
0x0050: 2e30 0d0a 4461 7465 3a20 5375 6e2c 2032 .0..Date:.Sun,.2
0x0060: 3620 4d61 7220 3230 3036 2031 353a 3335 6.Mar.2006.15:35
0x0070: 3a33 3520 474d 540d 0a43 6f6e 7465 6e74 :35.GMT..Content
0x0080: 2d4c 656e 6774 683a 2031 3237 300d 0a43 -Length:.1270..C
0x0090: 6f6e 7465 6e74 2d54 7970 653a 2074 6578 ontent-Type:.tex
0x00a0: 742f 6874 6d6c 0d0a 4361 6368 652d 636f t/html..Cache-co
Noted in the above packet is the “200” status code sent back by the web server. Due to this status code we know that the web server did not have an issue with parsing the large integer value from the Firefox web client. So we can see that IIS 5 will properly parse both normal input and abnormal input from a Firefox web client. Crap! I was hoping to have gotten something more interesting back from the web server. Perhaps even have caused a DoS (denial of service) condition.
Let’s try Apache now
Well I was a little disappointed with my lack of success at provoking some unexpected response from IIS 5. I did continue on for a while with various positive and negative integers with the same results. IIS 5 had no issues dealing with any of them. So I decided to next try this on Apache to see how it would handle some unusual input from Firefox. You can see in the screenshot below that I have entered a large integer value.
Figure 2
What happens when we resubmit this request with a now modified “q” field? Well let’s take a look at the packets below which will show both the packet being resent, and the Apache web servers response.
11:25:44.212750 IP (tos 0x0, ttl 128, id 59389, offset 0, flags [DF], proto: TCP (6), length: 388) 192.168.1.100.2859 > 192.168.1.104.80: P, cksum 0x12e1 (correct), 228302848:228303196(348) ack 892392516 win 65535
0x0000: 4500 0184 e7fd 4000 8006 8d59 c0a8 0164 E…..@….Y…d
0x0010: c0a8 0168 0b2b 0050 0d9b a000 3530 d444 …h.+.P….50.D
0x0020: 5018 ffff 12e1 0000 4745 5420 2f69 6d67 P…….GET./img
0x0030: 2f62 7269 646f 6e5f 6963 6f6e 2e70 6e67 /bridon_icon.png
0x0040: 2048 5454 502f 312e 310d 0a48 6f73 743a .HTTP/1.1..Host:
0x0050: 2031 3932 2e31 3638 2e31 2e31 3034 0d0a .192.168.1.104..
0x0060: 5573 6572 2d41 6765 6e74 3a20 4d6f 7a69 User-Agent:.Mozi
0x0070: 6c6c 612f 342e 3020 2863 6f6d 7061 7469 lla/4.0.(compati
0x0080: 626c 653b 204d 5349 4520 352e 303b 2057 ble;.MSIE.5.0;.W
0x0090: 696e 646f 7773 204e 543b 2042 6f62 290d indows.NT;.Bob).
0x00a0: 0a41 6363 6570 743a 2069 6d61 6765 2f70 .Accept:.image/p
0x00b0: 6e67 2c2a 2f2a 3b71 3d30 2e35 0d0a 4163 ng,*/*;q=0.5..Ac
0x00c0: 6365 7074 2d4c 616e 6775 6167 653a 2065 cept-Language:.e
0x00d0: 6e2d 7573 2c65 6e3b 713d 302e 350d 0a41 n-us,en;q=0.5..A
0x00e0: 6363 6570 742d 456e 636f 6469 6e67 3a20 ccept-Encoding:.
0x00f0: 677a 6970 2c20 6465 666c 6174 650d 0a41 gzip,.deflate..A
0x0100: 6363 6570 742d 4368 6172 7365 743a 2049 ccept-Charset:.I
0x0110: 534f 2d38 3835 392d 312c 7574 662d 383b SO-8859-1,utf-8;
0x0120: 713d 3131 3131 3131 3131 3131 3131 2e30 q=111111111111.0
0x0130: 2c2a 3b71 3d30 2e37 0d0a 4b65 6570 2d41 ,*;q=0.7..Keep-A
0x0140: 6c69 7665 3a20 3330 300d 0a43 6f6e 6e65 live:.300..Conne
0x0150: 6374 696f 6e3a 206b 6565 702d 616c 6976 ction:.keep-aliv
0x0160: 650d 0a2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d e..————-
0x0170: 2d2d 3a20 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d –:.————
0x0180: 0d0a 0d0a ….
We see in the above packet that the underlined and bolded part is our retransmission of the modified “q” weighted value. Let’s take a look below at the Apache web servers response to this.
11:25:44.212750 IP (tos 0x0, ttl 128, id 248, offset 0, flags [DF], proto: TCP (6), length: 910) 192.168.1.104.80 > 192.168.1.100.2859: P, cksum 0xb753 (correct), 892392516:892393386(870) ack 228303196 win 63892
0x0000: 4500 038e 00f8 4000 8006 7255 c0a8 0168 E…..@…rU…h
0x0010: c0a8 0164 0050 0b2b 3530 d444 0d9b a15c …d.P.+50.D…\
0x0020: 5018 f994 b753 0000 4854 5450 2f31 2e31 P….S..HTTP/1.1
0x0030: 2032 3030 204f 4b0d 0a44 6174 653a 2053 .200.OK..Date:.S
0x0040: 756e 2c20 3236 204d 6172 2032 3030 3620 un,.26.Mar.2006.
0x0050: 3136 3a32 343a 3336 2047 4d54 0d0a 5365 16:24:36.GMT..Se
0x0060: 7276 6572 3a20 4170 6163 6865 2f32 2e30 rver:.Apache/2.0
0x0070: 2e35 3420 2857 696e 3332 290d 0a4c 6173 .54.(Win32)..Las
0x0080: 742d 4d6f 6469 6669 6564 3a20 5361 742c t-Modified:.Sat,
0x0090: 2032 3020 4175 6720 3230 3035 2032 303a .20.Aug.2005.20:
0x00a0: 3235 3a35 3020 474d 540d 0a45 5461 673a 25:50.GMT..ETag:
0x00b0: 2022 3232 3239 2d32 3439 2d34 3039 3636 .”2229-249-40966
0x00c0: 3163 6422 0d0a 4163 6365 7074 2d52 616e 1cd”..Accept-Ran
0x00d0: 6765 733a 2062 7974 6573 0d0a 436f 6e74 ges:.bytes..Cont
0x00e0: 656e 742d 4c65 6e67 7468 3a20 3538 350d ent-Length:.585.
0x00f0: 0a4b 6565 702d 416c 6976 653a 2074 696d .Keep-Alive:.tim
0x0100: 656f 7574 3d31 352c 206d 6178 3d31 3030 eout=15,.max=100
0x0110: 0d0a 436f 6e6e 6563 7469 6f6e 3a20 4b65 ..Connection:.Ke
0x0120: 6570 2d41 6c69 7665 0d0a 436f 6e74 656e ep-Alive..Conten
0x0130: 742d 5479 7065 3a20 696d 6167 652f 706e t-Type:.image/pn
0x0140: 670d 0a0d 0a89 504e 470d 0a1a 0a00 0000 g…..PNG…….
0x0150: 0d49 4844 5200 0000 1000 0000 1008
Crap! Once again the web server was not affected by the unexpected stimulus. This is evidenced by the once again bolded and underlined portion in the packet above. By issuing the HTTP 200 status code, the web server is telling us that it had no problem in handling the web client request.
Wrapup
We have seen how we can use the SPIKE HTTP proxy in the real world. This true to life example is but just one use that such a tool as an HTTP proxy can do for you. It will allow you to do a great deal of web application testing, and all in a relatively intuitive setting ie: the SPIKE GUI (graphical user interface). Now that you have seen how easily one can go about testing such things as web servers, you can graduate and move onto such things as SQL injection amongst other fun. The HTTP proxy is a very powerful tool, and especially so in the hands of one who knows their protocols. I sincerely hope you enjoyed this article, and as always welcome your feedback. Till next time!
If you would like to read the other parts in this article series please go to:
