Much of the communication that we do across our networks is between two devices. Device A communicates to device B and device B communicates back to device A. The attackers though would like to be able to see everything happening in that communication between those devices. And to be able to do that, they've devised a series of attacks known as onpath attacks. This is how someone gets in the middle of a conversation to be able to monitor and in some cases change the information that's being sent from one device to another. What's interesting about an on path attack is that the end stations that are communicating may have no idea that their communication is being monitored. This means that security software that is monitoring information on the end stations may not have any idea that an onpath attack is taking place. One popular form of onpath attack is one that you can do on a local subnet. This is referred to as ARP poisoning or ARP spoofing. This allows someone to sit in the middle of a conversation and be able to look at all of the traffic going back and forth. One of the reasons that ARP poisoning is able to work so well is that there's no security built into the address resolution protocol. Let's look at a normal ARP communication. You might have two devices on the network. One is a laptop which has an IP address of 192.168.1.9 and you can see that it has a MAC address that ends in 38 delta 5. We also on this network have a router. Its IP address is 192.168.1.1 and its MAC address ends in Bravo Bravo Fox Echo. On this network, the laptop may need to communicate to the router to be able to send information to another subnet. But this laptop only has the IP address of that router and does not have the MAC address. In order to obtain the MAC address, that laptop will send out an ARP request. This ARP request sends a broadcast looking for the IP address of 192.168.1.1. And if we find that device, we would like that device to send back their MAC address. This broadcast is obviously going to be seen by the router. And the router is going to send back a response that says I am 192.168.1.1 and my MAC address is the one listed here that ends in bravo bravo fox echo. Once that ARP response is received by the instation, it is put into a local cache on this device where it is paired up the IP address and the MAC address. Now let's see how an attacker might create ARP spoofing to exploit that communication path. The attacker has an IP address of 192.168.1.14. So it's on the same subnet as the router and the laptop. And you'll notice that the MAC address of this attacker ends an echoech fox. The attacker is going to send an ARP response directly to the laptop. Even though the laptop has not sent out an ARP request because of the way that ARP works, that response will be received by that laptop and will be processed. The attacker's ARP response says that the attacker is 192.168.1.1 and it has a MAC address that ends in echoech fox. You can see that the IP address of the attacker is not that IP address, but it is that MAC address. That means when this laptop receives that response, it will change the information that is contained within the cache. We still have that original 192.168.1.1 IP address. But notice now that the MAC address for that IP address in the ARP cache has been modified to end in echoech fox, which is the same MAC address as the attacker. Now, anytime that this laptop wants to send information to the router, it will instead send that information to the attacker's workstation. Most attackers will perform the same art poisoning to the router and now it can sit in the middle of the conversation and watch all of the traffic being sent between both of these devices. Instead of having the attacker on the network, what if the attacker was on the laptop? This would be an onpath browser attack that takes a proxy software on that browser and uses that to sit in the middle of a conversation. Because the attacker has found a way to install this proxy software onto this local device. All of that communication is being redirected on the browser itself. This looks completely normal to the victim. All of the web pages visited by the victim look perfectly normal and they have no idea that this proxy is sitting in the middle of this conversation. Now all the attacker has to do is wait for you to log in to your bank or some other important site and now they have access to your login credentials. The attacker's software may not even have to send that information to the attacker, but instead exploit that particular vulnerability on the same local system. For example, you might open a browser and visit your bank's website and add your username and password. At that point, the attacker has gathered that information with the internal proxy on your system. From this point, the proxy can begin accessing your bank account directly and could effectively gain access to all of your funds. One place that an attacker could use an onpath attack might be on an open wireless network that you might find in an airport, a coffee shop, or any other public area. This is something called a wireless evil twin where a separate access point is created that has a very similar look and feel as the existing access points on that network. The attacker will create an access point that has the same SSID or network name. It has the same security settings and they might even create a captive portal screen that looks very similar to the one that currently exists. This may work just as being another access point that's on the edge of this network. Or the attackers might increase the power output of their access point to overwhelm the access points that are legitimate. If you're moving through an airport or you're at a coffee shop, you might not even notice that there are multiple access points with the same name that you can connect to. And although the end users think they're connecting to a legitimate network, they're actually connecting to the attacker's access point. Now the attacker can see all of the wireless communication going back and forth and they can simply monitor that data or they can modify the information that's being sent. This is just one of the reasons that you constantly hear us telling you to use encrypted channels when you are communicating across the network. You should certainly be connecting to websites that use HTTPS. That's the secure version of HTTP. And ideally, if you are outside your network on a public network, you are always using a virtual private network or VPN.