As a method of session hijacking, hackers can easily hijack unreliable protocols. However, TCP is a reliable transmission protocol, many transmission functions are also based on the TCP protocol, so TCP session hijacking will be discussed in this chapter.
TCP session hijacking
According to TCP/IP rules, two serial numbers are required for TCP communication. TCP uses these serial numbers to ensure connection synchronization and secure communication, the system's TCP/IP protocol stack generates these values based on time or linear. During communication, the serial numbers of both parties are mutually dependent, Which is why TCP is a reliable transmission protocol (For details, refer to RFC 793 ). If an attacker hijacks a session at this time, the result is definitely a failure. because both parties "do not know" the attacker, the attacker cannot provide a legal serial number. Therefore, the key to session hijacking is to predict the correct serial number. Attackers can use sniffing technology to obtain the information.
Serial number of the TCP protocol
Now let's talk about the serial number of TCP protocol. Each packet has two serial numbers:
SEQ: sequence number of the first byte in the current data packet
ACK: the serial number of the first byte in the packet to be received.
Assume that the two parties need to establish a connection:
S_SEQ: sequence number of the next byte to be sent
S_ACK: sequence number of the next byte to be received
S_WIND: Receiving Window
// The above is the Server)
C_SEQ: sequence number of the next byte to be sent
C_ACK: Number of the next byte to be received
C_WIND: Receiving Window
// The above is the Client)
They must conform to the following logical relationship; otherwise, the packet will be discarded and an ACK packet (including the expected serial number) will be returned ).
C_ACK <= C_SEQ <= C_ACK + C_WIND
S_ACK <= S_SEQ <= S_ACK + S_WIND
If the above logical relationship is not met, a "fatal weakness" will be extended. For more information, see.
Critical weakness
This fatal weakness is the Storm ). When both parties receive an unexpected packet, they will return the ACK packet with their desired serial number. At the other end, this packet is not expected, the ACK package will be returned again with the desired serial number ...... As a result, back and forth formed a vicious circle, which eventually led to the ACK storm. A better solution is to first implement ARP spoofing so that packets from both parties can be sent to the attacker "normally", then set packet forwarding, and finally session hijacking can be performed, and you don't have to worry about an ACK storm. Of course, not all systems have ACK storms. For example, the TCP/IP protocol stack in Linux is slightly different from that described in RFC. Note that the ACK storm only exists in injection session hijacking.
TCP session hijacking
Assume that host A and host B have A TCP session, and host C is an attacker. The hijacking process is as follows:
A sends A data packet to B.
SEQ (hex): x ack (hex): Y
FL
AGS:-AP --- Window: ZZZZ, package size: 60
B responds to A packet
SEQ (hex): y ack (hex): X + 60
FLAGS:-AP --- Window: ZZZZ, package size: 50
A responds to A data packet from B.
SEQ (hex): X + 60 ACK (hex): Y + 50
FLAGS:-AP --- Window: ZZZZ, package size: 40
B responds to A packet
SEQ (hex): Y + 50 ACK (hex): X + 100
FLAGS:-AP --- Window: ZZZZ, package size: 30
Attacker C impersonates host A and sends A packet to host B
SEQ (hex): X + 100 ACK (hex): Y + 80
FLAGS:-AP --- Window: ZZZZ, package size: 20
B responds to A packet
SEQ (hex): Y + 80 ACK (hex): X + 120
FLAGS:-AP --- Window: ZZZZ, package size: 10
Currently, host B executes the command that attacker C impersonates host A and returns A packet to host A. However, host A cannot identify the packet sent by host B, therefore, host A will return A data packet to host B with the desired serial number, and then an ACK storm is formed. If the ACK storm (such as ARP spoofing) is successfully solved, TCP hijacking is successful.