30

Under Windows/Linux, client side. How can I ensure that I'm not connecting to a rogue AP?

kalina
  • 3,374
  • 5
  • 21
  • 36
LanceBaynes
  • 6,209
  • 12
  • 60
  • 92
  • Check to see that the channel and mac address are correct. It might not be a 100% safe but harder to spoof... – KilledKenny May 25 '11 at 13:38
  • 3
    Also 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 – Rakkhi May 25 '11 at 14:28
  • 2
    If 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). – Ormis May 25 '11 at 19:38
  • I'm unsure how Firebug helps with the "fun and profit" of being a rogue AP that an iPhone connects to, I've got to say. – Bill Weiss May 26 '11 at 13:49
  • Edited title to say "Access Point". You don't really connect to an "SSID". Even if you did, you could still connect to the "right" SSID and still not be connected to the network you want. – Iszi May 26 '11 at 14:07
  • 4
    @WZeberaFFS, the MAC address is trivial to spoof. – D.W. May 29 '11 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. – pkaeding Jun 01 '11 at 20:43

10 Answers10

16

Speaking generally
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.

Don't worry
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.

The solution
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.

To recap
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.

Johan
  • 518
  • 4
  • 8
  • 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? – D.W. Jun 02 '11 at 06:17
  • Wpa2 mitm attacks are not unheard of, see e.g. http://news.softpedia.com/news/WPA2-Vulnerability-Allows-for-Man-in-the-Middle-Attacks-149052.shtml – Johan Jun 02 '11 at 23:50
  • 10
    Oh, 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.) – D.W. Jun 03 '11 at 00: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 `trusted` users. – Johan Jun 03 '11 at 08:00
  • https://github.com/apenwarr/sshuttle – LanceBaynes Jun 04 '11 at 10:12
  • @Lance, I don't know enough about that proxy to tell you if it's safe from mitm. If you tunnel over SSHv2 and make sure you **double check** that fingerprint prompt on first connect you should be safe and make sure to disable use of SSHv1 in /etc/sshd_config. – Johan Jun 05 '11 at 10:52
  • @Johan: Correction: you probably meant `/etc/ssh_config` - those are the system-wide defaults for _outgoing_ connections. `sshd_config` apply to the _incoming_ connections to SSH daemon on your machine, if there is one running (not really applicable in this scenario). – Piskvor left the building Aug 08 '11 at 15:43
  • "_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._" The main problem with _whatever_ is that the initial control data in _whatever_ is never encrypted. Because every _whatever_ authentication must start using the unencrypted control sequence, it will be vulnerable to a man-in-the-middle attack. – curiousguy Nov 02 '11 at 21:48
  • @Piskvor, I meant `sshd`, unsafe protocols should be disabled first and foremost in the server. But of course also on the client. – Johan Dec 14 '11 at 13:27
  • @Johan: Oh, sure. Fair point. – Piskvor left the building Dec 14 '11 at 14:14
10

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.

john
  • 10,998
  • 1
  • 36
  • 43
  • 2
    If 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)? – nealmcb May 26 '11 at 17:44
  • 1
    I 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. – john May 26 '11 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). – D.W. May 29 '11 at 21:39
  • @D.W. @john: but how often is it the case, and how could you know, that a particular symmetric key is only known to you and the AP? I'd guess it is rare, as demonstrated by the impact of the [FaceNiff](http://security.stackexchange.com/questions/4841/how-does-faceniff-work) – nealmcb Jun 27 '11 at 19:46
10

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.

sdanelson
  • 1,287
  • 10
  • 21
5

Here's what I suggest:

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

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

D.W.
  • 98,860
  • 33
  • 271
  • 588
3

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.

Iszi
  • 27,027
  • 18
  • 99
  • 163
  • 3
    It would help to define "secured" more unambiguously, for a newbie. – nealmcb May 26 '11 at 17:39
  • @nealmcb - What? You want another essay answer from me? I'll elaborate a bit more later. – Iszi May 26 '11 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). – D.W. May 29 '11 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. – Iszi May 30 '11 at 00: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. – Johan May 31 '11 at 21:29
  • @Johan - It may not be guaranteed, but it's really the only method globally applicable without having influence on the configuration and/or administration of the networks you connect to. – Iszi May 31 '11 at 22:38
1

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 1.1.1.1, 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.

TopherIsSwell
  • 371
  • 1
  • 14
1

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
Stuart
  • 300
  • 1
  • 3
  • 5
    using 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. – D.W. Jun 02 '11 at 06:19
0

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.

Matt S
  • 17
  • 1
  • 3
    Using 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. – Iszi May 26 '11 at 13:43
  • 1
    This appears to be the right answer to me. – atdre May 29 '11 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. – D.W. May 29 '11 at 21:40
-1

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?

Bradley Kreider
  • 6,182
  • 2
  • 24
  • 36
-3

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.

LanceBaynes
  • 6,209
  • 12
  • 60
  • 92
  • 5
    this 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. – D.W. May 29 '11 at 21:42