Josh Wright earlier this year posted a couple wireless security papers which are quite valuable. First he talks about wireless framing; basically a blitz through how wireless 802.11 works. There is also a paper about 5 wireless threats we may not know about. In the list, Wright mentions 802.11n (Greenfield mode) and Bluetooth rogue APs. I think scanning for rogue APs using kismet is becoming fairly common in concerned organizations (or by concerned geeks anyway). But how does one begin to scan to find these other wireless technologies?
BTScanner can be used, plus there are other papers on pentest.co.uk.
Bluescanner should also work, although I’m not sure if this is the same tool that was absorbed into Aruba Labs…
I’m sure there’s more, I’m just not coming up with them at the moment.
AirMagnet’s Laptop Analyzer will detect 802.11n signals. I’m not sure what else is available out there for this new tech.
I’m sure pretty soon there will be scanners for detecting vulnerable wireless keyboard/mice devices (pdf)) as well…
LonerVamp and Josh Wright both totally rule.
From what I understand, 802.11a is the worst of all, being the most likely to not only be rogue (and often missed), but also the least secured.
I’ve been so curious as to what Josh Wright has planned for his Shmoocon talk. This SANS article explains some of it — network impersonation of PEAP by faking the SSID and RADIUS in order to steal credentials or attack the host.
The Bluetooth rogue AP idea is interesting, but think about the other worse possibilities. For example, many hand radios are capable of packet data — and there are even ones that go past 2W that don’t even require a license. Ricochet or an EVDO setup could even be setup with a private, non-carrier link.
Speaking of rogue AP’s, try out an IRda rogue AP. The shorter the range, the less likely to be found, right? Or possibly network connectivity over laser. Oh and what about a rogue dry-pair of copper wire? There can always be a public rogue AP 2 miles down the road connected to it.
I guess there is a bit of a “woops”-factor for rogue AP’s because it’s so easy to spend $20 and plug it into a network port. This is why I suggest DAI (Cisco dynamic arp inspection) along with port-security setup so every port has 1 static and 1 dynamic (refreshing the statics occasionally after verifying them to assets). Make sure BPDU-filter/guard and root-guards are setup for your spanning-tree. Please also make sure EIGRP/OSPF/ISIS/RIP are not leaking into your LAN and are properly configured with crypto keys and explicit neighbors (setting routing protocols to “default-passive” is recommended). Network devices should set port-security to 1 static on transits/trunks. VTP should be off or transparent with the domain set to the hostname of the switch. All endpoint ports should have CDP and trunking (802.1q) explicitly off. The best way to protect VRRP and HSRP is to use crypto keys (some HSRP implementations use cleartext passwords that can simply be sniffed), but I suggest IPSec if crypto keys are not an option. You could also set your gateways to the highest IP’s in the subnet and set the HSRP priorities to 255. Make sure that routers don’t accept GARP or ICMP redirects. Finally, run Ettercap to look for other Ettercaps and verify the infrastructure with Yersinia and the Phenoelit tools.
I say skip on the 802.1x, EAP, PEAP, et al — they don’t really provide anything magical. The best setup for WiFi happens to be WPA2-Personal using HostAP to provide 63-character keys on a per-client basis (done by MAC address). I prefer to setup two AP’s: both using WKnock. First, WKnock one running FakeAP, which will start spitting out random SSID’s. Then, WKnock up your “real” HostAP and connect to it using WPA2-Personal. When you’re done using your WiFi, re-knock both AP’s. Then change the SSID (and maybe your WPA2-Personal PSK) on your HostAP, always choosing a random 32-character SSID and 63-character PSK. Generate the SSID with `cat /dev/urandom | tr -cd [:alphanum:] | fold -w 32 | head -1` and generate the PSK with `cat /dev/urandom | tr -cd [:graph:] | fold -w 63 | head -1`. Sometimes less is more.
Also – it’s a good idea to not allow access to anything without connecting over an SSL VPN that requires multi-factor authentication (e.g. an HTML forms-based user/password authentication along with a MAC-specific session ID). This provides something you know (user/pass), something you have (session ID), and something you are (MAC id tied to your computer). Using Flash LSO’s instead of HTTP cookies for the session ID’s would be preferred, as users are less likely to block or delete these (and Flash has direct access to the network stack making it easy to grab the MAC address). Of course, you’ll need a way of issuing new session ID’s if users change computers, preferably out-of-band such as verification over the phone (or automated with SMS).