Posts Tagged ‘Packet Decoding’

« Older Entries
Newer Entries »

Tshark Challenge – Uber-geek Answer

October 13th, 2009

In my last post I left you with a question: Given what we have seen in the decode file with tshark, what impact (if any) would there be if we place a stateful inspection firewall between the attacker and the Web server? In other words, if the attacker is running a packet sniffer, would they still see the Web server leaking out 404 errors?

And the answer is…

Maybe. :)

Not all stateful inspection firewalls are equal. Some handle packets slightly differently than others. For example some (like Checkpoint, Netscreen and others) let non-SYN packets to permit rules generate new state table entries. Some (Cisco, Netfilter and others) will only generate a state table with proper session establishment (must see TCP three packet handshake).

The NIPS sent a valid reset packet to the attacker on the Internet. Each of the above firewalls would see the reset packet and remove it’s entry from the state table. When the Web server continued to communicate however, only the first set of firewalls would let the packets leak out to the attacker. The second set of firewalls would simply drop the traffic. In fact if we set them up with a deny rule instead of a drop rule, they would kill the session on the Web server thus fixing the problem created by the NIPS.

Why do some vendors let acknowledgement packets generate new state table entries? This seems a bit counterintuitive as a legitimate session is always going to start with a SYN packet. There are two reasons this makes good functional sense:

  • Updating the firewall rules does not kill active sessions
  • Active-active setup will pass traffic prior to state table sync

Of course we’ve increased functionality at the cost of security. Unfortunately that is the typical trade off.

Hope you had fun with this challenge. If there is interest I will post more in the future.

2 comments »

Posted in 2-alert, Network Security, Packet Decoding

Tags:

Tshark Challenge – The Final Answers

October 9th, 2009

In my last post we had determined that the trace file contained a session where a single honed network based intrusion prevention system had attempted to stop an attack from an HTTP client to a Web server. We concluded that the client’s data request did look rather suspicious, and proved a third party system (the NIPS) was responsible for the reset packets transmitted during the session.

In this post we still need to answer two questions:

  1. Was the attack successful?
  2. Why did the Web server ignore the TCP reset packet transmitted by the NIPS?

Was the attack successful?

The attacker was looking to identify if the file “startstop.html” was located in the “Administrator” directory. Let’s take a look at one of the packets sent to the attacker after the reset packets were transmitted:

tshark -n -r challenge1.cap -x frame.number==11

11   0.711825  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

0000  00 50 8b ea 20 ab 00 b0 d0 20 7d e3 08 00 45 00   .P.. …. }…E.

0010  01 a7 37 47 40 00 40 06 73 8b 0c 21 f7 04 94 4e   ..7G@.@.s..!…N

0020  f7 0a 00 50 69 2a 3a 88 39 cd 6a 97 b9 4c 80 19   …Pi*:.9.j..L..

0030  19 20 8c d4 00 00 01 01 08 0a 3d 76 0e d3 00 ec   . ……..=v….

0040  48 4b 48 54 54 50 2f 31 2e 31 20 34 30 34 20 4e   HKHTTP/1.1 404 N

0050  6f 74 20 46 6f 75 6e 64 0d 0a 44 61 74 65 3a 20   ot Found..Date:

0060  54 75 65 2c 20 32 35 20 4a 75 6e 20 32 30 30 32   Tue, 25 Jun 2002

0070  20 30 30 3a 33 34 3a 35 38 20 47 4d 54 0d 0a 53    00:34:58 GMT..S

0080  65 72 76 65 72 3a 20 41 70 61 63 68 65 0d 0a 43   erver: Apache..C

0090  6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 6c 6f 73 65   onnection: close

00a0  0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20   ..Content-Type:

00b0  74 65 78 74 2f 68 74 6d 6c 3b 20 63 68 61 72 73   text/html; chars

00c0  65 74 3d 69 73 6f 2d 38 38 35 39 2d 31 0d 0a 0d   et=iso-8859-1…

00d0  0a 3c 21 44 4f 43 54 59 50 45 20 48 54 4d 4c 20   .<!DOCTYPE HTML

00e0  50 55 42 4c 49 43 20 22 2d 2f 2f 49 45 54 46 2f   PUBLIC “-//IETF/

00f0  2f 44 54 44 20 48 54 4d 4c 20 32 2e 30 2f 2f 45   /DTD HTML 2.0//E

0100  4e 22 3e 0a 3c 48 54 4d 4c 3e 3c 48 45 41 44 3e   N”>.<HTML><HEAD>

0110  0a 3c 54 49 54 4c 45 3e 34 30 34 20 4e 6f 74 20   .<TITLE>404 Not

0120  46 6f 75 6e 64 3c 2f 54 49 54 4c 45 3e 0a 3c 2f   Found</TITLE>.</

0130  48 45 41 44 3e 3c 42 4f 44 59 3e 0a 3c 48 31 3e   HEAD><BODY>.<H1>

0140  4e 6f 74 20 46 6f 75 6e 64 3c 2f 48 31 3e 0a 54   Not Found</H1>.T

0150  68 65 20 72 65 71 75 65 73 74 65 64 20 55 52 4c   he requested URL

0160  20 2f 63 66 69 64 65 2f 41 64 6d 69 6e 69 73 74    /cfide/Administ

0170  72 61 74 6f 72 2f 73 74 61 72 74 73 74 6f 70 2e   rator/startstop.

0180  68 74 6d 6c 20 77 61 73 20 6e 6f 74 20 66 6f 75   html was not fou

0190  6e 64 20 6f 6e 20 74 68 69 73 20 73 65 72 76 65   nd on this serve

01a0  72 2e 3c 50 3e 0a 3c 2f 42 4f 44 59 3e 3c 2f 48   r.<P>.</BODY></H

01b0  54 4d 4c 3e 0a 00 03 00 07                             TML>…..

