Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

judgecorp writes "Security researchers say that iPhone and other Apple devices are vulnerable to an old attack, using a fake Wi-Fi access point. Attackers can use an SSID which matches one that is stored on the iPhone (say "BTWiF"), which the iPhone will connect to automatically. Other devices are protected thanks to the use of HTTPS, which enforces HTTPS, but iPhones are susceptible to this man in the middle attack, researchers say."

I think the problem is that the iPhone will connect to an unsecure network automatically without alerting the user while the user believes they are on a different, secure network.

That can only happen if the Ask to Join Networks setting is off.

No, that's the whole point of TFA, which basically points out iOS devices have carrier pre-defined WiFi settings built it, and will connect to such networks automatically, such that placing an access point near a target that masquerades as one of these pre-defined access points is likely to cause such devices to connect automatically.

No. The example given is for a public hotspot (one of those things with a captive portal to enter your credentials), and those run on open wifi. No WPA, not even WEP.

Of course they can be spoofed and MITM used - that's been known for years. I don't know why the iPhone is any more vulnerable than any other phone. Does it hide the s in https perhaps, so the user won't notice they aren't on SSL?

I think the problem is that the iPhone will connect to an unsecure network automatically without alerting the user while the user believes they are on a different, secure network.

I'm not clear on why this is an iPhone-specific problem. The Android phone I bought from AT&T two years ago seemingly does exactly the same thing. It will automatically join AT&T wifi networks if they are in range - for example, when you walked into a Starbucks.

Unfrotunately people rarely go to websites by typing in a https url. They go to websites by typing something in a search box or by typing in a url without protocol (which for historical reasons defaults to http). This gives an attacker an opertunity to hijack things before the user switches to https and keep the client on plain http as the connection from attacker to server switches to https.

There is a new spec called http strict transport security which tries to mitig

Unfrotunately people rarely go to websites by typing in a https url. They go to websites by typing something in a search box or by typing in a url without protocol (which for historical reasons defaults to http). This gives an attacker an opertunity to hijack things before the user switches to https and keep the client on plain http as the connection from attacker to server switches to https.

Exactly, and it is trivially easy to accomplish these attacks with man in the middle tools like SSLstrip [thoughtcrime.org] and the Middler [google.com]

I think the problem is that we've seen over time many web based jail breaks of iPhones. Just visit a URL, and it breaks your phone's security to the root level. So if you can combine man-in-the-middle with a jailbreak style hack, you can redirect everyone's safari to your web site and p0wn everyone's iPhone in the city. Not easy to pull off, but potentially devastating to large numbers of users if you can.

You can easily see what networks the phone has saved as it probes for them even if it is connected to a network already.
There are application which just listens to what networks phones and other devices probes for and then automatically broadcast a SSID that matches to make them connect. By this method you could get just any phone in the area to connect to you at the same time.

But the article is partially correct, preset SSIDs that some carriers use are a vulnerability, I was messing with a WiFi attack with some other people where we would deauth everyone around us and then have our access points giving out SSIDs that were part of various major carriers presets.Just because Chrome uses HSTS doesn't mean that there wasn't some useful information acquirable.Also, people are stupid and will join networks that look legit.

Just to be clear here, protocols like HTTPS only secure data from the Application Layer - this man in the middle attack takes place at a much lower layer (Data Link/Network), meaning any device which automatically connects to familiar SSID's is susceptible. HTTPS will not save you from rogue AP's.This is largely a convenience feature implemented by Apple, but it doesn't matter which device you're using - if you aren't encrypting your traffic, you are vulnerable to eavesdropping. Period.

The article seems more to do with HTTPS STS and Apples lack thereof then anything specific about open WiFi. So even if you end up on a malicious network, with Android phones, your browsing is a little more secure (although first time visits to websites can be just as insecure because of HTTPS STS limitations).

