Gaining access to a traffic flow can be challenging for any attacker. In this video, you’ll learn how ARP poisoning and DNS poisoning can be used to perform on-path network attacks.
Spoofing is a term that describes when one person or device pretends to be another person or device. For example, a fake web server would be a spoofed web server. A fake DNS server– you’re spoofing the DNS server.
If you’ve ever received an email that says that it came from a person, but it really did not come from that person, then you’re a victim of email address spoofing. And if you’ve received a phone call, and the number on the screen is not really the number of the person who’s calling, then you’re also a victim of caller ID spoofing.
Spoofing is a technique that allows an attacker to have access to a system or a person that normally they would not have. And this is very commonly used for techniques such as on-path attacks, where they can sit in the middle of a conversation and be able to monitor or even change the contents of that conversation.
One way that a third party could sit-in the middle of a conversation is through the use of ARP poisoning. This is also called IP spoofing, where the attacker is pretending to be an IP address that they really are not. In this example, we have two devices on the network. We have a 192.168.1.9 IP address, and you can see the MAC address associated with that device. We also have a router. That router is 192.168.1.1. And obviously, the router has a completely different MAC address.
The way that Address Resolution Protocol, or ARP, works is that the device on one side needs the MAC address of a device that it wants to communicate to. All it really has is the IP address. So if the 192.168.1.9 needs to communicate to. 192.168.1.1, it first needs to determine what is the MAC address of 192.168.1.1. And that is what we would use the address resolution protocol for.
ARP will send out a message to everyone on the network using a broadcast. Then that broadcast will ask, who has 192.168.1.1? I need that MAC address. And the device with that IP address of 192.168.1.1 will respond back to the requester with the MAC address of that particular device. You can see in this example the MAC address that’s responded back is exactly the same MAC address associated with this router.
Once the original device has that response, it will cache that information into a local ARP cache on that machine so that it now knows that. 192.168.1.1 is the MAC address that it has received as part of that address resolution protocol.
You’ll notice that there’s no authentication or special security associated with that ARP process, and it’s that lack of security that the attacker will take advantage of. This example, we have an attacker who is at 192.168.1.14, and you can see they have a very different MAC address associated with their device. They’re going to send an ARP response to the 192.168.1.9 device even though that device did not originally send a request.
ARP will interpret and take any responses that are sent across the network. And in this case, the attacker is going to spoof the IP address of the router. And this attacker says I am 192.168.1.1, and this is the Mac address associated with that IP.
You can see in this example the MAC address that’s being sent as part of that ARP response is the MAC address of the attacker and not the MAC address of the legitimate router. When that ARP response is received, this ARP cache is now updated with the new information. So now 192.168.1.1 has a completely different MAC address than the one that was put there originally. The attacker has effectively spoofed the IP address of that router so that the victim now believes that the router is located at a different MAC address.
From this point forward, any traffic sent from this device to the router will first be sent to the attacker. And very commonly, the attacker will then forward that information on to the legitimate router. This means that neither the victim device nor the router realize that there is an attacker in the middle of the conversation that is intercepting and forwarding all of the traffic sent between these two devices.
Another type of spoofing that can take place is DNS spoofing. This is also referred to as DNS poisoning, where we are modifying either information contained on the DNS server itself, or we’re modifying the responses that are being sent from the DNS server.
We could do this without the DNS server itself by modifying the host file that’s on the client. This host file has a higher priority than DNS responses, and everything in the host file will always take precedence over anything else that may be on a DNS server.
This DNS poisoning works by sending fake responses to legitimate DNS requests. And if you’re not modifying information on the DNS server itself, this will require changing the information on the fly as it is sent in real time between the DNS server and the victim machine. This is a perfect example of where on-path attacks would be perfect to execute a DNS poisoning.
Let’s see how this DNS poisoning can be used to modify the results of a DNS response sent to different devices on the network. In this example, we have two users, a user 1 and a user 2. These two devices will be querying a DNS server that is also on the network. And, of course, you’ll notice we also have an attacker on the network as well.
The legitimate IP address for professormesser.com is stored currently in this DNS server. And if user 1 wanted to receive that information, it would simply make a request to the DNS server for professormesser.com. And that DNS server would respond back with the IP address of that particular host.
Once that’s received by user 1, it’s added to a cache on the user 1 machine. And you can see in this case that the IP address that is stored for professormesser.com is the same as the one that is located on the DNS server.
At this point, the attacker could use ARP poisoning to sit in the middle of the conversation between the DNS server and another device, or the attacker could hack into the DNS server and change the configuration of the DNS server itself. If they do that, they’ll be able to change the IP address of professormesser.com to the IP address of the attacker’s workstation.
Now, all subsequent requests to the DNS server for professormesser.com will return the poisoned address instead of the legitimate address. User 2 will make that request to the DNS server, and the response from the DNS server does indeed send the spoofed address, or poisoned address, to the user 2 workstation. And you can see that that is found on the user 2 cache. When that user now wants to communicate to professormesser.com, instead of going to the legitimate IP address for that web server, they will be redirected to a web server that’s running on the attacker’s IP address.