So the answer to the attacker’s question; “Is the file located on the server?, is answered in every packet the server set to the client after the reset packets were issued. Now the question becomes, did the attacker see this information?

When the reset packet was sent to the attacker, the reset should have killed the TCP session. This means that when this data arrived, the receiving port (TCP/26922) should have been in a closed state. Had this in fact been true, I would expect to see a reset/ACK coming back from the attacker’s system telling us that TCP/26922 is now closed. We never see those packets.

So why didn’t the remote port close? The reset packet is valid, so it should have killed the session. A savvy attacker is going to run a packet sniffer in the background while performing their attack. It is possible that the attacker would have figured out what was going on and simply created a firewall rule on their attack system filtering out all inbound reset packets. This would have permitted their tool to continue functioning. Even without the firewall filter their packet sniffer would contain the answers they seek. So there is a very good chance the attacker has figured out what we are vulnerable to, despite the fact a NIPS is protecting the network.

Why did the Web server ignore the reset packet?

Our final question is why did the Web server ignore the reset packet sent by the NIPS. This is causing two problems:

  • The info the attacker wanted is continuing to leak out
  • If the attacker does multiple file probes, they could fill up the session table on the Web server

The second item is kind of scary because it would actually be the NIPS causing the DoS attack by only killing one side of the connection properly. So even if we were patched and up to date, vendor gear we paid money for would end up killing our Web server. Gee I hate it when I spend money to DoS myself. ;)

Let’s take another look at those reset packets:

tshark -n -r challenge1.cap frame.number==6 or frame.number==7

6   0.031319  12.33.247.4 -> 148.78.247.10 TCP 80 > 26922 [RST, ACK] Seq=1 Ack=222 Win=0 Len=0

7   0.031385 148.78.247.10 -> 12.33.247.4  TCP [TCP ACKed lost segment] 26922 > 80 [RST, ACK] Seq=1 Ack=222 Win=0 Len=0

Notice that tshark is telling us packet 7 is a lost segment. In other words, tshark is telling us that the TCP sequence number is not within the window the host is expecting. A look at the sequence and acknowledge numbers explains why. The values are identical to the ones in packet 6. You may remember from the last post that packet 6 and 7 also had the same IP ID value (45298).

So it appears that here is what happened:

  • Client sent an HTTP attack to our Web server
  • NIPS detected the attack
  • NIPS sent a valid TCP reset to the attacker to kill the session
  • NIPS swapped the source and destination IP addresses in the packet, recalculated the CRCs, and then sent the same reset to the Web server
  • Web server ignores the reset because it does not contain an acceptable sequence number

You may be asking yourself, “How did the vendor miss this?”. My best guess is that the vendor ran some simulated attacks; the attack tool did not show them vulnerable files, so they assumed everything was working OK. In other words, a vendor who created a product to protect networks on the wire never bothered to look at what their product was actually doing on the wire. Hummm…

Bonus question

OK, if you are having fun with this one, here’s a bonus question to answer that will definitively prove your uber-geek status upon the top of the secret pyramid:

Assume we place a stateful inspection firewall between this subnet and the attacker. Will the attacker still be able to see the answers with a packet sniffer?

I’ll post the answer next week.

No comments »

Posted in 2-alert, Packet Decoding

Tags:

Tshark Challenge – Hints 4

October 8th, 2009

In my last post we identified that the client system was probably running some kind of tool to probe for known to be vulnerable files. We still have to explain the reset packets however, as well as why the server was ignoring them.

Right now we don’t even know where this packet capture was taken in relation to the two end points. I’m going to run tshark using the “-T fields” switch to print out the TTL information. By analyzing the TTLs, we should be able to determine where we are sniffing in relationship to the client and the server. I’m also going to print out the IP IDs to see if there are any abnormalities in the packet order.

Here’s the command and output:

tshark -r challenge1.cap -T fields -e frame.number -e ip.src -e tcp.srcport -e ip.ttl -e ip.id

1       148.78.247.10   26922   49      0x2a6b

2       12.33.247.4     80      64      0×0000

3       148.78.247.10   26922   49      0x2a95

4       148.78.247.10   26922   49      0x2a96

5       12.33.247.4     80      64      0×3743

6       12.33.247.4     80      255     0xb0f2

7       148.78.247.10   26922   255     0xb0f2

8       12.33.247.4     80      64      0×3744

9       12.33.247.4     80      64      0×3745

10      12.33.247.4     80      64      0×3746

11      12.33.247.4     80      64      0×3747

12      12.33.247.4     80      64      0×3748

13      12.33.247.4     80      64      0×3749

14      12.33.247.4     80      64      0x374a

15      12.33.247.4     80      64      0x374b

16      12.33.247.4     80      64      0x374c

17      12.33.247.4     80      64      0x374d

148.78.247.10 is the client. We know that because it initiated the session and its communicating using an upper source port. 12.33.247.10 is our HTTP server communicating from port 80.

In packet 1 we see the client has a TTL of 49. The closest starting TTL match for a known operating system is 64, so this tells us the client is a Linux, UNIX, or Mac system sitting 15 hops away. In packet 2 we see the server with a TTL value of 64, so it must be one of the previously mentioned operating systems sitting on the local network. So, we are on the same collision domain as the server, but sitting 15 hops away from the client.

There is a problem however. Look at packets 6 and 7. Here we see the TTL of both systems changing to 255. An OS will never change it’s TTL during a session, so this looks extremely suspect. Further, we already determined that the client is sitting 15 hops away from us. 255 is the largest possible TTL value as the TTL field is only a single byte (byte 8 in the IP header). So even though the source IP address claims to be the remote client, there is no way that packet could have originated anywhere but from the local network. If the packet had crossed one or more routers, the TTL value would be lower.