The WiFi component is just about 'spoofing' a know SSID to trick your iPhone into connecting to your network and not the actual trusted one; this part of the problem should apply to any phone or devic

This is one reason why it doesn't hurt to use a VPN with a profile that restarts the handshake should it get disconnected, so no traffic travels the Net unless it is to the VPN provider.

I just pick a service that has a low latency and has servers near me, use that. The result is that even if the Wi-Fi AP is completely compromised, the only traffic that will be obtained are packets to/from the encrypted tunnel.

Of course, if I use HTTP, traffic from the VPN provider and the destination can still be obtained,

>Of course, if I use HTTP, traffic from the VPN provider and the destination can still be obtained, but getting access to a trunk switch or router tends to be a lot harder than compromising an AP in public.

I'll sometimes set up my phone's wifi hotspot with the SSID of 'attwifi' at work occasionally, just to watch how many people's phones autoconnect to what is the standard SSID for starbucks (and others) hotspot names.

The article talks about a few different things which are only somewhat related. The wifi vulnerability is the fact that an Apple device will automatically connect to a wifi network that has the same SSID as a network it has previously connected to. I suspect this is the same for Android devices, but I am too lazy to test atm.

The issue that relates to https is related to something called HTTP STS. (http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security). HTTP STS is supposed to be a way by which servers can communicate to browsers that requests to a particular site should always be sent over https. The issue that is being raised is that Chrome supports HTTP STS and hence Android devices do as well, but Safari does not. I guess what this would get you is that if you connect over https to a site over a trusted network, then further requests to that domain are forced to be made over https with a certain validity of certificate.

The article talks about a few different things which are only somewhat related. The wifi vulnerability is the fact that an Apple device will automatically connect to a wifi network that has the same SSID as a network it has previously connected to.

Sort of. The vulnerability is that carriers are pre-configuring access points that devices will automatically connect to - not necessarily personal access points (e.g. at home) that you've previously used - and by configuring a malicious access point to look like the carrier's pre-defined one, you can cause the device to connect to the malicious access point:

I've noticed that iOS devices are pretty flexible in how they connect to wireless networks. Flexible, in that they will automatically try a whole bunch of stuff to get connected. I imagine this is in a best-effort to get connectivity and to avoid bothering the user as much as possible.

All it needs is an SSID an an associated password. If you change the access point, wifi settings, encryption protocols, etc it does not matter. As long as the SSID and password are correct the device will generally connect up.

If you use WPA2 Enterprise does the client authenticate base station? i.e. if a device finds a base station with the same SSID will it connect to it? If the fake base station also uses WPA2 Enterprise can it trick the device into sending the credentials?

Actually, the authentication doesn't happen at the base station level. The authentication gets passed to a RADIUS server (which authenticates individual base stations based on individual pre-shared keys), the RADIUS server has their own SSL certificate which needs to be accepted on the client (even if there is a trusted chain, and the certificate is 'valid', my iOS devices still asks me to verify the server certificate), then through TTLS or PEAP (or whatever authentication mechanism you specify) the RADIUS

- This is all mitigated using WPA2 Enterprise since you have end-to-end per-user encryption

The real problem is that WPA lacks a mode suitable for secure public hotspots. Such a mechanism would need to provide

1: a way of verifying with a reasonable degree of certainty that the operator is who they claim to be evern though the user hasn't previously interfacted with them. Likely this means some kind of certification authority. At least the WPA enterprise deployment i've used (eduroam) required the user to manually install a certificate to connect securely.2: a way of connecting as an "unknown user"

Why would we need yet another standard. Simply don't trust open access points and encrypt everything, use HTTPS, IMAPS, SMTPS, SFTP,... VPN if necessary. Even traffic on hotspots with a PSK are vulnerable as long as the attacker can get to the key.

HTTPS is another layer entirely and already complains when the certificate isn't valid or isn't signed by a trustworthy vendor, it's relatively hard to get a trusted SSL certificate to be accepted by any ol' device. HTTP STS only builds further on SSL by having a

