What is a Replay Attack?: A Complete Explanation
It’s almost impossible to overstate the value of the data that travels across computer networks today. Everything from coveted financial information to company trade secrets to personal identifiers like credit card and social security numbers all resides, in some form or other, on servers that communicate regularly with other machines. And while the swift information exchange does a great deal to grease the wheels of our technological civilization (which we all benefit from), it is not without its hazards. Information like that — constantly moving around, or even just sitting there in enormous quantities — is an irresistible target for cybercriminals.
Hackers have a distressingly sophisticated array of tools and techniques that they use to steal data and wreak havoc upon networks. Knowing about these types of attacks and how they work is essential for proper prevention.
As with most other crimes or malicious activity, stealth is usually of the essence for hackers. One common and often strikingly effective hacking technique, known as a replay attack, is especially underhanded. In essence, a replay attack is an attempt to impersonate a trusted party by intercepting critical network traffic and sending it along to its intended destination as if the attacker were the trusted party.
Fortunately, there are ways to protect your network infrastructure and valuable data from replay attacks. To understand how to do so, however, one first needs a detailed understanding of just what replay attacks are, how they function, and what security holes they are built to exploit. We’ve got the information you need regarding what attackers typically aim to achieve, some important variations on it, and even some of the history behind it. Perhaps most importantly, we’ll discuss some real-world examples where replay attacks have been (and still might be) used, and what prevention and mitigation strategies you can employ to combat them.
The Replay Attack: A Exact Definition
A replay attack, also known as either a repeat attack or a playback attack, is a type of network attack in which a hacker intercepts a valid data transmission — like a request by a client to access data on a server — and then fraudulently delays or repeats that data transmission. The hacker then steals the valid client’s session ID. In doing this, he or she can masquerade as the valid client to access whatever data the valid client can normally access on the network.
A session replay attack is a passive type of man-in-the-middle attack that fools the network servers into thinking they are communicating with valid clients. When this happens, the server or receiver gets the message twice — once from the true sender and once from the attacker. This is the reason for the name “replay attack.”
It is important to note that such intercepted communications usually do not need to be decrypted by the attacker to be effective, as decryption is generally done by the server after receiving the message. Indeed, given certain security protocols, traffic recipients may not only happen to accept encrypted incoming traffic but can even require traffic to be encrypted as a condition of accepting it.
How Do Replay Attacks Work?
To fully flesh out what replay attacks are, and how and why they can give attackers unauthorized network access, a little bit of background information on computer networking is in order.
Some Networking Background
All computers communicate by sending data packets to one another and receiving and interpreting the packets that are sent to them. Without this, no computer networking would be possible.
The central basis of the TCP/IP protocol — the most commonly used networking protocol today — is what’s known as a three-way handshake. This is a three-step process that has to happen before any client or server can establish a connection with one another.
First, the client — the computer seeking to establish the connection — sends an SYN packet to the server or computer to which the client desires to connect. In response, the server then sends an SYN/ACK packet back to the client acknowledging that it received the client’s SYN packet. Lastly, the client will send the server an ACK packet that acknowledges this response. During each of the steps, all three of these packets come with their own specific sequence numbers that distinguish the respective communicants.
Encryption and other security measures may somewhat complicate this process, but all replay attacks are designed to subvert and take advantage of this protocol.
The Steps and Structure of a Replay Attack
A successful playback attack can be broken down into a series of stages. The first of these is known as packet sniffing. Packet sniffing is the act of eavesdropping on a network, watching the packets being exchanged between its constituent computers, and then collecting, storing, and logging those packets for later use during a hack. Usually, a piece of software called a network sniffer is used to assist in this task. Wireshark is one example of a widely used packet sniffer.
The second stage of the session replay attack is to steal a network user’s session ID. A session ID is a unique number that a server assigns to a client for a given duration of time, usually coincident with the client’s network use or access. They are usually created by pseudorandom number generators and therefore are difficult to guess by chance. Web servers tend to attach these numbers to URLs to form strings.
When they aren’t attached to URLs, it’s common for servers to attach session IDs to either cookies or hidden form fields. Cookies are small files that track user behavior across a network and store certain user data (like website passwords) locally on that user’s browser and computer. Because of this, it’s often natural to embed session IDs into cookies. Some cookies, called session cookies, are created for specific sessions that a user spends on the network. When session IDs are embedded into cookies, the client sends the appropriate cookies as part of every packet exchange with the server, which allows the server to identify him.
To steal a session ID, a hacker needs to sniff network traffic and pick up the appropriate cookies or whatever other kinds of data the session ID may have been embedded into.
Once this is done, the hacker can initiate the third stage of his attack, which is when the real action happens. He uses the session ID to impersonate a trusted user of the network. He stores the appropriate authentication packets that he has sniffed and sends them to the server. After this, the hacker has access to all of the data that the original user would have access to, as well as all of the permissions that go with that user.
Prevention and Protection
Successful replay attacks can have truly awful consequences. If a company fails to protect its customer’s private data, its reputation will suffer. The privacy of those whose data is stolen will be shattered, and they will be left open to identity theft. If company bank accounts are tied to a compromised network, hackers can outright rob that company.
Luckily, there are several effective prevention strategies that you can use to keep from falling victim to replay attacks. First, you should implement all of the “standard” internet security measures such as firewalls, VPNs, pop-up blockers, anti-virus software, or even web-application-specific firewalls. While these measures are not specially tailored to prevent replay attacks, they are useful and can give hackers fewer ways to get a foot in the door.
Additionally, here are a few specifically anti-replay measures that you should implement:
- Timestamping: When you timestamp all of your data packets, you attach a bit of data to each one that specifies precisely when that packet was sent. The network server can then be programmed to ignore all packets with timestamps outside of a given range, with the range being appropriately adjusted as time progresses. That way, even if hackers can capture your data packets, they cannot use them to impersonate you outside of a rather short time window.
- Session IDs: Even though hackers can steal session IDs, it’s still a good idea to use them because they put an extra layer of authentication between the hackers and your network, making hackers’ jobs more difficult.
- TLS/SSL Certificates: Transport Layer Security, or TLS, is a network communications security protocol meant to encrypt sensitive traffic such that only specific parties can access it. TLS works by encrypting all communications between two parties using public-key cryptography and is at the core of HTTPS, the secure version of HTTP. Communications are only accepted and decrypted if one party can verify the identity of the other. This verification is done via a TLS certificate. These certificates are issued by special Certificate Authorities who sign them and verify that each certificate has been issued to some particular domain name and no other. Since hackers won’t have the requisite certificate, they won’t be able to steal your session ID or make much use of your traffic. You can learn more about the TLS protocol here.
- One-Time Passwords: A particularly extreme security measure is to guard every packet exchange between two parties on a network with a special one-time password generated for the purpose. Since each password is only good once, stealing one for session replay attack purposes is pointless. Institutions where data security is paramount, like banks, frequently use this method.
The Origins of the Replay Attack
Hacking and cybersecurity are two opposing sides of an arms race, so their histories coincide. With this in mind, it can be helpful to think of a replay attack as a passive version of what’s known as a man-in-middle attack.
A man-in-the-middle attack is an attack upon a network in which an attacker interposes himself between two network communicants and makes the communicant believe that they are communicating with one another when they are really communicating through the attacker. A replay attack is a passive version of this because, in a replay attack, the hacker merely eavesdrops on and steals messages exchanged between the communicants. He does not do anything to alter the messages being exchanged.
The first-ever man-in-middle attack started, like so many other hacks throughout history, as a joke. As the story goes, Guglielmo Marconi, the Nobel-Prize-winning electrical engineer whose work in creating the radio-wave-based telegraph network has served as the basis for all digital communications since, once decided to play a joke on an expert advisor to his company, a certain Professor Fleming.
Fleming would go around demonstrating the ability of Marconi’s system to send messages wirelessly from one node to another, to the amazement of many at the time. During one such planned demonstration, in which a message was to be set to the Royal Institute from a location in Cornwall, England, a man only remembered to history as “Mr. Maskelyne” decided to set up his own receiving and transmitting node and intercept Fleming’s message. After Fleming sent his message, Mr. Maskelyne intercepted it and changed it into something sarcastic and biting. Sadly, there is no record of what the new message was, but we know that Fleming was none too pleased about it and very much taken by surprise.
All kinds of man-in-the-middle attacks, whether replay attacks or otherwise, take advantage of the basic fact that devices (such as computers) form networks by wirelessly exchanging data packets with one another. Any insecure network is vulnerable. Historically, network holes have been discovered through trial and error, and cybersecurity emerged to plug them up.
Thus, the history of hacking and cybersecurity can be thought of as one long dance between black hat and white hat hackers. This is true not only of Marconi’s first hack but of later man-in-the-middle-type attacks that proliferated throughout the 1980s and eventually led to the creation of the SSL standard, and the even more sophisticated attacks that eventually forced the world to replace SSL with TLS in 2015.
Why Would Anyone Want to Carry Out a Replay Attack?
If it succeeds, a repeat attack will grant hackers access to the network they have chosen to target. Having fooled the network architecture into thinking that they are a trusted user, the hackers are granted access to whatever data that user normally has access to. There’s then no limit to what they can potentially pillage or destroy, from bank accounts to IoT-based systems at energy plants.
But malicious hackers aren’t the only ones to benefit from replay attacks. Large and important organizations often hire penetration testers — colloquially known as “white hat hackers” — to test their network security systems by attempting to compromise them. Such an attempt may succeed thanks to the replay attack, in which case, the penetration tester prepares a detailed report of all the security vulnerabilities that made the breach possible and suggests measures to strengthen network security and prevent such attacks.
A Real-World Example of a Replay Attack
We’ll cap off our discussion with a brief but scary example of this “playback attack” technique in action.
Cars built in more recent years can, for the sake of convenience, provide remote keyless access for their drivers. However, if a car thief sets up a device that can receive and transmit radio waves not far from the car, he can intercept the unlocking signal and store it for later use. The transmitter can then intercept and buffer all later attempts by the driver to unlock his vehicle. This not only gives the thief access to the vehicle but prevents the driver from getting access to it.