This is the third set of hints to the tshark decode challenge I issued last week. You can grab a copy of the decode file from the challenge page.
In my last post we spotted some discrepancies is the TCP stream. Let’s take a closer look at the payload to see if anything looks out of place. The command I’ll be using is:
tshark -r challenge1.cap -x | less
If you are running on Windows, replace the “less” command with the “more” command.
The “-x” switch will cause tshark to print the payload of each packet along with the header summary. If you page down to packet 4 you should see:
4 0.030787 148.78.247.10 -> 12.33.247.4 HTTP GET /cfide/Administrator/startstop.html HTTP/1.0
0000 00 b0 d0 20 7d e3 00 50 8b ea 20 ab 08 00 45 00 … }..P.. …E.
0010 01 11 2a 96 00 00 31 06 cf d2 94 4e f7 0a 0c 21 ..*…1….N…!
0020 f7 04 69 2a 00 50 6a 97 b8 6f 3a 88 39 cd 80 18 ..i*.Pj..o:.9…
0030 ff ff 42 fc 00 00 01 01 08 0a 00 ec 48 4b 3d 76 ..B………HK=v
0040 0e 8b 47 45 54 20 2f 63 66 69 64 65 2f 41 64 6d ..GET /cfide/Adm
0050 69 6e 69 73 74 72 61 74 6f 72 2f 73 74 61 72 74 inistrator/start
0060 73 74 6f 70 2e 68 74 6d 6c 20 48 54 54 50 2f 31 stop.html HTTP/1
0070 2e 30 0d 0a 48 6f 73 74 3a 20 31 32 2e 33 33 2e .0..Host: 12.33.
0080 32 34 37 2e 34 0d 0a 55 73 65 72 2d 41 67 65 6e 247.4..User-Agen
0090 74 3a 20 4d 6f 7a 69 6c 6c 61 2f 35 2e 30 20 5b t: Mozilla/5.0 [
00a0 65 6e 5d 20 28 57 69 6e 39 35 3b 20 55 29 0d 0a en] (Win95; U)..
00b0 52 65 66 65 72 65 72 3a 20 68 74 74 70 3a 2f 2f Referer: http://
00c0 31 32 2e 33 33 2e 32 34 37 2e 34 2f 0d 0a 58 2d 12.33.247.4/..X-
00d0 46 6f 72 77 61 72 64 65 64 2d 46 6f 72 3a 20 31 Forwarded-For: 1
00e0 34 38 2e 36 34 2e 31 34 37 2e 31 36 38 0d 0a 43 48.64.147.168..C
00f0 61 63 68 65 2d 43 6f 6e 74 72 6f 6c 3a 20 6d 61 ache-Control: ma
0100 78 2d 73 74 61 6c 65 3d 30 0d 0a 50 72 61 67 6d x-stale=0..Pragm
0110 61 3a 20 6e 6f 2d 63 61 63 68 65 0d 0a 0d 0a ce a: no-cache…..
0120 f8 43 76 .Cv
This is the “GET” request for the suspicious file name. There are a couple of fields in this payload that do not look right. The “HOST:” field should identify which Web server the client was attempting to access. This should always be a fully qualified domain name, like “www.fubar.com” or similar. The fact that the server’s IP address is listed tells me a Web browser was not used to generate this session.
It is possible to host multiple Web sites on the same physical server. The server figures out which specific site you want to access by analyzing this host field. If Web browsers didn’t follow this rule, co-location servers with multiple sites hosted on the same physical box would never work. So this tells me the client is going after the actual Web server process, not a Web site hosted on the system.
The “User-Agent:” field looks odd as well. While it is possible the client is still running Windows 95, it is unlikely.
The referer field is incorrect as well. This should show us the full URI the client was accessing when they were directed to this page. It should include the fully qualified domain name, as well as the exact page on the site that referred them to this page. In fact if the referer is a search engine, the field will also include what search parameters were used when they were directed to our site. Listing an IP address is completely incorrect.
There is one last interesting piece of information in this payload. The “X-Forwarded-For:” field tells us that the source IP address in the IP header is acting as an HTTP proxy for whatever IP address is listed in this field. It is not uncommon for attackers to bounce their attacks off of a public proxy server. This way if you detect the attack in your Web server access log, you will think the source IP address is the hostile entity as the X-Forwarded-For field will not be listed.
So we have a suspect file request, from an IP that is trying to hide their identity, using packets that have suspicious values. We don’t need a IDS to tell us this is probably an attacker looking for a known to be vulnerable file.
Now take a look at packets 8 through 17. Each one is the server attempting to tell the client “I’m sorry, I’m not running that vulnerable file. Please try a different vulnerable file if you want to compromise me”, via 404 error messages.
So the flow goes something like this:
- Client sends a probe for a potentially vulnerable file
- Server resets the connection
- Client resets the connection
- Server continually tells the client it does not have that file
So why the resets and why did the server ignore them? Tune in tomorrow to find out…
Related posts:
