Re: Re: MAC Spoofing Prevention in Wireless

[Jamie Ivanov <jamie.ivanov () gmail com>]

The DHCP server would be helpful but a static IP would render that
form of detection useless (unless there is some form of encrypted
dhcp, no idea of that technology exists). Using a combination of time
of association and which AP the host is on and whether it is actively
associated will be the best I can come up with off the top of my head.

Say Client1 associated with WAP1 and is still connected, Client2
spoofed Client1's MAC (even with a static IP) and associated sometime
after. What are the odds that in a multi-wap environment that both
clients will be on the same WAP? If Client1 is STILL associated on
WAP1 and Client2 tries to connect on WAP7, the controller will be like
"fuck no, someone with that mac is already auth'd on another WAP". The
more waps you have the more true that would become.

My only other suggestion is an additional transport protocol that can
tag packets in a specific fashion to determine the true/original
client vs. a spoofed interface. I doubt client isolation would be
beneficial here.

But because this is rather hard to do, it would be wise to have
additional security measures in place to prevent this scenario from
occurring. While I have experience in *some* cisco wireless equipment
in standalone, I can imagine that cisco has some specific enhancements
that could do something similar without you having to generate a
custom solution.

I've been up for 3 days with less than 5 hours of sleep, be gentle...

On Thu, Jul 14, 2011 at 12:53 PM, David Gillett <gillettdavid () fhda edu> wrote:
>  And what are they going to tell you?
>
>  IF you're very lucky, you might see the same MAC address trying to renew
> more than one IP address -- but that can only happen if one of the clients
> got its lease from somewhere else.  You'll probably just see some address
> requests from MACs that the server thinks already have valid leases -- and
> THAT happens all the time, perfectly legitimately.
>
>  Finding out what MAC addresses are on your network IS straightforward.
> Detecting that one or more of them are not unique, though, is NOT -- unless
> you can see that they are on different physical ports, or associating to
> different APs, or generating both associated and non-associated wireless
> control traffic.  And none of those things is going to be visible to or
> logged by your DHCP server....
>
>  Any obvious/straightforward method of detecting duplicate MAC addresses
> has to presume some OTHER mechanism for identifying distinct clients.  Since
> in the standard/portable case, distinct MAC addresses ARE the mechanism for
> making that distinction, a working solution, if one exists, is going to
> depend on something non-standard or non-portable or with an otherwise
> strange definition of "straightforward".
>
> David Gillett
>
> ________________________________
>
> From: Brent Jesmer [mailto:BJesmer () platformsolutions com]
> Sent: Wednesday, July 13, 2011 14:56
> To: David Gillett; security-basics () securityfocus com
> Subject: RE: Re: MAC Spoofing Prevention in Wireless
>
>
> So checking the dhcp logs or dhcp client tables isn't straight forward?
>
> Brent Jesmer
> Platform Solutions Inc.
> Sr. Security Consultant
> Sent via DROID. Please excuse any mis spelling.
>
>
> -----Original message-----
>
>
>        From: David Gillett <gillettdavid () fhda edu>
>        To: Brent Jesmer <BJesmer () PlatformSolutions com>,
> "security-basics () securityfocus com" <security-basics () securityfocus com>
>        Sent: Wed, Jul 13, 2011 21:53:31 GMT+00:00
>        Subject: RE: Re: MAC Spoofing Prevention in Wireless
>
>
>                   It's not "straightforward" at all.  How do you tell that
> there are two
>        MACs the same on the network?
>
>          On a wired network with STP enabled, you know there's *something*
> strange
>        going on if you see packets with the same source MAC address from
> more than
>        one wired interface.  But that simply doesn't translate to wireless.
>
>        (HINT:  MAC addresses are supposed to be unique on a subnet/segment.
> If
>        they're not, your network is out of spec and unlikely to work
> properly; any
>        communications that happen to work are just good luck and may not be
>        reproducible.)
>
>        David Gillett
>
>
>        -----Original Message-----
>        From: bjesmer () platformsolutions com
> [mailto:bjesmer () platformsolutions com]
>        Sent: Friday, July 08, 2011 12:31
>        To: security-basics () securityfocus com
>        Subject: Re: Re: MAC Spoofing Prevention in Wireless
>
>        The concept is fairly straight forward. The AP looks to see if there
> are 2
>        MACs of the same on the network and disallows the second one on the
> network.
>        Not having worked with the Aruba yet, i would try a deauth attack
> against
>        the mac you are going to spoof and then try to get on. If you can
> deauth
>        that client and get on before it, you might be able to get in.
>
>
> ------------------------------------------------------------------------
>        Securing Apache Web Server with thawte Digital Certificate In this
> guide we
>        examine the importance of Apache-SSL and who needs an SSL
> certificate.  We
>        look at how SSL works, how it benefits your company and how your
> customers
>        can tell if a site is secure. You will find out how to test,
> purchase,
>        install and use a thawte Digital Certificate on your Apache web
> server.
>        Throughout, best practices for set-up are highlighted to help you
> ensure
>        efficient ongoing management of your encryption keys and digital
>        certificates.
>
>
> http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727
>        d1
>
> ------------------------------------------------------------------------
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
> Securing Apache Web Server with thawte Digital Certificate
> In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, 
> how it benefits your company and how your customers can tell if a site is secure. You will find out how to test, 
> purchase, install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for 
> set-up are highlighted to help you ensure efficient ongoing management of your encryption keys and digital 
> certificates.
>
> http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
> ------------------------------------------------------------------------



-- 
Jamie Ivanov / KC9LFD
m.608.399.4252
http://www.linkedin.com/in/jamieivanov
-- -- -- -- -- -- -- -- -- -- -- --
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other
than the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and
delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended
recipients is not authorized and may be unlawful.

------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------