Replay Attacks

September 18th, 2008
By Evan Wheeler

Replay attacks use a simple method of exploiting a captured packet or packets, and resend that traffic to cause unexpected results. If the source does not detect the duplication of the communications and accepts the repeated packets, then the attack is successful.[1] Even if the communications channel is protected with encryption and some form of strong authentication, such as digital signing, the attack can still be successful without the attacker ever knowing the exact contents of the transmissions being replayed. Often the actual packet replay will be executed at a later time, but some instances require the retransmission to take place when a legitimate client session is still valid. More sophisticated versions of this exploit may combine replay attacks with packet modification/injection, 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.

A simple example of the vulnerability can be illustrated by looking at a typical protected communications channel such as a VPN tunnel. The network traffic can all be encrypted from point to point, and even each packet authenticated using digital signatures, and the replay attack will still be successful. To combat this, IPSec VPNs make use of the Encapsulating Security Payload (ESP) subcomponent to generate a sequence number that is sent with each packet. The recipient keeps a record of each sequence number in a table to help identify invalid traffic. "If a hacker were to capture and replay that packet, the recipient would extract the sequence number and compare it against the table that it has been recording. If the packet’s sequence number is already present on the table, then the packet is assumed to be fraudulent and is therefore discarded."[2] This solution is only successful, of course, if the sequence number itself is encrypted or digitally signed, preventing the attacker from modifying the packets to include the next valid sequence number. If the sequence number does not use some means of cryptography to protect it, then the attacker can monitor the traffic, determine the sequence number generation pattern and defeat it.

A web application is also a good target for replay attacks. Imagine a scenario with an application that processes financial transactions. The client sends a request to the application to transfer $1,000 to another account. If this request is intercepted by a malicious party, they could potentially resend the request and cause the application to duplicate the original request, resulting in another $1,000 being transferred. Beyond the obvious implications, this may even cause the client’s account to be overdrawn after several instances of the attack.[3] This would be considered a pure replay attack. Often replay attacks are also used in combination with other attacks such as packet modification and injection to change the account number to which the money is being transferred. In this scenario, it isn’t even important that return traffic be successful, the damage is already done. In some cases the original client session may need to still be valid for the replay attack to work on web applications, but some application protocols reset the sequence number at the end of the session so they will recognize the replay attack as the start of a new session.

A slightly different form of the attack is by using the replay of valid requests on a wireless network to generate return traffic that is used to break a WEP key. By replaying ARP requests from a valid client connected to a wireless access point, the attacker can then capture the reply traffic generated by the access point which will include a different Initialization Vector (IV) each time. This is used to decipher the secret key used in the WEP encryption, and to then use that key to eavesdrop on additional transmissions or connect to the access point itself. In this case, the more responses generated with different IVs, the easier it will be to break the WEP encryption. Sometimes an attacker may need to monitor the network for a while before seeing an ARP request that can be replayed, but there are also several different variations on this attack on wireless networks.[4]

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[5] can be used to grab the traffic off the network, and a specialized tools such as Tcpreplay[6], or Aircrack[7] 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[8] to capture the HTTP requests and also to replay them to the server.

===
1. http://en.wikipedia.org/wiki/Replay_attack
2. http://www.brienposey.com/kb/using_esp_to_prevent_replay_attacks.asp
3. http://chacs.nrl.navy.mil/publications/CHACS/1994syverson-foundations.pdf
4. http://www.aircrack-ng.org
5. http://www.wireshark.org/
6. http://tcpreplay.synfin.net/trac/wiki/manual
7. http://www.aircrack-ng.org
8. http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
9. http://www.owasp.org/index.php/Testing_for_WS_Replay