TCP/IP Hijacking

TCP/IP hijackingTCP/IP hijacking is a technique that uses spoofed packets to take over a connection between a victim and a host machine. It is similar to a man-in-the-middle attack, except that the rogue agent sends a reset request to the client so that the client loses contact with the server while the rogue system assumes the role of the legitimate client, continuing the session. This technique is especially useful when the victim uses a one-time password to connect to the host machine. A one-time password can, as its name implies, be used to authenticate once and only once; thus, sniffing the authentication is useless for the attacker.

To carry out a TCP/IP hijacking attack, the attacker must be on the same network as the victim. This gives the attacker the ability to sniff the local network segment and, as a result, all the details of open TCP connections can be pulled from the headers. Each TCP packet contains a sequence number in its header. This sequence number is incremented with each packet sent to ensure that packets are received in the correct order. While sniffing packets, the attacker has access to the sequence numbers for a connection between a victim and a host machine. Then the attacker sends a spoofed packet from the victim’s IP address to the host machine, using the sniffed sequence number to provide the proper acknowledgment number. The host machine will receive the spoofed packet with the correct acknowledgment number and will have no reason to believe the packet did not come from the victim’s machine; thus the TCP/IP hijacking attempt will be successful.


Forms of TCP/IP Hijacking

One form of TCP/IP hijacking is to inject an authentic-looking reset (RST) packet. If the source is spoofed and the acknowledgment number is correct, the receiving side will believe that the source actually sent the reset packet, and the connection will be reset. The attacker could perform such an attack using a program that uses the libpcap and libnet libraries. libpcap would sniff the packets, and libnet would inject RST packets. The program does not need to look at every packet, but only established TCP connections to a target IP, so the libcpap function calls would be structured accordingly. It is relatively easy to come up with a filter rule for packets that have a certain destination IP. It is somewhat more difficult to filter for established connections, but since all established connections will have the ACK flag in the TCP header TCP flags, the program can look for that.

Another type of TCP/IP hijacking is continued hijacking. The spoofed packet does not need to be an RST packet; the spoof packet can contain data. When the host receives the spoofed packet, it will increment the sequence number and responds to the victim’s IP. Since the victim’s machine does not know about the spoofed packet, the host machine’s response has an incorrect sequence number, so the victim ignores that response packet. And since the victim’s machine ignored the host machine’s response packet, the victim’s sequence number count is off. Therefore, any packet the victim tries to send to the host machine will have an incorrect sequence number as well, causing the host machine to ignore it. In this instance, both legitimate sides of the connection have incorrect sequence numbers, resulting in a desynchronized state. And since the attacker sent out the first spoofed packet that caused all this chaos, it can keep track of sequence numbers and continue spoofing packets from the victim’s IP address to the host machine. This lets the attacker continue communicating with the host machine while the victim’s connection hangs.


External Links:

TCP Hijacking at TechRepublic

Replay Attacks and Possible Countermeasures

replay attackReplay attacks are a variation on the man-in-the-middle theme. In a replay attack an agent is once again placed within the client/server line of communication. In the case of a replay attack, however, the transaction data is recorded for the express purpose of allowing the data to be modified and replayed to the server at a later time for nefarious purposes.

An example of a replay attack is an instance where one party wants to prove their identity to a another party. If a third party eavesdrops on the conversation, they can intercept the password. Once the exchange is over, the eavesdropper can send the password and impersonate the party to whom the password belongs to gain unauthorized access to the other party.

Defenses Against Replay Attacks

As with other man-in-the-middle attacks, replay attacks can be countered using encryption, timestamps, serial numbers and packet sequences so that the server can detect that the data is being replayed from a previous session. One effective method of avoiding replay attacks which uses encryption is to use session tokens. Let us assume that A is required to send a password to B. If session tokens are used, B will send a one-time token to A, which A will then use to transform the password and send the result to B. On the other side, B performs the same transformation, and if both values match, the login will be successful. If C eavesdrops on A and B and captures the transformed password, C can try to use it to authenticate with B. But B will send a session token, and if C sends the transformed password captured earlier, the transformations will not match, and authentication will fail.


