Replay Attacks

Replay Attacks

by Ted Hersey


Abstract

A Replay attack occurs when a third party captures a command in transmission and replays it at a later time. By capturing the correct messages, an intruder may be able to gain access to a secure computer or execute commands which are normally encrypted and unreadable. It is often not necessary to decifer the command to use it. Because of this, "Replay attacks are typically simple to perform and require little or no sophistication." [1]


Performing an Attack

The Replay attack is simple because it is not difficult to capture the commands to be replayed. An user on a network can run a sniffer program and capture all packets that travel over the network. "Many popular Virtual Private Network (VPN) daemons for Unix and Linux operating systems could allow a remote attacker to launch a replay attack using a sniffer tool to capture encrypted packets and replay them at a later time. [2] The fact that these packets are encrypted is not a problem. Replay attacks look for systems with weak authentication.


Without Authentication You are Vulnerable

When a user sends a computer command or transmission from one machine to another we want that communication to be secure. There are three different attributes that secure communications should have: secrecy, integrity, and authentication. [3]

Secrecy means that only the sender and receiver are able to understand the message. This can be achieved with a number of symetric or public key encription schemes. Integrity means that the message is not changed in transmission. It means the reciever got the exact data that the sender transmitted and the message has not been tampered with or changed in transmission. This can also be achived in encription schemes with the addition of hash values or message digests. These functions calculate a unique mathematical value for the message. The receiver can recalculate the hash to see that the message is unchanged.

Authentication, the third attribute of secure communications, means that both the sender and receiver know the identity of each other. If the reciver can not verify the identity of the sender, he is vulnerable to a replay attack. A command captured by a third party can be replayed at a later time and accaepted as true by the reciever.


Examples of Replay Attacks

Older technology is most vulnerable to replay attacks. For example, telnet transmits its information in clear text with no encryption. "This makes you susceptible to replay attacks in which a cracker simply plays back your username and password." [4] The answer is not with fancier technology. Biometrics offers sophisticated ways to identify a person. Using a fingerprint reader, a remote machine can identify the user. But, "then there's nothing to prevent an attacker from sniffing a fingerprint reading and then replaying it later to masquerade as the fingerprint's owner." The best encryption and identification does nothing if the reciever of a message can not be sure of who sent it.


Preventing Replay Attacks

To prevent Replay attacks, an encryption system needs to include a way for sender and receiver to verify each others identity. This can be done by passing back and forth a one time unique number, or "nounce." For applications where no possibility of replay attacks can be tolerated the server can use one-time response digests which will not be honored for a second time." [5] This is a way of building authentication into the transport layer of internet software. There are also approaches that add security to the IP network layer. "IPSec is a security enabled protocol that's designed to run on IP networks. IPSec runs at the network level and is responsible for establishing secure communications between pcs. Guarding against replay attacks is done through the use of another ESP subcomponent, a mathematically generated sequence number. When a packet is sent to a recipient, the recipient extracts the sequence number and records the sequence number in a table. 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." [6]

IPSec can be implemented on Virtue Private Networks. For application running over the general network, it is important to build authentication into your applications. If you run a server which can not verify the the acurate indentity of its clients, you are suseptible to Replay attacks.


Reference

[1] Dr. Fred Cohen. www.all.net/CID/Attack.
http://www.all.net/CID/Attack/Attack76.html
[2] Internet Security Systems. www.iss.net
[3] James F. Kurose & Keith W. Ross. "Computer Networking". p566. Addison-Wesley 2001.
[4] "The Problem with Identity". www.cs.tufts.edu
http://www.cs.tufts.edu/g/150NET/notes/identity.php3
[5] Replay Attacks. www.securenet.com
[6] Brien M. Posey. "Using ESP to Prevent Replay Attacks". www.brienposey.com
http://www.brienposey.com/using_esp_to_prevent_replay_attacks.htm