If an attacker can sit between you and your data, they’ll have access to a wealth of information. In this video, you’ll learn about man-in-the-middle attacks and what you can do to prevent them.
<< Previous Video: Denial of Service Next: Buffer Overflows >>
We usually consider our network communication to be private. We’re communicating to a server, and we’re assuming that everything between our workstation and the server is not going to be seen by other people. The reality, of course, is far from that. The bad guys would love to get into the middle of that conversation. And they do this using a technique called man-in-the-middle. They’re able to sit between you and that other device and be able to watch all of the traffic going between point A and point B.
The bad guy acts as the middleman. It’s receiving information from one device, looking at what’s inside of it, and forwarding it on to another device. Neither end station realizes that there’s someone in the middle who is sitting between that conversation. And that’s the secret of man-in-the-middle, is that it is completely invisible to the end stations.
There’s a technique that the bad guys use called ARP poisoning. They’re able to use some of the functions of ARP because there is no security built into the Address Resolution Protocol. And by taking advantage of that lack of security, it’s very easy for the bad guy to create a man-in-the-middle when they’re sitting on the same IP subnet as two other devices.
Here’s how this process works. We’ve got two devices on this network. There’s a workstation, this laptop, that is 192.168.1.9. And we also have a router on this network that is 192.168.1.1. And you can see the Mac addresses for each of those.
Now normally, when the workstation needs to communicate out to the router, it needs its Mac address. So it sends an ARP request asking who out there has the Mac address for 192.168.1.1. That’s sent as a broadcast to everybody on the subnet, which means this router will see that request, and it will respond back saying, oh, I’m 192.168.1.1, and here is my Mac address, 00095 bravo delta 4 bravo bravo fox echo.
And when that information gets to the workstation, it will store that information so that it doesn’t have to constantly ask over and over for that Mac address. It stores it and makes a note that, if I need to get to 192.168.1.1, I’ll use this Mac address to communicate. It’s this ARP information the bad guys will take advantage of.
Here’s our bad guy at the bottom. His IP address is 192.168.1.14. And you can see the Mac address associated with him. It’s aabbccddeeff. That should be something easy to look for. What the bad guy will do is send its own ARP request to the workstation, saying that I am 192.168.1.1, and here is my Mac address. The end station sees that and puts into the ARP cache the updated information. So now the ARP has changed, and anytime this workstation is going to send information to the router, it’s going to send it to this device first, who will then forward it on. He is now the man in the middle.
Let me give you a practical example of performing an ARP poisoning. I have a few windows up on the screen. There’s a browser window we’re going to use to log in to my local wireless router. We’ve got a terminal screen here that we’ll use to look at my local ARP cache. And then we have a remote desktop connection to a third-party device that is running a utility called Ettercap. This Ettercap application is specifically designed to provide man-in-the-middle functionality. And we’ll be using this utility to sit in the middle and watch everything going back and forth.
The first thing I’d like to do is to look at the ARPs that are currently stored in the ARP cache on my machine. So I’m going to type a command, arp-a, and it’s going to list out all the IP addresses and the Mac addresses associated with those IP addresses. The device we’re going to communicate to is 10.1.10.2. And you can see the Mac address of that device ends in 403f. That is indeed the Mac address of that wireless access point, and if I was going to communicate to 10.1.10.2, it would be communicating directly to that Mac address.
What we’re going to do is tell Ettercap to sit in the middle and use that ARP poisoning functionality to now look at everything going back and forth between my workstation and the wireless access point. To do that, I’m going to choose on Ettercap that I’m going to sniff the communication. And I’m going to use what they call unified sniffing to sniff all the traffic going in and out of one particular interface. And on my device, that is en0.
So now it has started up. It’s now watching anything that happens to come over that interface. But because this is a switched configuration, it’s not going to see the communication back and forth between my workstation and the wireless access point. So we need to set up some targets into this. I can either have Ettercap list out a number of IP addresses, or I can specify the IP addresses myself by selecting the targets myself. And I can tell Ettercap what I’d like these targets to be.
The first target is going to be my workstation. And I know my workstation is 10.1.10.249. And I also want to put the target in of the wireless access point. And I know that its IP address is 10.1.10.2. Those are my two targets. And when I put those in, I can then tell Ettercap to start MITM, man-in-the-middle ARP poisoning.
And when I choose that option– and I’m just going to use the default parameters– it’s going to say that there are ARP poisoning victims now that I’ve set up on this connection for group one and group two. It’s going to start performing a man-in-the-middle across both of those. Now the poisoning is set up, and you can see that Ettercap does show there’s group one, which shows the 10.1.10.249– that’s my workstation– and group two that shows 10.1.10.2.
If we go back to our computer and perform another arp-a, remember that the 10.1.10.2 originally had a Mac address that ended in 43f. And now if we perform the same arp-a, you’ll notice now the Mac address has changed. So the man-in-the-middle ARP poisoning is currently in effect.
And if I turn on Ettercap, show that screen, and then go to that IP address, 10.1.10.2, you will see that the first thing that pops up is the message asking for username and password. This is already cached in the browser. So you’ll see that [INAUDIBLE] even captures that first request, which from 10.1.10.2 the user is admin and the password is password1. That is the correct username and password.
If I add in admin and password1, it will capture that information again as it’s going through. And now I’m logged into the wireless access point. And because Ettercap had a man-in-the-middle ARP poisoning, it’s able to see all of the information going back and forth, even though it’s not directly connected to either my workstation or the wireless access point.
In our ARP poisoning example, we needed to be on the local subnet where these devices were. And the bad guys, of course, are not usually on your local network. So instead, what they’ll do is perform a man-in-the-middle, but they’ll do it from inside the browser. We call this a man-in-the-browser attack.
They create a proxy on your system, and simply send all the communication in and out of the proxy on the same computer that you’re using. There’s obviously huge advantages for the bad guys to do this. They can not only see all the traffic that normally would be encrypted across the network because they’re on your local machine where the traffic is not encrypted, and everything to the end user looks the same as it always does. And of course, they don’t need to be on your local network. The man-in-the-browser can, for example, wait for you to log into your bank, capture those bank credentials, and then send that information off to the bad guys, who can then later on log in to the bank and perform their own functions.
This obviously requires that the bad guys first install this malware onto your machine that acts as the middleman. But once it’s inside the browser, it can simply wait for that log into your bank. And at that point, on the same machine, they can begin performing their own functions behind the scenes that you don’t even see. But because they already have your credentials and they’re part of your browser, they can now access your bank account and perform any number of functions because they now have all of the credentials and all of the capabilities as if they were you sitting in front of your computer.