The IP ID information does not look right either. In the first three packets from the client we see the IP ID values 0x2a6b (10859), 0x2a95 (10901), and 0x2a96 (10902). This tells us the client is possibly using a +1 incremental IP ID, we just didn’t see 42 of the packets between the first and second packet transmitted. The next IP ID we see from the client is 0xb0f2 (45298). OK, unless we missed over 34,000 packets, this IP ID does not jive.

Note the above analysis would only be theoretical were it not for the inconsistent TTL values. With only three packets to look at, we cannot precisely identify the IP ID increment. It is also possible, but very highly unlikely, that the IP ID increment is completely random and the system just happened to assign two incremental IP IDs, one right after the other. Still, combine the TTL and IP ID information together and they indicate that this final packet could not have originated from the same system.

We have more IP ID data from the server to work with, so let’s take a look at that. The IDs are:

  • 0 (0)
  • 0×3743 (14147)
  • 0xb0f2 (45298)
  • 0×3744 (14148)
  • 0×3745 (14149)
  • 0×3746 (14150)
  • 0×3747 (14151)
  • 0×3748 (14152)
  • 0×3749 (14153)
  • 0x374a (14154)
  • 0x374b (14155)
  • 0x374c (14156)
  • 0x374d (14157)

Take a look at the third listed IP ID, which is from packet 6 in the trace. Note that all of the other IP IDs are incremental +1, but this IP ID does not belong. In fact we can show that the server increments it’s IP ID by +1 and that there is no way this packet originated from the server.

Humm. I wonder if these suspect packets line up with the strange resets we saw:

tshark -r challenge1.cap -T fields -e frame.number -e ip.src -e tcp.srcport -e ip.ttl -e ip.id -e tcp.flags.reset

1       148.78.247.10   26922   49      0x2a6b  0

2       12.33.247.4     80      64      0×0000  0

3       148.78.247.10   26922   49      0x2a95  0

4       148.78.247.10   26922   49      0x2a96  0

5       12.33.247.4     80      64      0×3743  0

6       12.33.247.4     80      255     0xb0f2  1

7       148.78.247.10   26922   255     0xb0f2  1

8       12.33.247.4     80      64      0×3744  0

9       12.33.247.4     80      64      0×3745  0

10      12.33.247.4     80      64      0×3746  0

11      12.33.247.4     80      64      0×3747  0

12      12.33.247.4     80      64      0×3748  0

13      12.33.247.4     80      64      0×3749  0

14      12.33.247.4     80      64      0x374a  0

15      12.33.247.4     80      64      0x374b  0

16      12.33.247.4     80      64      0x374c  0

17      12.33.247.4     80      64      0x374d  0

Ah ha! So if we look at the packets with the strange TTL and IP ID values, these were the strange reset packets sent during the session.

It looks to me like some third system is jumping into the conversation in order to transmit the reset packets. Since these strange packets have a TTL of 255, we know it must be on the same collision domain as where we are sniffing. Since it is on the same collision domain, the Ethernet header information might be helpful:

tshark -r challenge1.cap -T fields -e frame.number -e eth -e tcp.flags.reset

1       Ethernet II, Src: HewlettP_ea:20:ab (00:50:8b:ea:20:ab), Dst: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3)     0

2       Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

3       Ethernet II, Src: HewlettP_ea:20:ab (00:50:8b:ea:20:ab), Dst: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3)     0

4       Ethernet II, Src: HewlettP_ea:20:ab (00:50:8b:ea:20:ab), Dst: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3)     0

5       Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

6       Ethernet II, Src: D-Link_8f:e0:0c (00:50:ba:8f:e0:0c), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)       1

7       Ethernet II, Src: D-Link_8f:e0:0c (00:50:ba:8f:e0:0c), Dst: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3)       1

8       Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

9       Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

10      Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

11      Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

12      Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

13      Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

14      Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

15      Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

16      Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

17      Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

So when the client comes in from the Internet, it passes through an HP system acting as either a router or a firewall. Our Web server is running on Dell hardware. Note our resets (packets 6 and 7) are both being generated by the same system using a D-Link NIC.

So why did the D-Link system try to kill the session? This occurred just after the client sent the suspicious file request. It looks to me like the D-Link system is actually a single honed intrusion prevention system (IPS). When an attack is detected, the IPS attempts to prevent the attack by transmitting reset packets to both ends of the connection.

But we still have some unanswered questions. Was the attack successful and why did the server appear to ignore the IPS’s attempt to kill the session?

Turn in to the next episode to find out.

No comments »

Posted in 2-alert, Packet Decoding

Tags:

Tshark Challenge – Hints 3

October 7th, 2009

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…

No comments »

Posted in 3-err, Packet Decoding

Tags:

Tshark Challenge – Hints2

October 6th, 2009

Yesterday we left off taking an initial look at the decode file. A first pass left us scratching our head because we saw a 404 error followed by multiple retransmissions. In this hint we’ll dig into the trace a little deeper.

Let’s go back to our initial decode and follow what happened packet by packet:

tshark -r challenge1.cap

1   0.000000 148.78.247.10 -> 12.33.247.4  TCP 26922 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=0 TSV=15485003 TSER=0

2   0.000080  12.33.247.4 -> 148.78.247.10 TCP http > 26922 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=1031147147 TSER=15485003 WS=0

3   0.029341 148.78.247.10 -> 12.33.247.4  TCP 26922 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0 TSV=15485003 TSER=1031147147

4   0.030787 148.78.247.10 -> 12.33.247.4  HTTP GET /cfide/Administrator/startstop.html HTTP/1.0

5   0.030841  12.33.247.4 -> 148.78.247.10 TCP http > 26922 [ACK] Seq=1 Ack=222 Win=6432 Len=0 TSV=1031147150 TSER=15485003

6   0.031319  12.33.247.4 -> 148.78.247.10 TCP http > 26922 [RST, ACK] Seq=1 Ack=222 Win=0 Len=0

