Under Windows/Linux, client side. How can I ensure that I'm not connecting to a rogue AP?
Check to see that the channel and mac address are correct. It might not be a 100% safe but harder to spoof...– KilledKennyMay 25, 2011 at 13:38
3Also interested in this. Simple attack in a conference create a wifi hotspot called Free-wifi or BT Openzone and see how many iPhones connect to it automatically. Setup firebug or wireshark. Fun and profit. There must be a better way to uniquely identify wifi networks than a SSID string which can simply be copied– RakkhiMay 25, 2011 at 14:28
2If you keep auto-connect off and keep an eye open while authenticating and associating to the AP... you should be able to see any irregularities (for instance, my work wireless connection changed encryption method or my home network is available while at Starbucks ~ stuff like that is a bad sign).– OrmisMay 25, 2011 at 19:38
4@WZeberaFFS, the MAC address is trivial to spoof.– D.W.May 29, 2011 at 21:36
1@Bill Weiss, I think @Rakkhi meant FireSheep, which would allow the attacker to easily grab the passing login cookies, and impersonate the victim on many websites that don't use HTTPS for all their traffic.– pkaedingJun 1, 2011 at 20:43
MAC's are easily spoofed.
WEP is cracked in minutes.
WPA/WPA2 implementations are not secure in all routers.
IMO man-in-the-middle attacks are almost unavoidable
The main problem is that the control data in 802.11x is never encrypted.
Because every wireless authentication must start using the unencrypted control sequence, it will be vulnerable to a man-in-the-middle attack.
To make matters worse, 802.11x sessions can easily be forced to disconnect and re-authenticate, so the man-in-the-middle can appear at any time in the session.
By using a radio-beam directed only at the client, it is very hard for intrusion detection systems to intercept this traffic.
The solution to this is to stop worrying about the man-in-the-middle at this or that access point.
Just make a connection with any access point, secured or not.
None of them can be trusted, so don't bother.
Instead use a VPN solution that is safe from man-in-the-middle attacks*). e.g. SSHv2 in a MITM-safe configuration and connect to your endpoint using that.
What can the attacker do?
Than your attacker can listen in on the stream of data to his hearts content, all he can infer is how much data you are sending and receiving at your laptop (traffic analysis), this is still useful, but he could do that anyway by silently sniffing the wireless traffic.
But keep your laptop safe
You will still have to keep an attacker out of your laptop, employ a firewall that only accepts traffic from your VPN connection and nothing else. Use a secure operating system.
Benefits of this approach
Your laptop will be usable outside the corporate infrastructure. Realistically it will almost never stay inside that safe shell and securing all the access points you want to connect with is a pipe dream.
If you set up a proxy server for web and mail server reachable through the VPN connection you'll have full secure use of your laptop from any and all locations.
With WEP and WPA outside attackers can spoof your wireless access point.
With WPA2, regardless of encryption used authenticated attackers can initiate a mitm attack regardless of encryption scheme used. This can be done by unreliable insiders or malware on a trusted laptop.
Whilst there is no need to get all paraniod about this as D.W. correctly pointed out.
The bottom line is, there is no way to be 100% sure that you are not connecting to a rogue AP.
Now you only need to worry about that iphone.....
WPA2 has a mitm attack vector called Hole 196, see: http://www.airtightnetworks.com/WPA2-Hole196
*) not all VPN solutions are and lots of them have configurations where an otherwise safe solution is still at risk, but there are safe options and if you have a good sysadmin it is not a difficult thing to setup correctly.
3@Johan, are you sure? I think your answer is incorrect. I think you're sweeping with too broad a brush. Yes, WEP is trivial to crack, and WPA has problems. However, I'm not aware of any serious attack against WPA2 (when used properly: say, with a long and strong passphrase and with AES). Can you provide a citation to your claims? Jun 2, 2011 at 6:17
Wpa2 mitm attacks are not unheard of, see e.g. news.softpedia.com/news/… Jun 2, 2011 at 23:50
10Oh, come on. WPA2 is fine as long as you ensure that only trusted users have access to the passphrase. There are no known attacks in that scenario. The Hole 196 link says explicitly that only an authorized user can mount the attack. So Hole 196 is not relevant here, if you use the wireless network properly. @Johan's answer is misleading; it is written as though WPA2 is worthless, but that is not accurate. To onlookers, I do not recommend relying upon the statements in @Johan's answer. (This is a problem with relying upon voting-based web sites for crypto advice.) Jun 3, 2011 at 0:24
6@D.W. There is no such thing as a trusted user, 50% of all attacks come from inside the organisation. WPA2 is not worthless though I did not say that, it is just not secure against mitm attacks by so called
trustedusers. Jun 3, 2011 at 8:00
github.com/apenwarr/sshuttle Jun 4, 2011 at 10:12
The only way to be 'sure' you are connecting where you want to connect, is by having a root of trust beforehand, something shared with AP like symmetric keys or a the public key of the AP (and be trust the public key belongs to it) or trust some certificate. If you have this root of trust, you can form a basis of trusting the AP if it can provide assurances that it knows the private key or can use the shared key.
Also, if the AP uses WPA/WPA2 then mutual authentication is used, so you can infer it is the correct AP by the fact that authentication succeeds or fails.
2If I share a symmetric key with an AP, what prevents me from setting up another rogue AP with the same symmetric key? My WPA/WPA2 "create new wireless network" menu (really "configure new...." I assume....) doesn't mention anything besides a password. How could I pre-configure the public key or certificate I'm looking for (on Ubuntu)? May 26, 2011 at 17:44
1I didn't say that all users share the same symmetric key with the AP. You could create an rogue AP, but if everybody else have a key that they trust, (which is not the one you have) then there's no point in doing that. For WPA/WPA2, if you want to create an AP and use certificates, you have to use EAP-PEAP. I don't know how is this done (if possible) in windows.– johnMay 26, 2011 at 19:21
@nealmcb, what prevents you is that hopefully you don't know and can't guess the symetric key. Put another way, while @john didn't say this explicitly, an implicit assumption is that the key must not be shared with anyone else (or at least, not with anyone you don't trust, though that gets a bit more dubious). May 29, 2011 at 21:39
The solution is alluded to in another answer but not explicitly stated. This is currently only possible using WPA/WPA2 Enterprise. Using EAP-TLS both the client and the authentication server (ie RADIUS) are authenticated via certificates. If you want to be sure you are connecting to the right AP secure mutual authentication is required. That being said this type of deployment is rare outside of the enterprise.
Go RADIUS! :) (At least I think that's what needs deployed for this to work) Aug 9, 2011 at 19:02
You would be correct. Added RADIUS to the answer. Aug 17, 2011 at 2:24
This is the answer I was hoping to see here. Of course, RADIUS isn't the only solution for enterprise WPA2. My vote would be for TACACS+ instead!– MarkJul 4, 2012 at 21:50
Here's what I suggest:
Configure the access point to use WPA2-PSK, with a long and strong passphrase, one that would be very hard for anyone to guess or to break by brute force. (Don't use WEP or WPA, they are not secure enough.) Don't tell anyone else the passphrase.
Configure your computer to connect to that wireless network with that passphrase, and only that wireless network. Disable auto-connect, or delete all other remembered wireless networks. (On Windows, you can do that by going to the Network and Sharing control.) If the connection succeeds, I think you have pretty good assurance that you are talking to the real access point.
This seems good enough for most purposes. If you need high security, set up a VPN and ensure that all of the network traffic out of your machine is tunneled through the VPN: then you don't care what access point it is traversing.
My general advice would be to only connect to "secured" WiFi Access Points. This requires that you and the AP have knowledge of a PSK or other authentication process, by which your system otherwise will not connect to the AP.
Additionally (and obviously) this does have the major added benefit of making sure that your wireless traffic isn't easily sniff-able by Eve.
3It would help to define "secured" more unambiguously, for a newbie. May 26, 2011 at 17:39
@nealmcb - What? You want another essay answer from me? I'll elaborate a bit more later. May 26, 2011 at 17:48
1"secure" needs to be defined carefully. For instance, it is easy for many users to think that WEP or WPA connections are "secured", but actually they provide poor security. WPA2 is needed (preferably WPA2-AES). May 29, 2011 at 21:38
@DW - I agree with using WPA2 for best security. However, to answer the concern addressed in the question, any security mode should be sufficient. May 30, 2011 at 0:12
1@Iszi, if the security was WEP, the password can be cracked in minutes and therefore spoofed. WPA2 is also not a guarantee, many Speedtouch routers have wpa2, but use a bogus algorithm to generate a default password. I've got an app on my iphone that cracks that password in seconds, so I strongly disagree with your comment. May 31, 2011 at 21:29
You cant and you should not worry to much about it.
If the AP gives you internet connectivity it should be regarded with the same suspicion as any internet connection. So any sensitive information sent over the internet and the access point should be separately authenticated and encrypted.
- Use your own DNS server not the one provided by the AP
- Only use https when connecting to websites
- Or use a vpn tunnel to a reliable server
5using your own DNS server doesn't help, because a rogue AP can mount a man-in-the-middle attack on your connection to your own DNS server. A VPN tunnel does help. HTTPS does help if you are careful to never click through any certification warning. Jun 2, 2011 at 6:19
Here are a few mitigations
Don't Connect based on the SSID
You can configure many clients' remembered WiFi networks to include the BSSID of the AP. The upside of doing so is that if your device detects the SSID of a remembered network, it won't even initiate a connection unless it has the BSSID that is stored in your device's remembered network config. The downside is that this will kill more forms of WiFi roaming, and the BSSID can be spoofed. This is really only good for protecting against very simple attacks or preventing your device from attempting to connect when a name collision occurs (like when "linksys", "holiday-inn", "starbucks-wifi" or whatever else is in your remembered networks).
Use Server Authentication
In WPA2 Enterprise, you can configure 802.1X to use a RADIUS server for authentication, and the first thing you should do in this case is ensure that your client device is authenticating the server by checking to see if it has a cert signed by a CA you trust. The upside of this is that it's a robust validation technique that is extremely difficult to undermine. The downsides are that you do have to attempt a connection first (meaning the AP is at least aware of your device), this requires a lot of set-up, and this may not be in your power if you're trying to validate someone else's AP and they don't want to set-up WPA2 Enterprise.
Don't Trust the Infrastructure
Though you didn't ask, I'll give you this for free. Even if you connect to a rogue AP, tailor your behavior to help protect against MitM attacks. Use a VPN provider like PIA, use tor, use https-everywhere, hard-code your client DNS to a well-known provider like 184.108.40.206, have all authentication cookies deleted upon browser closure. However, this is still a dicey prospect. Many applications fail to perform robust CA validation on endpoints, there are attacks on Windows clients that can expose your authentication cookies through a rogue AP, sslstrip can redirect you to non-ssl sites unless your using https-everywhere in aggressive mode or the site your connecting to uses HSTS (most don't), or tor or VPN proxy can often be circumvented (usually innocently) by applications.
One of the best options for protecting yourself against LAN-level MitM, when you're using a laptop, is to virtualize Whonix (or something to serve as a VPN gateway/router) and use IOMMU to pass your WiFi card to that VM. Then route your traffic to the Whonix router and everything will be sent over TOR. This greatly eliminates proxy evasion on your client, and reduces network card/hardware attack surface. The downside of course, is that on the other side of the tor proxy/VPN endpoint your traffic is just as vulnerable to MitM attacks (however, such attacks require much more sophistication to take place between an ISP and a service provider). This sort of set-up is what Qubes-OS does, but can be managed with a little tinkering on most linux distros. This almost certainly will not be feasible on Android or iOS. #NotForTheFaintOfHeart.
This is a common issue at the security conferences I have attended in the past. One in particular provided all the delegates with the MAC address of AP. Users were instructed to enter static entries in the ARP table of your device to ensure that rouge APs would not work.
As for determining prior to connection you could use something like Kismet/Kismac to ID the AP.
3Using the AP's MAC address is good, but I doubt it's really that great of a measure at a security conference where everyone there knows how to spoof a MAC. May 26, 2011 at 13:43
1This appears to be the right answer to me.– atdreMay 29, 2011 at 16:20
4's answer is bad advice. It is trivial to spoof the MAC address. It is trivial to set up a rogue AP with any desired MAC address. Checking the MAC address provides little additional security. May 29, 2011 at 21:40
You can't? You can be sure within some confidence level. The "secure" confidence level depends on your situation.
But to be more helpful, Johan has answered it pretty comprehensively. I think the more important question might be "What are the relative strengths of the various ways to secure your APs?"
And how much effort does it take to subvert the various levels of securing your AP?
If have root access to the wireless router then if running an SSHD on it, then you can check the ssh key stored in the "known_hosts" on the client that it matches the one you get when connecting to the SSHD on the wireless router.
5this doesn't work. It is not secure. That's not how wireless connections to 802.11 access points are made: they're not made over SSH. Alternatively, if your idea was to connect to the access point, then trying to SSH to 192.168.0.1, then that's not secure either, because you might have connected to a rogue AP that acts as a man-in-the-middle to relay SSH connections to 192.168.0.1 to the real AP without tampering with them, while tampering with all other network connections. I suspect you may have some misconceptions about how 802.11 works. May 29, 2011 at 21:42