3

I am programming with Python and his partner Scapy. I am facing a situation that i dont know if it is a normal behavior from ARP Protocol or some another problem.

I have this scenario:

1- A vm machine (1) sending an "ARP Request" to another vm machine (2) with Spoofed Source MAC Address field (generated with Scapy).

2 - The vm machine (2) receives that "ARP Request" with the Source MAC Address field Spoofed and RESPONDS that with an "ARP Reply". The strange part is that the vm machine (1) receives that.

Notes: I have confirmed with Wireshark that the first packet (ARP Request) gets on the vm machine (2) with the Source MAC Address Field REALLY spoofed. And the promiscous mode on networks interfaces are disabled, so, the vm machines only receive packets that are REALLY destined to their interfaces.

So, my questions:

a) Is it the normal behavior from ARP Protocol?

b) Because vm machine (1) has another MAC Address configured on your interface (the real one), how the response packet sent from vm machine (2) with another MAC Address on the Destination field (that is spoofed, so, not even exists on the network) arrives to vm machine (1) and is effectively processed by vm machine (1) like a valid "ARP Reply"??

StarkBR
  • 227
  • 8
  • 15
  • Are you talking about ARP caching? If machines receive a ARP response (not destined to it), it will cache it in its local cache. After all, if someone announces "00-1F-29-52-E7-81 is at 1.1.1.1" why not add an arp entry mapping 1.1.1.1 -> 00-1f-29-52-e7-81. – David Z. Apr 21 '12 at 01:13
  • Also can you check if there are any other packets from vm machine 2 to vm machine 1 that is being sent on broadcast address? vm machine 1 may be sending arp announcements (which even on interfaces with promiscuous mode disabled will receive). – David Z. Apr 21 '12 at 01:20
  • Hi David, I will exemplify (**Packet 1 - Request**) -- Who has IP 192.168.2.2? -- Source MAC Address: 22:22:22:11:11:11 (Spoofed)- Destination MAC Address: ff:ff:ff:ff:ff:ff (Broadcast) ******** (*Packet 2 - Reply*)- IP 192.168.2.2 is at 44:44:44:44:44:44 -- Source MAC Address: 44:44:44:44:44:44 -- Destination MAC Address: 22:22:22:11:11:11 (Spoofed) **** Question: How Packet2 (reply) come back to the vm machine (1) if the packet contains a Fake Destination MAC Address that is not the real MAC Address configured on the vm machine (1)'s network iface? – StarkBR Apr 21 '12 at 01:28
  • How are you confirming that Packet2 has come back to the originating VM machine? Are you taking a packet capture (is the packet capture set to promiscuous mode) or are you just checking the arp cache on VM2. In the packet capture on the first machine, are you sure it is not recieving any broadcast arps with destination MAC set to broadcast mac address. – David Z. Apr 21 '12 at 01:39
  • I'm taking a capture with Wireshark. The promiscuous mode is disable on the capture from both machines. The ARP cache on VM2 has only one entry (Spoofed IP to Spoofed MAC), the real MAC from VM1 not appears. On the VM1 i see on the capture that the ARP Reply packet arrives back: even with the fake MAC on the Destintation field that doesn't match with real MAC on network iface of VM1 – StarkBR Apr 21 '12 at 02:02
  • I'm just starting to think that ARP (as it stays on a lower layer) maintains a type of "cache", so, if an ARP REQUEST packet was send (even with spoofed source) it nows that packet will come back, that way, it will treat it even with the MAC Destination field mismatch. IS IT POSSIBLE???? – StarkBR Apr 21 '12 at 02:06
  • VM1(ARP Request) - Ubuntu LTS 10.04 // VM2(ARP Reply) - Windows XP Professional SP3 – StarkBR Apr 21 '12 at 02:19
  • It might be worth checking if this behavior works the other way to rule out any OS issues. If it's not gratuitous arps. It sounds like that either promiscuous mode is not actually configured or is being ignored. – David Z. Apr 21 '12 at 02:32
  • David, tks for the help man. So, it's not Gratuitos ARP,it's ARP Request and ARP Reply, respectively. To work with the question of promiscuous mode, i did put another VM on the game. I did set promiscuous mode ON for the capture for this VMs, and VM3 receives the ARP traffic related to VM1 and VM2,as was expected. Next, i did set promiscous mode OFF again and repeat the test. The result show me that VM3 did not receive the traffic,as was expected too. So,it appears the promiscuous mode is not the reason of the situation.Do you think that can it be a normal behavior of ARP? Make sense to you? – StarkBR Apr 21 '12 at 02:44
  • This doesn't sound to be normal ARP behavior. If traffic isn't even making it to the VM (dropped at the NIC) then I'm questioning if the OS even has anything to do with it. – David Z. Apr 21 '12 at 02:52
  • Yeah, i don't know...the behavior that is ocurring is not the one i expected and I don't know how to confirm that... – StarkBR Apr 21 '12 at 10:35

1 Answers1

0

The strange thing I see here that how the ARP Reply bounced back to VM(1) although it uses a spoofed MAC address..

Well, try to check on the ARP table on VM (2) and see which MAC record it holds for VM (1); probably you'll find the legitimate MAC address cached due to some communications before you spoof the MAC address.

MYZ
  • 711
  • 1
  • 5
  • 7
  • I made it. The ARP table from VM (2) shows the Spoofed IP and reference it to the Spoofed MAC. So, the real MAC from VM (1) not even exists on VM (2) ARP table but the ARP Reply is send back to the VM (1), remembering that it arrives on VM (1) with the Spoofed MAC Address on Destination Field. – StarkBR Apr 21 '12 at 01:43
  • So, there are no references for the real MAC from VM (1), but the ARP Reply is still sending back to VM (1) by VM (2). – StarkBR Apr 21 '12 at 01:53
  • well then, what is the virtualization software you use, and what type of virtual network you implement? – MYZ Apr 21 '12 at 02:33
  • I'm using Vmware Workstation. I have created a virtual network only between the vms. No bind to my physical iface was setted. No promiscuous mode setted on my captures. To make a test, i put 3 differents vms connected on the same virtual network (with no promiscuous mode) and the traffic occurs the same way between vm1 and vm2, vm3 did not receive the traffic, as was expected. – StarkBR Apr 21 '12 at 10:32