full-disclosure - Static ARP Replies?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <9036df470408052015edc3f7d@mail.gmail.com>
From: dan.taylor.jr at gmail.com (Dan Taylor, Jr.)
Subject: Static ARP Replies?

I have encountered a few 802.11b public access points (I can't
remember the vendors, but they were for hotels) that seem to have
built-in ARP cache poisoning prevention.  I found it nonetheless
impressive and am looking for solutions to implement it (presumably
with my own wireless card and hostap drivers).

Here's what happens on one of these networks:

Say the AP's MAC address is DE:AD:C0:DE:CA:FE, with the IP of
192.168.1/255.255.255.0, and I send out an ARP request for hosts
192.168.1.2-254.

Say my MAC address is FE:ED:FA:CE:BE:EF, with the IP address of 192.168.1.100
--> ARP broadcast (source FE:ED:FA:CE:BE:EF destination FF:FF:FF:FF:FF:FF)
--> Who has 192.168.1.2?  Tell 192.168.1.100

--< ARP Reply (source DE:AD:C0:DE:CA:FE, destination FE:ED:FA:CE:BE:EF)
--< 192.168.1.2 is at DE:AD:C0:DE:CA:FE

I'm assuming this is a rather effective way of not only preventing ARP
poisoning attacks, but making it so that all communication is
virtually done between the client and the access point).
Has anyone seen this feature implemented in any other access points? 
To what extent does this work and/or it's behavior on layer-2
broadcasting or client to client (mac address to mac address)
communications?

Thanks.