Replay Attack & Its Countermeasures

Replay Attack:

A replay attack is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. This is carried out either by the originator or by an adversary who intercepts the data and retransmits it, possibly as part of a masquerade attack by IP packet substitution. This attack uses a simple method of exploiting a captured packet or packets, and resends that traffic to cause unexpected results. If there is no mechanism implemented to detect such duplication of the packets/communications then the attack is successful.
The attack can be successful even if the communications channel uses encrypted channel and implements strong authentication, such as digital signing. The only thing is that in such a case the attacker doesn’t know the exact contents of the transmissions being replayed but can blindly perform the actions. Often these replay attacks will be carried out at a later time, but in some cases the replay has to be done when a legitimate client session is still valid. More sophisticated versions of this exploit may combine replay attacks with packet modification, source spoofing, or man-in-the-middle attacks. The success of this attack in any form relies on the ability of the attacker to initially capture valid transmissions to the target system, whether encryption is used or not. Common targets for the replay attack are encrypted communications channels such as IPSec tunnels or wireless encryption protocols, as well as web applications.
For example, assume that there is a web application with this vulnerability. A user called ‘Legitimate’ transferred 500 bucks to another account. If this transaction is captured by an ‘Attacker’ and he replayed the same packets again then what happens? Again 500 bucks from ‘Legitimate’ user’s account will get transferred to another account. Suppose, assume that these transactions are not protected with encryption then the ‘Attacker’ can modify the captured packets thus can transfer the amount to his account as well as can change the transfer amount. Even with or without encryption the attack is successful the only difference is if the communication/transaction is protected with encryption then the attacker can only replay the same action that the legitimate user did before.
The attacker can gain the access to a legitimate user’s session if he captures the initial requests (authentication related) of the legitimate user and replays the requests. For example, a legitimate user wants to establish a connection with the server. Server requests authentication information from legitimate user as proof of identity, which legitimate user dutifully provides; meanwhile, an attacker is eavesdropping this conversation and captures these requests made by the legitimate user. After the interchange is over, attacker connects to the server posing as legitimate user; when asked for a proof of identity, attacker replays the captured packets, which server accepts and gives access to attacker.
The combination of strong authentication and encryption defeats most spoofing and man-in-the-middle attacks when implemented correctly, but not replay attacks. For this reason, some sort of timestamp or pseudo sequence number (also known as ‘session token’) is needed in combination with the encryption and strong authentication. Commonly tools such as Tcpdump or Wireshark can be used to grab the traffic off the network, and a specialized tools such as Tcpreplay, or Aircrack in the case of wireless, can be used to test systems for this vulnerability. For web applications, another common method of testing for this weakness is to use a web proxy such as WebScarab or Fiddler to capture the HTTP requests and also to replay them to the server.

Countermeasures:

Session Tokens: A pseudo random token should be issued to the user when the request come from a legitimate user then this session token has to be submitted by the user whenever he sends the subsequent request thus the server can cross check this session token with the token stored at server side. These tokens should be chosen by a (pseudo-) random process and must be changed for every action performed by the user. For example, create a random token in page load, protect it with encryption/hash and send/store it at client (like in the form of acookie). So, whenever the client sends another request like submission of the data then cross check the token with the stored token at server side.
Timestamps: This is another way of preventing a replay attack, in this synchronization of the time should be achieved using a secure protocol. For example server periodically broadcasts the time on its clock together with a MAC. When user wants to send a request to the server, he includes his best estimate of the time on his clock in his request, which is also authenticated. Server only accepts requests for which the timestamp is within a reasonable tolerance. The advantage of this scheme is that server does not need to generate random numbers/ session tokens.
Limit the session time: Enforce session time limits to invalidate state information and session IDs after a certain period of inactivity (10 minutes, for example) or a set period of time (perhaps 30 minutes). This actually limits the interval time for attack.
Deny concurrent logins: Disallow users from having multiple, concurrent authenticated sessions to the application. This could prevent malicious users from hijacking or guessing valid session IDs.

References:

http://www.sans.org/resources/security_plus/replay_attack_sp08.php
http://www.reference.com/browse/wiki/Replay_attack

Session hijacking: A method of taking over a user session

Session hijacking:

Session hijacking is a method of taking over a Web user session by surreptitiously obtaining the session ID and masquerading as the authorized user. Once the user's session ID has been accessed, the attacker can masquerade as that user and do anything the user is authorized to do. Session hijacking works by taking advantage of the fact that most communications are protected with authentication procedures (by providing credentials) at session setup, but not thereafter. These attacks generally fall into three categories: Man-in-the-middle (MITM), Blind Hijack, and Session Theft.
In MITM attacks, an attacker intercepts all communications between two hosts. With communications between a client and server now flowing through the attacker, he or she is free to modify their content.
In blind hijacking, an attacker injects data such as malicious commands into intercepted communications between two hosts commands like "net.exe localgroup administrators /add EvilUser". This is called blind hijacking because the attacker can only inject data into the communications stream; he or she cannot see the response to that data (such as "The command completed successfully.") Essentially, the blind hijack attacker is shooting data in the dark, but as you will see shortly, this method of hijacking is still very effective.
In a session theft attack, the attacker neither intercepts nor injects data into existing communications between two hosts. Instead, the attacker creates new sessions or uses old ones. This type of session hijacking is most common at the application level, especially Web applications. The session ID is normally stored within a cookie or URL for web applications, so the attacker use other techniques like cross site scripting to capture or steal these cookies to hijack a current active session. The intrusion may or may not be detectable, depending on the user's level of technical knowledge and the nature of the attack. If a Web site does not respond in the normal or expected way to user input or stops responding altogether for an unknown reason, session hijacking is a possible cause.
Session hijacking at the network level is especially attractive to attackers. They do not need host access, as they do with host-level session hijacking. Nor do they need to customize attacks on a per-application basis, as they do at the application level. Network-level session hijacking attacks allow attackers to remotely take over sessions, usually undetected. But successfully hijacking a session at the network level requires more skills and attacker needs to cross many obstacles.