The procedure for safely using an untrusted wireless access point that has a captive portal with a VPN goes something like:

1: shut down any internet using applications that could potentially send private information over unencrypted connections. Hope you didn't miss any.2: connect to the wifi3: launch your browser with special parameters to make sure it doesn't try to do a session restore or otherwise leak any private data from pre-existing cookies. Alternatively keep a seperate browser that you only use fo

Read the original blog post instead: http://blog.skycure.com/2013/06/wifigate.html [skycure.com]
Summary: phones come pre-loaded with wifi SSNs, which you can spoof and get random iPhones to connect to you. Reach-arounds ensue.

SOME phones come pre-loaded and I wouldn't be surprised if Android and even feature-phones come pre-loaded. You could also wipe pre-installed configuration profiles if you are so inclined. Or simply don't trust any hotspots that aren't your own, you know, common sense...

I've wanted the ability to tell my iPhone to forget old networks so it doesn't waste time and power sending probe frames trying to provoke any hidden access points/SSIDs to advertise themselves. The security concern raised by this article is yet another.

As the posts there point out that only works if you're still in range of the old network. It's a pain to have to remember to forget a network each time I check out of a hotel, nor do I want to have to reset all settings and reteach the phone about the networks I do want it to use.

Indeed, there's no option to manage/delete from a list of networks you're not already in range of. You unfortunately have to do a "Reset network settings", which clears everything out but of course means re-entering passwords for wifi stations you *do* want to keep (next time you're in range).

... I'd recommend the installation of WiFiFoFum. It's basically like iStumbler for the iPhone, so you can at least see if the local access points are ad-hoc or infrastructure, & other stuff like that. I always run it before connecting my phone/iPad to any public hotspots.

Disclaimer: not connected to the development of this app, just a happy user.

So if you RTFA it might clear a bit of the confusion up. The issue has to do with carrier branded WiFi networks. If you buy a phone from, say, Vodaphone (mentioned in the article) there is a feature the carrier can enable on their iPhones that allows the phones to connect automatically to the carrier owned WiFi hotspots. I believe AT&T does the same thing. The phones have built in authentication, so the user never sees it. Most are using HTTPS STS but I guess Apple hasn't pushed that out yet. Vodaph

This article has a misleading headline and/. simply relays the misleading.
This is not an Apple iDevice problem, all WIFI devices are subjectable for such an attack.
Underlying problem in Apple's case is that some carriers seem to add predefined WIFI networks to an iPhone/iPad when the device get their carrier settings. So this must be the carrier's issue!

But this attack could might as well be used against any laptops or Android devices.

UPDATE: Vodafone has told TechWeek why it believes its users are safe: “The embedded configuration that is applied for our iOS devices ‘1WiFiVodafone1x’ and ‘Auto-BTWiFi’ are locked to ‘EAP-SIM’ authentication which is a bi-directional authentication protocol.

“Man-in-the-middle attacks rely upon a hacker setting up an access point pretending to be the configured AP [access point].

“With EAP-SIM configured, the device will send the AP a challenge to make sure that it is Vodafone that it is connecting to. This transaction is resolved with our network, which sends back the response to the challenge and its own challenge. The handset then responds to the network challenge and providing all of these challenge response pairs work then the user gets access. If the initial test for it being Vodafone fails, the device doesn’t connect.”

UPDATE: Vodafone has told TechWeek why it believes its users are safe: âoeThe embedded configuration that is applied for our iOS devices â1WiFiVodafone1xâ(TM) and âAuto-BTWiFiâ(TM) are locked to âEAP-SIMâ(TM) authentication which is a bi-directional authentication protocol.

The WiFi Pineapple has made this sort of attack possible for a long time. It's not just the iPhone that is vulnerable. Nearly everyone has connected to a "linksys" or "attwifi" hotspot before, and you can easily spoof this with Karma.