Re: Strange WLAN behavior

[Tisiphone <tisiphne () gmail com>]

Interesting note:

MAC spoofing aside,

OUI 00:04:0E:xxx

I show this as this manufacturer:
00-04-0E (hex) AVM GmbH
00040E (base 16) AVM GmbH
Alt-Moabit 95
10559 Berlin
GERMANY

They make a small selection of DSL, and ISDN modems. Their primary
selling point seems to be VoIP and DECT integration.
http://www.avm.de/en/Produkte/FRITZBox/index.html

They can be flashed with a ddwrt alternative called Freetz:
http://www.renemoser.net/2009/01/freetz-avm-fritzbox-firmware-extension/
http://trac.freetz.org/

Which finally, in newer models gives the capacity for all sorts of
interesting sniffing, even DECT:
https://dedected.org/trac/wiki/Fritzbox7270-Sniffer
http://trac.freetz.org/wiki/packages

Of course, if the MAC is spoofed, then this is irrelevant. But it
seems like a rather fun box to play with... and you might want to look
into this further if you also use a DECT/UPCS telephone...

On Wed, Mar 31, 2010 at 10:59 AM, Adam Mooz <adam.mooz () gmail com> wrote:
> > Depending on how the malicious AP is setup, the first two will not
> > work at all.  MAC addresses are also trivial to spoof, even
> > automatically.  Cloaking your own SSID means that one has to send out
> > a probe for it, which can be happily answered by a rogue AP.  If the
> > rogue AP is using KARMA (or worse, Karmetasploit), it will be
> > perfectly happy to answer as just about any mainstream service, saving
> > all of the associated passwords and keys and forwarding the traffic on
> > (while, of course, monitoring everything going by, and maybe even
> > sending back other helpful things in addition to the requested
> > information).  Changing the password may work only so long as one
> > doesn't inadvertently connect to the rogue AP again.
>
> The point is to make this as difficult as possible to prevent just the
> scenario you've outlined; them getting back into your AP after theirs
> goes down.  If you change your password, cloak the SSID, and use MAC
> address filtering this may push the rogue into exploring the other
> networks in the area and ignoring yours, if only temporarily.  Short
> of implementing RADIUS or some other form of enterprise authentication
> there isn't a whole lot that can be done.
>
> ----------------------------------------------------------
> Adam Mooz
> Blog: http://www.adammooz.com
> LinkedIn: http://www.linkedin.com/ln/adammooz
>
>
>
> On Tue, Mar 30, 2010 at 6:54 PM, Jarrod Frates <jfrates.ml () gmail com> wrote:
> > On Tue, Mar 30, 2010 at 11:58 AM, Jon Janego <jonjanego () gmail com> wrote:
> > > By default, Windows XP will probe for all the access points you've set
> > > up and you want to remove any reference to the "hijacked" AP.
> >
> > I believe that there was a patch that was integrated into SP3 that
> > addressed this behavior, stopping it by default.  But clearing out the
> > wireless configuration is probably still a good idea.
> >
> > On Tue, Mar 30, 2010 at 10:30 AM, Adam Mooz <adam.mooz () gmail com> wrote:
> > > It sounds like there's a rogue/malicious AP hijacking your internet, I'd suggest you cloak your SSID, implement MAC 
> > > address filterting, and change your password ASAP.
> >
> > Depending on how the malicious AP is setup, the first two will not
> > work at all.  MAC addresses are also trivial to spoof, even
> > automatically.  Cloaking your own SSID means that one has to send out
> > a probe for it, which can be happily answered by a rogue AP.  If the
> > rogue AP is using KARMA (or worse, Karmetasploit), it will be
> > perfectly happy to answer as just about any mainstream service, saving
> > all of the associated passwords and keys and forwarding the traffic on
> > (while, of course, monitoring everything going by, and maybe even
> > sending back other helpful things in addition to the requested
> > information).  Changing the password may work only so long as one
> > doesn't inadvertently connect to the rogue AP again.
> > --
> > Jarrod Frates
> > GAWN, GCIH, GPEN
> >
> > ------------------------------------------------------------------------
> > 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
> > ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
> 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
> ------------------------------------------------------------------------

------------------------------------------------------------------------
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
------------------------------------------------------------------------