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