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.
Related posts:
