4

The Scapy documentation gives the following example of ARP Cache Poisoning: 

send(Ether(dst=clientMAC)/ARP(op="who-has", psrc=gateway, pdst=client))

Question 1:
My understanding is that this is the broadcast of an ARP request from a client. Shouldn't the ARP Poison be executed by the attacker responding with: 

send(Ether(dst=clientMAC)/ARP(op="is-at", psrc=gateway, pdst=client))

Question 2: In a post on stackoverflow about Scapy, the OP posted:

This sends the victim an ARP reply packet with the local machine masquerading as the router:

send(ARP(op=ARP.is_at, psrc=router_ip, hwdst=victim_mac, pdst=victim_ip))

This sends the router an ARP reply packet with the local machine masquerading as the victim:

send(ARP(op=ARP.is_at, psrc=victim_ip, hwdst=router_mac, pdst=router_ip))

In both of these packets, the hwsrc field is filled by default with the local machine's MAC address.

But the Scapy documentation doesn't mention that hwdst is required. I'd like to know why.

Question 3: In the Scapy documentation:

send(Ether(dst=clientMAC)/ARP(op="who-has", psrc=gateway, pdst=client))

But in the OP's post from Question 2, the Ether(dst-clientMAC) is not supplied. Does that mean it's not required?

Thanks.

User137481
  • 223
  • 1
  • 4
  • 14

1 Answers1

8

In computer networking, ARP spoofing, ARP cache poisoning, or ARP poison routing, is a technique by which an attacker sends (spoofed) Address Resolution Protocol (ARP) messages onto a local area network. Generally, the aim is to associate the attacker's MAC address with the IP address of another host, such as the default gateway, causing any traffic meant for that IP address to be sent to the attacker instead. Wiki

As it is mentioned in Scapy documentation,

ARP cache poisoning attack prevents a client from joining the gateway by poisoning its ARP cache through a VLAN hopping attack.

What they mean by that is that the poor client will not be able to send his packets to the gateway (Access Point in this case) and will fail to communicate with external resources. Note, however, that the very same client will still be able to communicate with other hosts within the VLAN. Even with the attacker (assuming it is also connected to the same WiFi network).

Let's go through this attack step-by-step.

Before, we move further, let's check the current ARP table on the Client side (before the attack is executed). On Linux to view the ARP table you need to run the following command:

$ sudo arp -n

Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.1              ether   54:f6:15:f5:51:55   C                     wlan0

As you can see, the ARP table has only one record which lists the Gateway IP address (192.168.1.1) and it's MAC (54:f6:15:f5:51:55).

When the Attacker executes the following command in Scapy:

send(Ether(dst=clientMAC)/ARP(op="who-has", psrc=gateway, pdst=client))

it creates and sends the following packet:

  1. At the Ether layer, the destination MAC address dst is set to point to the Client's (victim's) MAC. At the same time, Scapy automatically fills in other Ether layer fields, most importantly, the src field which is set to attacker's MAC address. This means that on Ether layer the packet seems to come from the Attacker. Other Ether layer fields remained unchanged and contain default values. You can see it yourself if you run the following command in Scapy:

    a = Ether(dst="clientMAC") a.show()

  2. Now, on IP layer the attacker crafts an ARP request packet, in which he sets the psrc (source IP) field to point to the IP of the gateway node (AP in this case). Now, remember that previously, on the Ether layer Scapy filled in the src field for us and set it to point to Attacker's MAC address. This means, that the final packet which is sent to the Client (victim) will look like it came from host that has Attacker's MAC and Gateway's IP address. We will get to it later. For now, let's move on. Finally, Client's IP address is set as a destination for the packet in a pdst field.

  3. The packet is created and sent to the Client (victim).

The Client receives this packet and checks the packet's content. It sees that the ARP request arrived from Gateway IP (let's assume it's 192.168.1.1). It checks the MAC address field psrc in the Ether layer of the packet (let's assume it's a9:2b:24:9c:fd:c7) and updates it's ARP table, which now looks as following:

$ sudo arp -n

Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.1              ether   a9:2b:24:9c:fd:c7   C                     wlan0

As you can see the IP address remained the same, but the MAC address changed. So, now, whenever the Client sends packets to the Gateway node, it actually sends them to the Attacker's MAC. If the Attacker's goal is to prevent the Client from communicating with the Gateway, these packets will be dropped and never delivered to the desired destination.

While the Attacker keeps sending crafted ARP packets to the Client, the Client will not be able to communicate with the Gateway. Once the Attacker stops, the real ARP request from the Gateway with real IP and MAC addresses will eventually arrive to eh Client restoring the normal communication. That is why, you, as an attacker, would probably want to create a loop for sending malicious packets, like this:

sendp(Ether(dst=”CLIENT-MAC”)/ARP(op="who-has", psrc=”GATEWAY-IP”, pdst=”CLIENT-IP”), inter=0.2, loop=1)

With this never ending loop, you effectively jam the communication between the Client and Gateway.

Igor
  • 121
  • 1
  • 3