7   0.031385 148.78.247.10 -> 12.33.247.4  TCP [TCP ACKed lost segment] 26922 > http [RST, ACK] Seq=1 Ack=222 Win=0 Len=0

8   0.031610  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

9   0.031664  12.33.247.4 -> 148.78.247.10 HTTP HTTP/1.1 404 Not Found  (text/html)

10   0.251838  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

11   0.711825  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

12   1.631812  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

13   3.471773  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

14   7.153143  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

15  14.511594  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

16  29.231324  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

17  58.670815  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

Our first three packets are the TCP handshake. This portion looks pretty normal. In packet 4, we see the client send a “GET” request for a file. This file request strikes me as suspicious. A file named “startstop.html” in the “Administrator” directory does not exactly sound like a file we would want to be serving up to the public at large. We’ll make a note of this and come back to it later.

In packet 5 we see the server acknowledge the data request. After this packet, things get a little odd. In packet 6, we see the server transmit a reset packet to kill the connection. This is an indication that the server feels something has gone wrong with the session and that it is unrecoverable. This is extremely odd behavior for TCP as it tries very hard to be reliable. It normally will transmit multiple attempts to reestablish a connection if it thinks something went wrong. You can see normal recovery behavior in packets 10 through 17, which more closely matches how TCP will attempt to maintain connectivity. There is a .5 ms difference in the timestamp between packets 5 and 6. A normal operating system would never determine in that short a period of time that the TCP session is unrecoverable.

In packet 7, things continue to act strangely. We see the client respond to the server’s reset packet with a reset packet of its own. This is certainly not normal IP behavior as the RFCs state you should never respond to an error packet. So during a normal session you would never see this type of error exchange. Something is obviously very wrong.

In packet 9, we see the server send a 404 error message. There are a couple of problems here. To start, the server already sent a reset indicating it considered the session to be unrecoverable. A system should never continue to send data after issuing a reset packet. In fact, the server continues to transmit all the way to packet 17. What makes this activity even stranger is that the client has issued a reset as well. So the server is not only ignoring the fact that it issued a reset, it is also ignoring the reset sent by the client.

So needless to say this is very strange TCP behavior. In my next post I’ll dig deeper into the payloads to get a better look at what is going on.

No comments »

Posted in 3-err, Packet Decoding

Tags:

Tshark Challenge – Hints1

October 5th, 2009

Last week I posted a Libpcap file and challenged you to figure out as much as you could about the trace using tshark. In this post I’ll start you through the process of analyzing the decode. I WIL NOT cover it completely. My goal here is to give a leg up to the folks who do not even know where to start. I’ll add more details as the week goes on.

Getting started

The first thing you should do is have a look at the contents of the file. I’ll use the –r switch to read in the contents of the file. This will override tshark’s default setting of sniffing on the first detected interface. Normally I would pipe the output through the “less” command (or “more” on Windows), but there are only 17 packets in the file.

tshark -r challenge1.cap

1   0.000000 148.78.247.10 -> 12.33.247.4  TCP 26922 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=0 TSV=15485003 TSER=0

2   0.000080  12.33.247.4 -> 148.78.247.10 TCP http > 26922 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=1031147147 TSER=15485003 WS=0

3   0.029341 148.78.247.10 -> 12.33.247.4  TCP 26922 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0 TSV=15485003 TSER=1031147147

4   0.030787 148.78.247.10 -> 12.33.247.4  HTTP GET /cfide/Administrator/startstop.html HTTP/1.0

5   0.030841  12.33.247.4 -> 148.78.247.10 TCP http > 26922 [ACK] Seq=1 Ack=222 Win=6432 Len=0 TSV=1031147150 TSER=15485003

6   0.031319  12.33.247.4 -> 148.78.247.10 TCP http > 26922 [RST, ACK] Seq=1 Ack=222 Win=0 Len=0

7   0.031385 148.78.247.10 -> 12.33.247.4  TCP [TCP ACKed lost segment] 26922 > http [RST, ACK] Seq=1 Ack=222 Win=0 Len=0

8   0.031610  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

9   0.031664  12.33.247.4 -> 148.78.247.10 HTTP HTTP/1.1 404 Not Found  (text/html)

10   0.251838  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

11   0.711825  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

12   1.631812  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

13   3.471773  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

14   7.153143  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

15  14.511594  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

16  29.231324  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

17  58.670815  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

