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-prev] [day] [month] [year] [list]
Message-ID: <002601c47bd3$a2877a00$fc11010a@msad.brookshires.net>
From: toddtowles at brookshires.com (Todd Towles)
Subject: follow up question...

Preventing ARP poisoning is a very good security measure, but I am not sure
how they made it do it in this case.

 

If you don't know what ARP poisoning is and why it is dangerous, then google
it. 

 

An AP is basically a normal router but for wireless. ARP poisoning allows
for sniffing packets on switched network (not really important on the
wireless side, since you can sniff them out of the air) and is the start of
man-in-the-middle attacks most of the time.

 

-----Original Message-----
From: full-disclosure-admin@...ts.netsys.com
[mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of kyle stapp
Sent: Friday, August 06, 2004 8:20 AM
To: full-disclosure@...ts.netsys.com
Subject: [Full-Disclosure] follow up question...

 

Hey there everyone,

No answer to the question here...just another one.
I caught this and got thinking...I don't know near enough about wireless
systems so here's a question in addition to his.  Does that really make it
more secure(prevent ARP poisoning).  Doesn't that make it easier to
corrupt the network?  How hard would it be to assume the identity of the AP?
What happens if two AP's with the same IP and MAC attempt to get on the same
network?  I been reading and heard a lot more about people infiltrating by
setting up their own rouge AP's.  If I don't understand this right let me
know.
I believe from what has been said that this system forces all comunication
to be sent to the AP and the AP handles routing it to the true destination.
ie
Source=192.168.1.34 FE:EF:FA:CE:BE:EF
Dest=192.168.1.35  FE:EF:FA:CE:BE:EE
AP=192.168.1/255.255.255.0 DE:AD:C0:DE:CA:FE
Situation: Source want to send to Dest.
Source queries as in previous email...Source sends to DE:AD:CO:DE:CA:FE.
AP re-routes this to FE:EF:FA:CE:BE:EE.
----- Original Message ----- 
From: "Dan Taylor, Jr." <dan.taylor.jr@...il.com>
To: <full-disclosure@...ts.netsys.com>
Sent: Thursday, August 05, 2004 11:15 PM
Subject: [Full-Disclosure] 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.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040806/4064d3e8/attachment.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