If C knows that B is using session tokens, C might be able to pose as B, presenting some predicted future token, and convince A to use that token in A’s transformation. C can then replay A’s reply at a later time, when the previously predicted token is presented by B, and B will accept the authentication. For that reason, session tokens should be chosen by a pseudo-random process.

One-time passwords are similar to session tokens in that the password expires after it has been used or after a very short period of time. They can be used to authenticate individual transactions in addition to sessions.

Replay attacks can also be thwarted by the use of message authentication codes (MACs), short pieces of information used to authenticate a message and to provide integrity and authenticity assurances on the message. MAC algorithms accept as input a secret key and an arbitrary-length message to be authentication, and outputs a MAC. This value protects both a message’s data integrity and its authenticity by virtue of the fact that the verifiers possessing the secret key to detect any changes to the message content.

Timestamping is another means of preventing a replay attack. Synchronization is achieved using a secure protocol. As an example, B can broadcast the time on their clock along with a message authentication code (MAC). If A wants to send B a message, they can include an estimate of the time on B’s clock in their message (which also sends a MAC). B only accepts messages for which the timestamp is within a reasonable tolerance.


External Links:

Replay attack on Wikipedia

Man-in-the-Middle Attacks

man-in-the-middle attackMan-in-the-middle attacks are perhaps one of the more complex and sophisticated forms of security breaching approaches. As the name implies, such an attack involves the surreptitious placement of a software agent between the client and server ends of a communication. In this scenario, neither end of the communication is aware that the malicious agent is in the line of communication. For the most part, the man in the middle simply relays the data transmissions between client and server as though nothing is happening. What is generally happening in parallel with this process is that the agent is also recording the data as it is passed through. A man-in-the-middle attack can succeed only when the attacker can impersonate each endpoint to the satisfaction of the other. Such an attack results in a third party gaining access to a variety of different types of data, from login and password credentials to proprietary and confidential information. In addition, it is possible for the man-in-the-middle agent to modify data, causing unsold problems for the victim.

Man-in-the-middle attacks have increased considerably since the introduction of wireless networking. As a result, there is no need for the hacker to connect to a wire. Instead, the data can simply be intercepted from anywhere within range of the wireless signal.


Preventing Man-in-the-Middle Attacks

In order to prevent MITM attacks, some form of endpoint authentication is helpful. Just using public key encryption is not enough to prevent such an attack. As an example, suppose A and B are trying to communicate, and C is trying to intercept said communications. If B sends A his public key and C intercepts it, he can replace B’s public key with his own and send it to A. If A then encrypts a message with C’s public key (believing it to be B’s public key), then when it is sent, C can intercept and read it, decrypting it with his private key. He can also re-encrypt the message using C’s public key and send it to C.

Thus, any private-public key system requires some means of ensuring that a MITM attack does not compromise its integrity. One possible method is public key infrastructures (PKI). The main defense in a mutual authentication. In this case, as well as the application validating the user, the user’s devices validate the application – hence distinguishing rogue applications from genuine applications. Another possibility is a recorded media attestment, which can be either a verbal communication of a shared value for each session, or an audio/visual communication of the public key hash. In addition, stronger mutual authentication, such as secret keys and passwords often helps thwart man-in-the-middle attacks.

Latency examination may be a useful means of detecting man-in-the-middle attacks. For example, if each party performs a long cryptographic hash function calculation that takes 20 seconds normally, and the calculation takes 60 seconds to reach each party, this can indicate a third party.

The integrity of public keys must generally be assured in some manner, but need not be secret. Passwords and shared secret keys have the additional secrecy requirement. Public keys can be verified by a certificate authority whose public key is distributed through a secure channel. Public keys can also be verified by a web of trust that distributes public keys through a secure channel.

Quantum cryptography protocols, which use quantum communication and quantum communication to perform cryptographic tasks, can be used to thwart man-in-the-middle attacks. One method quantum cryptography employs is quantum key distribution (QKD), which establishes a shared key between two parties. If a third party tries to eavesdrop and learn these bits, the messages will be disturbed and the original two parties will notice. The key is then typically used for encrypted communication.


External Links:

Man-in-the-middle attack on Wikipedia

© 2013 David Zientara. All rights reserved. Privacy Policy