A replay attack can allow an attacker to access an account without the use of login credentials. In this video, you’ll learn about different replay attacks and how to prevent them.
<< Previous Video: Buffer Overflows Next: Request Forgeries >>
The communication that we send from our computer to other devices on the network will very often have information that a crafty hacker can use against us. This might be a session ID, it might be login credentials, but they want to be able to find the information in those network flows and be able to use it as an advantage during an attack. This means the attacker needs to find a way to gather that network information.
If they have physical access to the network, they can physically install a network tap that will redirect or send a copy of all network traffic to their workstation. If they don’t have physical access to the network, then they need to find some logical way to redirect that information. And one way they might do that is through something like ARP poisoning. Or they might just simply add their own code or malware onto your computer and they’ll use your computer to gather that information and then send it back to the attacker.
If the attacker can capture information that can then be replayed across the network to make it seem as if it was coming from you, this is called a replay attack. And they want to be able to gather session IDs or credentials and be able to use those credentials later on across the network. Although the initial gathering of the information may involve the attacker being on the path between the two devices, that’s not a requirement for the actual replay attack. The replay attack can be done afterwards. The original user does not even need to be on the network at that time.
One very simple kind of replay attack is called pass the hash. This is referring to the hash value that is associated with a password that is sent across the network during the authentication process. If the attacker can gain access to the hash, they may be able to replay that hash back to the server and pretend that they are the original workstation.
In our network here, we have three devices. We have the client device that will be the victim, we have an attacker that’s on the network, and we have the server that is communicating back and forth with the client. During the initial authentication process where the client sends username and password information to the server, what’s usually sent across the network is the username and a password hash. As that information is being sent to the server, the attacker puts something in the middle of the network. This might be a redirection of the network or an ARP poisoning of some kind, and redirects that hash down to their device as well.
That means that they’re going to have a copy of that hash on their computer. Now that the attacker has that hash, they can pretend to be the original user by sending the username and hash information off to the server as if they were doing this from the original client’s workstation. From the perspective of the server, this looks like a normal authentication coming from a legitimate user. And that means that the attacker would then have access to that user’s account on that server.
One way that developers can avoid this type of pass the hash attack is to make sure that the client and the server are always communicating over an encrypted channel such as SSL or TLS. If that channel is sending encrypted data, it doesn’t matter what the attacker gathers. They won’t be able to find any of the hash or anything else inside of that encrypted information.
Another technique developers use is to salt the hash. They might salt it with the session ID. And when that session idea is sent across to the server to authenticate, it’s a one time authentication process. Even if somebody was to gather that information across the network as it was being sent originally, they would not be able to reuse it. And the replay attack of this kind would not be successful.
This is also why we want to be sure that the cookies saved in our browser configuration on our computers are secure. The browser cookies that are on your computer may contain information that an attacker might be able to use for a replay attack. These browser cookies often have information that’s specific to you. It may have personalization details or session management information. And it usually is something that’s very unique to your sessions that you’re using in the browser.
Not only is there personal or private information that might be in these cookies, these cookies can often contain session IDs as well. And if somebody was to gain access to an active session ID, they could pose as you when communicating with another service. The key to a session hijack or sidejack, is for the attacker to somehow gain access to the session ID.
When the client first logs into the server, they are assigned a session ID. And from that point going forward, the victim is including that session ID when communicating with the service. This means that the user doesn’t have to constantly keep logging in with their username and password every time they communicate back to that website server. Instead, they’ll simply send the session ID and that will confirm that the user that’s communicating to the web server has already been authenticated.
If that attacker gains access to that session ID, they could have used that information to pose as the victim and communicate directly to that service without requiring a username or password. This is why it’s important to use an encrypted protocol such as SSL or TLS when communicating across the network, which means that the attackers would have no way to gather that session ID off of the network flows.
For this session ID attack to work, the attacker needs to first get the session information. They might gather that directly from the network using Wireshark or Kismet to gather it from the wired or the wireless networks. If the server has a cross site scripting vulnerability, the attacker could use the server to have session IDs sent directly to the attacker instead of gathering them from the network. Once the attacker has the session ID information, they need to modify the headers that are being sent to the server and they might use a third party utility to be able to do that in real time.
The attacker could also modify their browser cookies to make them look identical to those that would come from the victim’s computer. One way to prevent these types of replay and session attacks is to make sure that all of the communication between both sides is always encrypted. They can’t capture session IDs if it happens to be in this encrypted traffic flow.
Turning on encryption on a web server adds some additional overhead. But is going to protect all of the data that’s being sent back and forth. There are some browser extensions you can get that will force communication to be HTTPS or TLS, but many sites these days will only operate as an HTTPS or encrypted channel. So if you were to go to professormesser.com you will always be connected over HTTPS.
If you’re communicating to a service that doesn’t support HTTPS, or it’s using a different type of communication mechanism, then you may want to use something like an encrypted tunnel to at least have part of the communication flow be in this encrypted channel. That way, if anybody does gather that information on that encrypted flow, they would not be able to use any of the information inside of that network traffic.