If an attacker can get into the middle of a conversation, they can effectively read and modify all network communication. In this video, you’ll learn about on-path attacks and how to prevent them.
When we communicate to a web server, we’re usually assuming that our local workstation and the web server are the only two devices involved in this conversation. But attackers have realized that they can get in the middle of this conversation. They can not only see what you may be sending back and forth, but they may be able to modify it as it’s being sent across the network.
We used to refer to this as a man-in-the-middle attack. You’ll commonly see it now referred to as an on-path attack. An on-path attack works by having an attacker sit-in the middle of the conversation, and they can redirect the traffic as you’re sending it back and forth to another device. From your perspective, everything is working normally. You’re sending information out to the web service, and the web service is sending information back to you.
You have no idea that in the middle of this conversation is a third party who’s intercepting that communication. On a local subnet, one simple way to have an on-path attack is through the use of ARP poisoning. ARP is the address resolution protocol. And because there’s no security built in to ARP, we’re able to manipulate where certain devices can send traffic.
Let’s look at how ARP works on a normal network configuration. Let’s say we’ve got a laptop, and it needs to communicate outside of our subnet. So it needs to find the MAC address of the local router. The only thing this laptop knows is that the local router’s IP address is 192.168.1.1. So your laptop will send a broadcast to all devices on the network.
This broadcast has a single message inside of it that says, if you happen to be 192.168.1.1, please respond back with your MAC address. Obviously our router is on this network. It does have the IP address of 192.168.1.1, so it’s going to respond back to that ARP request, saying that I am 192.168.1.1, and here is the MAC address associated with my IP address.
When your laptop receives that message, it makes a note of that MAC address and stores it into a local cache. This means that it doesn’t have to keep sending out an ARP request every time it wants to communicate to 192.168.1.1. It simply uses the MAC address that already exists within its cache.
On most networks, this is the process that occurs whenever a device needs to communicate to a third party. And if you look at the local ARP cache on your computer, you’ll find a number of local IP addresses and the MAC addresses associated with those. But an enterprising attacker can also take advantage of this.
Let’s say that we have an attacker on this network of 192.168.1.14, and you can see the MAC address associated with this device aa bb cc dd ee ff. If this attacker would like to get into the middle of this conversation, it can simply pretend to be the router.
So the attacker will send out an unsolicited ARP response that says, I am 192.168.1.1, which normally would be associated with the router, and my MAC address is the MAC address associated with the attacker’s device or aa bb cc dd ee ff.
When that ARP response is received by the laptop, the laptop says the ARP has changed. Something is different. Let me update my ARP cache, which has the same IP address. But you can see now that the ARP cache has a completely incorrect or spoofed MAC address. This attacker can perform that same ARP poisoning to the router, and now everything that is sent back and forth between these devices must pass through the attacker’s device.
If you want to perform an on-path attack to devices that are not on your network, one way that you could do this is through the use of DNS poisoning, where you modify the entries that are inside the DNS server. This obviously requires someone to have the skills to be able to break into the DNS server and make that change. But if you can modify those DNS files, you can redirect people to whatever IP address you’d like.
If you’re trying to change where one particular device may be communicating, you don’t have to change the DNS server. You can simply modify the local host file that’s on that particular client. This usually causes antivirus and anti-malware systems to throw a message saying that someone’s trying to manipulate one of these very important files that are on your system.
But if you can find a way to modify that client’s host file, you can effectively redirect it to any IP address you’d like. And a third way to poison a DNS conversation is to simply send fake response to DNS requests that are being made. Normally, we’re expecting a DNS response to come back from the DNS server. But if someone can sit-in the middle of the conversation, they can block the legitimate DNS reply and send their own DNS reply with whatever information they’d like.
Let’s take the first example where someone modifies the configuration of an existing DNS server. You can see that professormesser.com is configured in this DNS server with 162.159.246.164. And when a user makes a DNS query to the DNS server asking for the IP address of professormesser.com, that information is provided back to the user, and that IP address is saved in the local DNS cache on that user’s computer.
A skilled attacker, however, could gain access to the DNS server and change what configurations may be inside of that service. So it might change the IP address of professormesser.com to be 100.100.100.100, which by the way also matches the IP address of the attacker. We’re assuming that the attacker would like all of the messages that would normally be sent to professormesser.com to be sent to the hacker’s device instead.
This means that any subsequent requests to the DNS server will be responded back with the poisoned or spoofed IP address, and everyone else who tries to gain their IP address from that service will end up getting the IP address of the attacker.
There are many different ways for an attacker to gain access into these conversations and perform an on-path attack. You might see session hijacking, HTTPS spoofing, or something as easy as eavesdropping over the Wi-Fi connection to cause this on-path attack.
In almost all of these situations, you can avoid these types of on-path attacks by simply using encryption. If the attacker can’t see the information contained within the packets, then obviously your data will remain safe, and an encrypted connection can’t be modified so an attacker would not have a way to inject their own data into your existing data flows.