Hijacking a TCP Session:

One of the key features of TCP is reliability and ordered delivery of packets. To accomplish this, TCP use acknowledgment (ACK) packets and sequence numbers. Manipulating these is the basis for TCP session hijacking. To understand the TCP session, we need to focus on what happens when a client establish a connection with the server. Every TCP session initiation starts with a three way handshake. For example, the client first initiates a session with the server by sending a synchronization (SYN) packet to the server with initial sequence number x. The server responds with a SYN/ACK packet that contains the server's own sequence number p and an ACK number for the client's original SYN packet. This ACK number indicates the next sequence number the server expects from the client, this is x+1 (x plus client's original SYN packet size in bytes, normally is one when establishing a session). The client acknowledges receipt of the SYN/ACK packet by sending back to the server an ACK packet with the next sequence number it expects from the server, which in this case is p+1 (the server's initial SYN packet sequence number plus one). The client and server are ready to start exchanging data.

Client	------- SYN, Sequence no x ---------------------->	Server
Client	<----- SYN/ACK, Sequence no p -----------------	Server
	<----- Acknowledgement no x + 1 -------------
Client	----- ACK, Acknowledgement no p + 1 ------->	Server

Once the TCP session is established, then the client starts sending data to the server with the sequence number x + 1. The server acknowledges this packet by sending back to the client an ACK packet with number x + n (n is size of the data sent in bytes) as the next sequence number expected by the server. If the attacker wanted to inject data into the TCP session as the client, he or she would need to: Spoof the client's IP address, determine the correct sequence number that is expected by the server from the client, and inject data into the session before the client sends its next packet. The first and second tasks are easily accomplished, but the third is a bit difficult and not impossible.
Hijacking a session over a User Datagram Protocol (UDP) is exactly the same as over TCP, except that UDP attackers do not have to worry about the overhead of managing sequence numbers and other TCP mechanisms. Since UDP is connectionless, injecting data into a session without being detected is extremely easy.

Web based Session Hijacking:

In web based/application based session hijacking, it is the act of taking control of a user session after successfully obtaining or generating an authentication session ID. Session hijacking involves an attacker using captured, brute forced or reverse-engineered session IDs to seize control of a legitimate user's Web application session while that session is still in progress. HTTP is stateless, so application designers had to develop a way to track the state between multiple connections from the same user, instead of requesting the user to authenticate upon each request in a Web application. A session is a series of interactions between two communication end points that occurs during the span of a single connection. When a user logs into an application a session is created on the server in order to maintain the state for other requests originating from the same user. For this purpose a session ID is used and shared between the client/user and server, a session ID is an identification string (usually a long, random, alpha-numeric string) that is transmitted between the client and the server. Session IDs are commonly stored in cookies, URLs and hidden fields of Web pages.
There are several problems with session IDs. Many of the popular websites use algorithms based on easily predictable variables, such as time or IP address, in order to generate the Session IDs, causing their session IDs to be predictable. If encryption is not used (typically SSL), Session IDs are transmitted in the clear and are susceptible to eavesdropping. In most applications, after successfully hijacking a session, the attacker gains complete access to all of the user's data, and is permitted to perform operations instead of the user whose session was hijacked. Session IDs can be stolen using a variety of techniques like sniffing network traffic, using Trojans on client PCs, using the HTTP referrer header where the ID is stored in the query string parameters, and using Cross-Site Scripting attacks.

Countermeasures:

Use of strong and random session IDs: Use strong and random session IDs to prevent brute force and guessing techniques.
Limit the session time: Kill the session after few minutes of idle time.
Mutual Authentication: Client certificates can be a strong mitigation against Man in the Middle attacks and session hijacking.
Secured Socket Layer: Using SSL for all communication can mitigate the session hijacking. But, SSL alone does not do the trick to protect session hijacking. You need to have session tokens as part of POST data.
HTTPOnlyFlag: It is a good mitigation to prevent client code accessing cookie even if is not strong mitigation (can be bypassed). You might want to add /secure parameter to prevent them traveling in non SSL channels.
Changing session token: Regenerating cookie information often, or on each request, you should generate it at each POST data request when this data is sensitive.
Regenerating session ID: Upon successful log in a fresh token/ID should be created to mitigate session fixation type attacks.
Use IPSec to prevent TCP based session hijacking: Internet Protocol Security has the ability to encrypt your IP packets based on a Pre-Shared Key or with more complex systems like a Public Key Infrastructure ‘PKI’. This will also defend against many other attack vectors such as sniffing. The attacker may be able to passively monitor your connection, but they will not be able to read any data as it is all encrypted. Remember that, there are IPSEC cracking tools available on the internet that will attempt to guess the PSK and decrypt packets.
Finally, ensure that your application is safe from injection attacks like cross site scripting, reduce the attack surface area of your application and network and follow defense in depth rule.

References:

http://technet.microsoft.com/hi-in/magazine/2005.01.sessionhijacking(en-us).aspx
http://www.securitydocs.com/library/3479
http://seclists.org/webappsec/2009/q1/0078.html