In today’s world, hardly anybody needs an introduction to cybercrime. If you are reading up on this material on the internet, you probably know what cybercrime is and the havoc it wreaks.
One kind of cybercrime is the Man in the Middle kind of cybercrime, where the communication between two legitimate parties on the internet is intercepted by a malicious entity to gain access to personal and valuable information. The malicious entity here, of course, is the Man in the Middle who perpetrates the crime of stealing information.
After having gained access to the data packets of a message, the attacker can use them in many ways, one of them being what we call a Replay Attack. This is an attack on the lower rung of an attack hierarchy if you will.
If you are looking for a single liner, in a Replay Attack, the attacker uses the captured data packets to either delay the original message or repeat the exact same message. If it sounds interesting, let’s get deeper into it.
Table of Contents
What is replay attack?
A Wikipedia definition is warranted before any other, and this is how it goes, “A replay attack is a form of network attack in which valid data transmission is maliciously or fraudulently repeated or delayed”. Delaying it constitutes what is called a Suppressed Replay Attack. In all probability, a Replay Attack is carried out as part of a spoofing attack using IP packet substitution.
In our context, it suffices to know that the spoofing attack is a more complex attack where the hardware identity of a network device is stolen for illegal use of the hardware or to get past authentication.
Replay attack Working
So how does it work? Without going into the data packet level details or the transport layer details of networking, let’s look at this at a conceptual level. Let’s assume there are 2 legitimate entities that are involved in communication over the network.
Entities here could be machines that either assumes a client role or server role depending on the context. Referring to the figure below, Machine-A is the sender(client), Machine B is the receiver(server) and Machine C is the Man in the Middle, the perpetrator of the crime. The situation we assume is an exchange of password for authentication purposes.
Machine A sends the password in an appropriate form to Machine B for authentication and login. This allows Machine A access to assets or services on the server which is Machine B.
Now while sending the password to the server, Machine C has intercepted this message. Since the message is encrypted or hashed or salted (several methods to ensure passwords are not decipherable), Machine C cannot do anything really with this captured information, but if it sends it to Machine B, in other words, replay the information back to Machine B, the server is then tricked into believing it is Machine A again and grants access to machine C too and voila! Machine C is having the same access as Machine A does on Machine B and can do anything which Machine A is authorised to.
You could replace the word Machine with “user” in the above example if it makes it easier to grasp. There are several techniques to listen or sniff data packets being sent over a network which can let you know who the sender is, the receiver, if unencrypted, the exact data being sent and if encrypted the bunch of encrypted data along with the key. If you think that is interesting, and you could use this expertise to good use, you may want to visit a very targeted and well-designed Cybersecurity course.
Replay Attack Prevention
You definitely do not want to be anywhere near such kinds of situations. It is better to take measures to prevent such incidents in the first place. We have a few tricks up our sleeves to tackle these eavesdropping neighbours.
There are at least 4 documented practices known to thwart such attempts of identity or data theft.
- Session Identifiers
This method involves using a unique, randomly generated session ID, for each request, so the previous interaction becomes invalid when the Replay attack is orchestrated.
- One Time Passwords (OTP)
OTP, this one must be familiar to you, is a way to authenticate the user by asking to input the OTP that was dynamically created and sent to the original machine/user over another network, preferably a mobile network.
Without the OTP, the attacker cannot gain access to the system unless the other network or device on which OTP was delivered is also compromised, the chances of which are highly unlikely.
- Nonces and MAC
Nonces are random numbers issued during authentication and can be used only once, rendering a replay attack effectively inactive. Nonces are used along with Message Authentication Codes, that validate or establish the authenticity of the message.
- Timestamps
Timestamps can replace the random number generation concept used in the Nonces and MAC method listed above, by including the timestamp of the message along with a Message Authentication Code (MAC). This isn’t as straightforward as it sounds, so let’s take an example to go through it and this time let’s substitute “user “for “machine”.
User B is a server that periodically sends its timestamp along with a MAC. When User A is ready to send information to User B, also have to add the best estimate about the timestamp on the machine used by User B. User B will allow the connection to User A only if the given timestamp is close enough, within defined tolerance intervals.
Conclusion
That’s all we had on Replay Attack, but if this has ignited a spark in you to know more, learn more and become an expert, take a look at the highly recommended Master Certificate Program in Cyber Security from Jigsaw Academy.
