Even if the bad guys can’t hack into your system, they may be able to temporarily morph into something that looks exactly like you. In this video, you’ll learn how replay attacks can be used to gain inappropriate access to devices and how software developers can protect against replay attacks.
<< Previous Video: Denial of ServiceNext: Spoofing >>
There is a lot of very important security information that is sent over a network. There’s authentications that occur, user names are sent, passwords are sent. And a bad guy can take advantage of these with a replay attack.
To be able to perform this replay attack, the bad guy needs access to the network information. So they’re either going to physically tap the network, so that they can receive a copy of everything that goes across. Maybe they sit in the middle by doing something called ARP poisoning. Or maybe they install malware on the victim’s computer and simply have the victim’s machine send the bad guy directly everything that was going across the network.
At this point, the bad guy will pick out the pieces of that information that will allow them to impersonate the original user. And then they’ll replay that information across the network. Here’s an example of how a replay attack might happen.
I have me, on my system. I’m communicating to a server and authenticating to that device, through a switch. And the bad guy has gained access to the switch and has told the switch to also send all the traffic down to the bad guy’s laptop. Well, I’m of course going to authenticate to the server. So I’ll send my packet through the network. And it will then complete its process to the server. But, of course, a copy of that has now been sent to the bad guy.
So he’s captured that authentication process. That’s probably going to be my user name sent in the clear and probably a hash password. You don’t generally see passwords being sent in the clear across the network any longer.
Since the bad guy now has my user name and my hash password, he’s going to attempt his own authentication request using that captured information. And now that that goes to the server and is captured by the server, the bad guy gains access. Because the server thinks that information came directly from me.
These days when you’re using authentication like this across the network, we usually take advantage of a capability called salting the password. There’s usually a session ID that’s only in use for the duration of that session. Even if the bad guy was able to gather the session ID, the username, and the hash password, and use all of them together to form a valid authentication attempt, the server would know that that session ID was no longer available. And the entire process would fail. And the replay attempt would not be successful.