Some details that immediately grab my attention:

  1. This is an HTTP session
  2. The connection attempted to access a file that does not exist (404 error in #9)
  3. There were communication issues with the session (#10-17 are retransmissions)

So right away this trace leaves me asking a few questions:

  1. What’s up with the request for a file that does not exist?
  2. Why are we having communication problems?

That’s it for now. Tomorrow I’ll post another hint.

No comments »

Posted in 3-err, Packet Decoding

Tags:

Tshark Decode Challenge

October 2nd, 2009

In my last post I covered tshark and discussed how to manipulate the output during a decode. There is no better way to learn than by doing, so I decided to post a challenge. In this post I’ll provide a Libpcap file. Your mission Mr. Phelps, should you choose to accept it, is to attempt to identify what is going on within the decode file using tshark.

Installing tshark

In order to install tshark, you need to install Wireshark. You can grab a current copy from the download page. Once you do, the installation process is dependent on what platform you are using:

Linux/UNIX

If you are running Fedora or Red Hat, you do not need to visit the download page. You can install Wireshark directly through Yum:

su –

yum –y install wireshark.i586

If you are running a UNIX flavor or some other Linux distro, you may need to grab the tar archive from the above link and compile Wireshark for your system. Pay close attention to the dependencies as there are a lot of them. Ensure that “./configure” completes successfully before building your binaries.

Windows

  1. Download the self-extracting executable
  2. Run the executable
  3. Accept Unknown Publisher screen by clicking “run” button
  4. Follow the on-screen prompts accepting the defaults
  5. Install WinPcap (make sure box is checked)
  6. Install NPF service if non-Administrator users will be running the tool
  7. Add “C:\Program Files\Wireshark” to the end of your path statement

OS X

  1. Select the image that matches your processor type (Intel or PPC)
  2. Open with DiskimageMounter
  3. Open the “Read me first.rtf”
  4. Follow the “Quick Setup” instructions

The challenge

Here’s the challenge file:

challenge1.cap

And here are the hashes of the file to verify your download:

MD5: ea92f08d9ba104c6cf7756564eb5aef9  challenge1.cap
SHA-1: 71041ab0f670c5b9558183a56fe1bb80e8b10506  challenge1.cap

Good luck and starting next week I’ll post a little more info about the file every day to help move you through the decode process.

No comments »

Posted in 3-err, Packet Decoding

Tags:

Analyzing packets with tshark

October 1st, 2009

In an earlier post I discussed how to adjust the display output in tshark. The post generated a lot of interest, so I decided to add some additional information on using tshark to decode packets. This post assumes you have read the one linked to above.

Why use tshark instead of tcpdump/windump?

Many old time decoders swear by tcpdump, and it’s Windows counterpart windump. Both are great tools, but they have become a little dated. While patches are still released from time to time, little has been done to update or expand their decode capability. Wireshark on the other hand, as well as it’s included tools such as tshark, include decode support for hundreds of protocols and the list is growing all of the time. While you can certainly analyze packets without the decoders, they make the process go far quicker.

Why use tshark instead of Wireshark?

Wireshark is a great tool when you are doing an in-depth payload analysis. It can be a little tedious however if you wish to follow a specific field over multiple packets. For example let’s say we wish to watch the TCP sequence number increment over multiple packets. With Wireshark, I would have to note the sequence number location in the middle pane and page through each packet. Since there is no way to line up the value over multiple packets, I’m forced to remember previous values when performing my calculations. With tshark however, we can do something like this:

tshark -n -T fields -e ip.src -e tcp.seq -e tcp.len

64.111.96.38    0        0

64.111.96.38    1        0

64.111.96.38    1        363

64.111.96.38    364     1448

64.111.96.38    1812    1448

64.111.96.38    3260    1448

64.111.96.38    4708    1448

64.111.96.38    6156    1448

64.111.96.38    7604    1448

64.111.96.38    10500   310

64.111.96.38    9052    1448

64.111.96.38    10810   0

Remember that the TCP sequence number (the second field) should increment based on the size of the payload (the third field). Note that packets 10 and 11 where received out of order. This could mean there are multiple paths available between our location and the identified IP address. While Wireshark would show us this information as well, in this view it is a bit easier to follow the flow.

More on displaying fields

As discussed in my earlier post, as well as shown above, the “-T” switch can be used to manipulate the output being displayed. You can choose from XML, Postscript or plain text. The most useful option is “fields” as it lets you pick and choose which specific fields you want printed out. As shown above, the “-e” switch can then be used to identify which fields you wish to display. The complete list of filters can be found here. A nice cheat sheet of the most commonly used values can be found here.

If you define a specific protocol, tshark will display some of the more important fields from that header. For example to look at only the Ethernet header:

tshark -T fields -e eth

Ethernet II, Src: TyanComp_56:3b:14 (00:e0:81:56:3b:14), Dst: Dell_d1:fe:ef (00:12:3f:d1:fe:ef)

Ethernet II, Src: TyanComp_56:3b:14 (00:e0:81:56:3b:14), Dst: Dell_d1:fe:ef (00:12:3f:d1:fe:ef)

Ethernet II, Src: TyanComp_56:3b:14 (00:e0:81:56:3b:14), Dst: Dell_d1:fe:ef (00:12:3f:d1:fe:ef)

Note the type and CRC fields are not displayed, as they are not as “interesting” as the source and destination MAC address. We would have to define these fields specifically (ip.type and ip.trailer) if we wish to see them.

One side effect of printing fields is that tshark will add a blank line for any packet that does not contain the specified field. This can be a pain when analyzing HTTP packets as not every packet will contain a URI. An easy way to clean this up is to pipe it through grep. For example:

tshark -T fields -e http.request.uri | grep -v “^$”

/

/styles.css

/templates/classic/images/starsnstripes.gif

/templates/classic/images/unionjack.gif

/templates/classic/images/amazon.header.gif

/c_images/2009/05/07/71090.2.jpg

In my last post I discussed grep as well as where to grab a free version for Windows. The above grep command uses the “-v” switch to match all lines that do not contain the specified value. “^$” defines a blank line. So the above grep command filters out all blank lines.

More display options

Tshark has a number of other useful display options. For example you can print headers at the beginning of the output:

tshark -n -T fields -e ip.src -e ip.dst -E header=y

ip.src  ip.dst

64.111.96.38    12.5.200.100

64.111.96.38    12.5.200.100

64.111.96.38    12.5.200.100

If you plan on importing the information into a spreadsheet or database, you can define which character to use between fields:

tshark -T fields -e ip.src -e ip.dst -e tcp.dstport -E header=y -E separator=;

ip.src;ip.dst;tcp.dstport

64.111.96.38;12.5.200.100;34831

64.111.96.38;12.5.200.100;34831

64.111.96.38;12.5.200.100;34831

Packet statistics

Tshark has solid statistical capability as well. If you need to process a lot of files, sometimes it is help to start with looking at the raw stats. The “-z” switch is used to specify the statistics you wish to analyze. Normally these will be printed at the end of the decode information, but if you use the “-q” switch only the stats will be printed. Here’s an example:

C:\testing>tshark -q -z http,stat, -z http,tree -r test.cap

===============================================================

HTTP/Packet Counter           value            rate         percent

——————————————————————-

Total HTTP Packets            64915       0.048999

HTTP Request Packets           459       0.000346           0.71%

GET                                       24       0.000018           5.23%

HEAD                                   433       0.000327          94.34%

OPTIONS                                 2       0.000002           0.44%

HTTP Response Packets          448       0.000338           0.69%

???: broken                            0       0.000000           0.00%

1xx: Informational                    0       0.000000           0.00%

2xx: Success                         12       0.000009           2.68%

200 OK                                12       0.000009         100.00%

3xx: Redirection                   0       0.000000           0.00%

4xx: Client Error                436       0.000329          97.32%

404 Not Found                  432       0.000326          99.08%

403 Forbidden                      4       0.000003           0.92%

5xx: Server Error                  0       0.000000           0.00%

Other HTTP Packets           64008       0.048314          98.60%

===============================================================

===============================================================

HTTP Statistics

* HTTP Status Codes in reply packets

HTTP 200 OK

HTTP 403 Forbidden

HTTP 404 Not Found

* List of HTTP Request methods

GET  24

OPTIONS  2

HEAD  433

===============================================================

A couple of things stick out in this output. First, we have four 403 errors indicating that someone was attempting to access something they did not have permission to. Also, out of 459 HTTP requests, 432 of them were for non-existent files. We are also seeing a lot of “HEAD” requests which could be a proxy, or could be an attacker attempting to keep from being logged to the Web server’s access log. Clearly this capture file includes some suspect traffic that warrants further investigation.

Tshark can even produce general throughput statistics if you need them. This is an excellent way to check for DoS attacks:

tshark -q -z io,stat,10 -r test.cap

===============================================================

IO Statistics

Interval: 10.000 secs

Column #0:

|   Column #0

Time            |frames|  bytes

000.000-010.000     254    145081

010.000-020.000     145     80003

020.000-030.000     125     65527

030.000-040.000       4       264

===============================================================

Note tshark will print the frame and byte count for any interval specified, defined in seconds. The only problem is that if you are capturing packets off of the wire, stats are not displayed until the capture ends.

Exec Summary

Tshark is an extremely capable packet analysis tool that has surpassed it’s counterparts tcpdump and windump. Combine the extensive decode capability along with the flexible output display, and tshark has become the tool of choice for many packet decoders.

No comments »

Posted in 2-alert, Network Security, Packet Decoding

Tags:

Passively Fingerprinting VMware Virtual Systems

September 15th, 2009

There have been some excellent papers written on how to detect if an operating system is running as a Vmware guest image. Automated tools have even been released to help expedite the process. All assume however that terminal or command prompt access is required to perform the detection. Few people realize that it is possible to passively detect a Vmware guest without any level of system access. In fact, if you know what to look for, you can even identify which version of VMware is hosting the virtual system.

Passive fingerprinting

Passive fingerprinting is a technique where by a remote operating system can be identified by the nuances in the IP packets it produces. For example the payload of Echo-Request packets are pretty unique from operating system to operating system. In a previous post I discussed how different operating systems use different time to live values. By analyzing these variations in the IP packets, you can do a pretty accurate job of identifying the source operating system. In fact many times you can even identify the patch reversion level of the system.

VMware virtual systems

VMware supports two modes for connecting a guest operating system to a network. You can NAT it behind the host, or connect it in bridging mode. Many people think that bridging mode gives the guest OS direct access to the network card, but they forget that VMware is still sitting in between the guest OS and the host system’s drivers to run the NIC. It is not uncommon for this layer to make changes in the IP packets before passing them onto the wire. So if you know what changes to look for, you can detect when VMware software is sitting between an operating system and the local network.

VMware makes multiple changes to the IP datastream. In this post we will only look at two of these changes (window size and scaling), and I’ll leave it to the reader to try and find the others. Further, different versions of VMware will modify the IP datastream in different ways. If you know what changes are unique to each version, you can identify the release level of VMware sitting between the guest OS and the network.

Window size and window scaling

TCP uses window size to identify how much data can be transmitted before a remote system must pause and wait for an acknowledgement. For example if “System A” tells “System B”, “window size = 1400”, “System B” is permitted to send just under one full size Ethernet packet before it must wait. After the 1400 bytes are transmitted, “System B” is not permitted to send any more data till it receives an acknowledgement of that data from “System A”. Window size is adjusted on the fly, so “System A” may eventually advertise “window size = 1600”. This means “System B” can now send a full size packet followed by one small packet before it must pause for an acknowledgement. Window size is a method of flow control to help insure that the receiving system does not see more data than it’s buffers can handle.

Window size dates back to the original implementation of TCP. At the time 16 bits were reserved (bytes 14 and 15 in the TCP header) to specify how many bytes could be transferred before pausing for an acknowledgement. This means we could specify a maximum window size of 65,535 bytes. That’s more than big enough by 1980 standards, but not so great when you are talking about 1 Gb and faster networks. In the early 90’s window scaling was added as a TCP option. Window scaling is only advertised in the first TCP packet sent by a system (SYN or SYN/ACK packet) and is a multiplier for the advertised window size. For example, assume a window size of 1400 bytes. If the window scale is 3, the math would be:

(2*2*2) * 1,400 = 11,200

If the window scale is 4, the math becomes:

(2*2*2*2) * 1,400 = 22,400

So window scaling permits us to now advertise much larger window sizes. This explanation is rather simplistic, but should give the reader a good idea of how window size and scale works. For more info see RFC 1323 or the TCP Wiki.

Backtrack 3 final as a stand-alone host

Here’s a SYN/ACK response to a connection request returned by a Backtrack 3 system (Linux 2.6.21.5 kernel) running on a dedicated host:

IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 192.168.100.4.80 > 192.168.100.50.44943: S, cksum 0×9552 (correct), 2760872392:2760872392(0) ack 4071399005 win 5792 <mss 1460,sackOK,timestamp 5362662 198395,nop,wscale 5>

Note the initial window scale is 5, which means the actual window size is 32 * 5792 = 185,344. This is pretty common for Linux systems running a post 2.6.17 kernel.

Now let’s take a look at how the window size for Backtrack 3 gets incremented:

[root@fubar ~]# tshark -n -T fields -e ip.src -e tcp.window_size -e tcp.options.wscale_val dst host 192.168.100.50

Capturing on eth0

192.168.100.4     5792      5

192.168.100.4     245

192.168.100.4     336

192.168.100.4     426

192.168.100.4     517

192.168.100.4     607

192.168.100.4     698

192.168.100.4     788

192.168.100.4     879

192.168.100.4     969

192.168.100.4     1060

I used tshark to clean up the output so we could focus on the fields we actually care about. The above trace is a large data transfer to 192.168.100.4 (BT3 stand alone) via TCP/80, as show in the above tcpdump trace. Note that we can pretty clearly identify how the window size was incremented over the data session.

Backtrack 3 final, guest on Windows XP Workstation

So let’s take a look at how window size and scaling get affected when the operating system is sitting behind VMware. In this test I ran BT 3 as a guest operating system on a Windows XP workstation host. I used VMware player 2.5.3 and wrote a custom VMX file to run the BT 3 iso.

Here’s an initial SYN/ACK packet:

IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 192.168.100.7.80 > 192.168.100.50.35245: S, cksum 0x670d (correct), 3795217952:3795217952(0) ack 4108648760 win 5792 <mss 1460,sackOK,timestamp 5210512 208486,nop,wscale 4>

Note that while the initial window size matches the stand-alone BT 3 system, VMware has dropped the window scaling from 5 (32x) to 4 (16x).

Here’s the stream of packets being returned by the guest system:

[root@fubar ~]# tshark -n -T fields -e ip.src -e tcp.window_size -e tcp.options.wscale_val dst host 192.168.100.50

Capturing on eth0

192.168.100.7     5792      4

192.168.100.7     490

192.168.100.7     671

192.168.100.7     852

192.168.100.7     1033

192.168.100.7     1214

192.168.100.7     1395

192.168.100.7     1576

192.168.100.7     1757

192.168.100.7     1938

192.168.100.7     2119

Note that after the first packet the negotiated window size appears larger, but when you factor in the window scale multiplier the overall window size ends up being slightly smaller than BT 3 when it is run on a dedicated system. Not all that surprising as virtual systems typically run slower than dedicated systems, but we’ve just tagged two differences we can look for to determine if the host is stand-alone or a guest virtual image.

Backtrack 3 final, guest on Fedora 11

Of course the big question is, “was the window size change due to the Windows XP host or VMware?”. VMware circumvents the Windows IP stack when transmitting on the wire, so the host OS should have no effect on the packet stream. To verify this, let’s try the same test using the same version of VMware player, only this time we’ll use Linux as the hosting operating system. Here’s the SYN/ACK:

IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 192.168.100.13.80 > 192.168.100.50.43363: S, cksum 0x6ef7 (correct), 3423175369:3423175369(0) ack 483782889 win 5792 <mss 1460,sackOK,timestamp 579990 366817,nop,wscale 4>

Here’s the stream of packets being returned from TCP/80 on the guest BT 3 system:

[root@fubar ~]# tshark -n -T fields -e ip.src -e tcp.window_size -e tcp.options.wscale_val dst host 192.168.100.50

Capturing on eth0

192.168.100.13    5792      4

192.168.100.13    490

192.168.100.13    671

192.168.100.13    852

192.168.100.13    1033

192.168.100.13    1214

192.168.100.13    1395

192.168.100.13    1576

192.168.100.13    1757

192.168.100.13    1938

192.168.100.13    2119

Note the results are identical to when BT3 was the guest operating system on Windows XP. So while this methodology will not identify the host operating system being used, we can consistently determine if BT3 is running on a dedicated system or as a guest via VMware. While it is entirely possible to modify a dedicated system to appear to be a virtual guest, the opposite does not appear to be feasible.

Exec Summary

By having an in-depth understanding of IP and the nuances generated by different operating systems, it is possible to determine if an OS is running on a dedicated system or as a guest via VMware. Modifications made by the VMware wrapper leave behind tell tale clues. A smart packet weenie can leverage these clues to determine the virtualization status of the source operating system.

No comments »

Posted in 2-alert, Packet Decoding

Tags:

Filtering Packet Output With Tshark

September 1st, 2009

In my last post we were looking at some packet decodes. One of the biggest pains in working with decodes is following a specific field over multiple packets. Some fields are not too bad as they tend to get printed by default. Good examples are port numbers and TCP flag settings. But in the last post we were working with the IP ID. That usually only gets printed if you view verbose information, so now you end up with a lot of data on the screen that you do not care about.

Luckily, the new version of tshark fixes this problem. Let’s work with some example so you can see what I mean.

What is tshark?

Tshark is the command line packet utility that is included with Wireshark. If you are not familiar with Wireshark, it is arguably one of the best graphical packet decoding tools available today, and it is free for use. There are versions that run on Linux, BSD and Windows (YES! Even Windows!).

So why work at the command line if there is a GUI version? In the case of tshark, it is because you can get a better presentation layout of the data you actually want to see.

The problem

So let’s say we want to monitor the IP ID increment for multiple packets leaving a system. We may try a command similar to the following:

C:\>tshark -n -i 3 src host 192.168.100.5

Capturing on Intel(R) PRO/100 VE Network Connection (Microsoft’s Packet Scheduler)

0.000000 192.168.100.5 -> 192.168.100.3 TCP 0 > 1832 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

1.003331 192.168.100.5 -> 192.168.100.3 TCP 0 > 1833 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

2.007332 192.168.100.5 -> 192.168.100.3 TCP 0 > 1834 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

3.011347 192.168.100.5 -> 192.168.100.3 TCP 0 > 1835 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

4.015336 192.168.100.5 -> 192.168.100.3 TCP 0 > 1836 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

The above command tells tshark not to perform name resolution, listen on the system’s third interface, and only capture packets originating from the system at 192.168.100.5. There is a problem however, where’s the IP ID? Unfortunately, tshark, like tcpdump and windump, does not print the IP ID value by default. Even Wireshark buries it in the middle pane so it can be difficult to spot and follow over multiple packets.

So what to do? Normally we would simply add in the “verbose” switch. This is what I used in the last post to print the IP ID with tcpdump. With tcpdump and windump you use the switch “-v”, but with tshark the switch is capitalized “-V”. Here’s an example:

C:\>tshark -n -i 3 -V src host 192.168.100.5

Capturing on Intel(R) PRO/100 VE Network Connection (Microsoft’s Packet Scheduler)

Frame 1 (54 bytes on wire, 54 bytes captured)

Arrival Time: Aug 31, 2009 13:18:42.532218000

[Time delta from previous captured frame: 0.000000000 seconds]

[Time delta from previous displayed frame: 0.000000000 seconds]

[Time since reference or first frame: 0.000000000 seconds]

Frame Number: 1

Frame Length: 54 bytes

Capture Length: 54 bytes

[Frame is marked: False]

[Protocols in frame: eth:ip:tcp]

Ethernet II, Src: 00:07:e9:46:2d:55 (00:07:e9:46:2d:55), Dst: 00:17:08:54:9a:00 (00:17:08:54:9a:00)

Destination: 00:17:08:54:9a:00 (00:17:08:54:9a:00)

Address: 00:17:08:54:9a:00 (00:17:08:54:9a:00)

…. …0 …. …. …. …. = IG bit: Individual address (unicast)

…. ..0. …. …. …. …. = LG bit: Globally unique address (factory default)

Source: 00:07:e9:46:2d:55 (00:07:e9:46:2d:55)

Address: 00:07:e9:46:2d:55 (00:07:e9:46:2d:55)

…. …0 …. …. …. …. = IG bit: Individual address (unicast)

…. ..0. …. …. …. …. = LG bit: Globally unique address (factory default)

Type: IP (0×0800)

Internet Protocol, Src: 192.168.100.5 (192.168.100.5), Dst: 192.168.100.3 (192.168.100.3)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0×00 (DSCP 0×00: Default; ECN: 0×00)

0000 00.. = Differentiated Services Codepoint: Default (0×00)

…. ..0. = ECN-Capable Transport (ECT): 0

…. …0 = ECN-CE: 0

Total Length: 40

Identification: 0×0461 (1121)

Flags: 0×00

0… = Reserved bit: Not set

.0.. = Don’t fragment: Not set

..0. = More fragments: Not set

Fragment offset: 0

Time to live: 128

Protocol: TCP (0×06)

Header checksum: 0xed15 [correct]

[Good: True]

[Bad : False]

Source: 192.168.100.5 (192.168.100.5)

Destination: 192.168.100.3 (192.168.100.3)

Transmission Control Protocol, Src Port: 0 (0), Dst Port: 2535 (2535), Seq: 1, Ack: 1, Len: 0

Source port: 0 (0)

Destination port: 2535 (2535)

[Stream index: 0]

Sequence number: 1    (relative sequence number)

Acknowledgement number: 1    (relative ack number)

Header length: 20 bytes

Flags: 0×14 (RST, ACK)

0… …. = Congestion Window Reduced (CWR): Not set

.0.. …. = ECN-Echo: Not set

..0. …. = Urgent: Not set

…1 …. = Acknowledgement: Set

…. 0… = Push: Not set

…. .1.. = Reset: Set

[Expert Info (Chat/Sequence): Connection reset (RST)]

[Message: Connection reset (RST)]

[Severity level: Chat]

[Group: Sequence]

…. ..0. = Syn: Not set

…. …0 = Fin: Not set

Window size: 0

Checksum: 0×9078 [validation disabled]

[Good Checksum: False]

[Bad Checksum: False]

OK, if we sift through the output we can find the IP ID information. If we want to check the value over multiple packets however, its going to be time consuming.

Printing only specific fields

One of the features in the latest version of tshark is the ability to print only specific packet fields. This is performed using the “-T fields” switch. You then use the “-e” switch to specific the fields you wish to see, in the specific order you want them to be printed. Here’s an example:

C:\>tshark -n -i 3 -T fields -e ip.src -e ip.dst -e ip.proto -e ip.id src host 192.168.100.5

Capturing on Intel(R) PRO/100 VE Network Connection (Microsoft’s Packet Scheduler)

192.168.100.5   192.168.100.3   0×06    0×0491

192.168.100.5   192.168.100.3   0×06    0×0492

192.168.100.5   192.168.100.3   0×06    0×0495

192.168.100.5   192.168.100.3   0×06    0×0496

192.168.100.5   192.168.100.3   0×06    0×0497

The “-e” switch uses the same pcap syntax used by Wireshark for display filters.  Packetlife has an excellent cheat sheet showing commonly used values. From left to right, I specified Source IP, Destination IP, transport, followed by the IP ID value. Note that with this format, it is now trivial to follow the IP ID increment in the packet stream.

Exec Summary

When performing packet decodes, it is not uncommon to end up with far more information on the screen than you actually need. In fact this can make it difficult to find the values you are trying to focus in on. The addition of tshark’s new display options can make following information over multiple packets far easier than it is with similar tools.

No comments »

Posted in 3-err, Packet Decoding

Tags: