×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

iPhone Apparently Open To Old Wi-Fi Attack

timothy posted about 10 months ago | from the any-old-wireless-port-in-a-storm dept.

Wireless Networking 90

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

90 comments

HTTPS enforces HTTPS? (5, Funny)

cdrudge (68377) | about 10 months ago | (#43996325)

Other devices are protected thanks to the use of HTTPS, which enforces HTTPS

HTTPS enforces HTTPS? Whew. That's a relief. Does SFTP enforce SFTP and SSH enforce SSH too? Just checking to make sure I'm secured.

Re:HTTPS enforces HTTPS? (3, Informative)

telchine (719345) | about 10 months ago | (#43996413)

Other devices are protected thanks to the use of HTTPS, which enforces HTTPS

HTTPS enforces HTTPS? Whew. That's a relief. Does SFTP enforce SFTP and SSH enforce SSH too? Just checking to make sure I'm secured.

I assume they mean HTTPS STS

Re:HTTPS enforces HTTPS? (2)

judgecorp (778838) | about 10 months ago | (#43997111)

That should have read "HTTP STS which enforces HTTPS" Peter Judge

Re:HTTPS enforces HTTPS? (1)

Anonymous Coward | about 10 months ago | (#43997391)

Can we agree to drop the HTTPS and just say "STS enforces Peter Judge"

Actually ... no. (1)

oneiros27 (46144) | about 10 months ago | (#43997695)

You can apply the 'HPN' (high performance networking' patch to SSH to get faster transfers speeds.

Of course, much of what it does is enable the 'None' cipher, so you don't have any encryption overhead. But you have to have both the server & client modified for it to work.

Re:Actually ... no. (2)

cheater512 (783349) | about 10 months ago | (#44001799)

Where can I find this patch? I love having the best speed possible on my servers so I'll definitely apply this one asap.

HTTPS (2)

telchine (719345) | about 10 months ago | (#43996357)

Most sensitive mobile data these days is carried over SSL surely? I can't see this being any more dangerous than connecting to a public network voluntarily.

Re:HTTPS (2)

The MAZZTer (911996) | about 10 months ago | (#43996427)

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.

Re:HTTPS (0)

Anonymous Coward | about 10 months ago | (#43996595)

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.

Re:HTTPS (5, Informative)

DigitAl56K (805623) | about 10 months ago | (#43997005)

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.

The original article is here, and includes notes that on some occasions, not only the baked-in SSIDs are visible, but also the passwords in plaintext:
http://blog.skycure.com/2013/06/wifigate.html [skycure.com]

Re:HTTPS (0)

Anonymous Coward | about 10 months ago | (#44007557)

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,

No, the whole point of the article is to pretend that carrier settings under Android don't do the exact same thing.

Re:HTTPS (1)

Trillan (597339) | about 10 months ago | (#44072813)

This is a fascinating problem. I can see the feature being incredibly valuable, yet awful as it's currently implemented. Is there an approach to doing this safely?

Re: HTTPS (0)

Anonymous Coward | about 10 months ago | (#43999447)

The htc One S has that same problem. You didn't even need to have a named wifi AP. It just connected to any nearby wifi without any user input. Id drive by a Mcdonalds and lose my signal while it tried to connect wifi calling to something with a login page.
Though, to be fair, it never tried that during a call.
I even turned on "ask before connecting" which is an option it did have, and it STILL did it. The only way around it is to completely turn off wifi.

Re:HTTPS (1)

SuricouRaven (1897204) | about 10 months ago | (#43996995)

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?

Re:HTTPS (2)

93 Escort Wagon (326346) | about 10 months ago | (#43998297)

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.

Re:HTTPS (2)

petermgreen (876956) | about 10 months ago | (#43997539)

It's SUPPOSED to be carried over https.

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 mitigate this by allowing servers to tell the browser "if in future you see a http url pointing to me use https instead". TFA is complaining that IOS doesn't implement this new spec while andriod does and also complaining that carriers set up open wifi networks by default (though honestly even if they didn't most users would probablly end up adding several open wifi networks manually because wifi is usually faster and cheaper than cellular data).

Re:HTTPS (1)

Nixoloco (675549) | about 10 months ago | (#43998069)

It's SUPPOSED to be carried over https.

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]

p0wned (1)

countach (534280) | about 10 months ago | (#44002021)

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.

Re:HTTPS (1)

tepples (727027) | about 10 months ago | (#44005735)

Most sensitive mobile data these days is carried over SSL surely?

Smaller sites on name-based virtual hosting still have to fall back to HTTP in the clear to support Android 2.x, whose default browser can't use SNI [wikipedia.org] .

yep, i do this all the time (1)

Anonymous Coward | about 10 months ago | (#43996373)

i set up my and my inlaws' wifi to be the same SSID and password so that when we visit each other the devices get on wifi automatically

i wonder what will happen if i do this with one WIFI router requiring a password and another with the SSID not requiring one. wonder if SSIS will connect.

either way, how will someone know the list of my saved SSID's? does apple allow an app to pull it?

Re:yep, i do this all the time (1)

jonbryce (703250) | about 10 months ago | (#43996493)

I think the idea is that you use the name of a popular provider of public Wifi services. The example given is BTWifi, and they are the largest in the UK.

Re:yep, i do this all the time (1)

Krojack (575051) | about 10 months ago | (#43996707)

Time to head to a popular open wifi spot in town and start up my hotspot on my rooted phone. Could be interesting, could be ungodly boring.

Re:yep, i do this all the time (1)

ZerXes (1986108) | about 10 months ago | (#43996865)

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.

Re:yep, i do this all the time (0)

Anonymous Coward | about 10 months ago | (#43997771)

how will someone know the list of my saved SSID's? does apple allow an app to pull it?

Due to the stupid practice of "hiding the SSID", a client can not simply listen to beacons and connect when one of the known networks is in range. Instead it has to send probe requests and hope for a response from one of the known networks. The option "Connect even if the network is not broadcasting its name (SSID)" is what toggles these probe requests in Windows 7 on a per-network basis. There are automated attack toolkits which listen for probe requests, set up unencrypted networks with these SSIDs, proxy every network connection going and modify web pages to remove HTTPS redirects. (For example: Karma [wirelessdefence.org] , Jasager [digininja.org] )

Now you know why "hiding the SSID" runs down the battery and makes you less safe.

Also, zealous autoconfiguration is a feature: http://xkcd.com/416/ [xkcd.com]

Editors didn't read the summary? (4, Informative)

Imagix (695350) | about 10 months ago | (#43996379)

the use of HTTPS, which enforces HTTPS

What does that even mean?

restricted, top secret, need to know, codeword (1)

swschrad (312009) | about 10 months ago | (#43996717)

otherwise known as a brain fart, secured from shame. in my business, it is reported on the logs as "Special (Freaking) Magic."

Re:Editors didn't read the summary? (3, Informative)

Lord Byron II (671689) | about 10 months ago | (#43996771)

That and "BTWiF" which makes no sense. It's supposed to be "BTWifi" which is BT's public WiFi network.

Re:Editors didn't read the summary? (3, Funny)

water-and-sewer (612923) | about 10 months ago | (#43997197)

That's an acronym common in the industry which stands for "by the way I farted."

Re:Editors didn't read the summary? (0)

Anonymous Coward | about 10 months ago | (#43997939)

It's broadcast sexting: By The Way, I Fuck Indiscriminately.

Re:Editors didn't read the summary? (1)

imikem (767509) | about 10 months ago | (#43998129)

Are you on Facebook by chance?

Re:Editors didn't read the summary? (0)

Anonymous Coward | about 10 months ago | (#43998403)

Sorry if that made you horny. No, I'm not on Facebook.

Re: Editors didn't read the summary? (0)

Anonymous Coward | about 10 months ago | (#44003131)

By the way I farted.

(that's how she knew it was love)

Re:Editors didn't read the summary? (0)

Anonymous Coward | about 10 months ago | (#43997219)

They didnt want to get hit with copyright/patent/trademark/insert-corporate-protection-method-here lawsuits.

Re:Editors didn't read the summary? (0)

Anonymous Coward | about 10 months ago | (#43997563)

What does that even mean?

It's like a double rainbow... all the way.... whooooaaa...

Re: Editors didn't read the summary? (0)

Anonymous Coward | about 10 months ago | (#43997883)

Really poor summary. They start by mentioning it will auto connect to an access point then all of the sudden are talking HTTPS. I can only guess they are saying there is a vulnerability that allows a MITM attack to send non-HTTPS traffic to a HTTPS connection? Just guessing, though.

Re: Editors didn't read the summary? (0)

Anonymous Coward | about 10 months ago | (#43998261)

just keep your iphone constantly connected to a vpn while on wifi!

Greetings slashdort. Big things happening today! (1)

For a Free Internet (1594621) | about 10 months ago | (#43996387)

As I left the house today, I thought of bread and ice cubes. A strange bear was driving cars, so I went back in and posted this on slashdort, for the historical record. See you later, BOB

Forces use of HTTPS (0)

Anonymous Coward | about 10 months ago | (#43996401)

I'm sorry, maybe I'm the idiot here (doubtful) but are you saying that the iPhone is vulnerable to connecting to fake Wi-Fi access points, but that other devices somehow don't make the connection because they use... https?

I think what you mean to say is that any device that auto-connects to a wifi hotspot based on SSID is vulnerable, but that many devices are, by default, not configured to do this. Also, everyone should use encrypted connections so that their login/pass aren't leaked.

i've noticed this with at&t hotspots (3, Informative)

ebubna (765457) | about 10 months ago | (#43996423)

pass a damn mcdonalds and bloop there i am connected. pretty annoying!

Terrible summary (1)

Anonymous Coward | about 10 months ago | (#43996431)

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.

Misleading Summary (3, Informative)

rogueippacket (1977626) | about 10 months ago | (#43996433)

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.

Re:Misleading Summary (1)

Jabrwock (985861) | about 10 months ago | (#43996591)

"This is largely a convenience feature implemented by Apple"

From what I understand, this is mostly implemented not by Apple, but by the carriers. AT&T iPhones come pre-programmed to "know" about AT&T hotspots, etc.

Re:Misleading Summary (0)

Anonymous Coward | about 10 months ago | (#43996601)

if you aren't encrypting your traffic, you are vulnerable to eavesdropping. Period.

Also, do the key exchange over another channel.

Please Explain (0)

Anonymous Coward | about 10 months ago | (#43996517)

I guess I don't know what the article is saying, but I don't see anything new here or anything that doesn't actually impact any device.

The phone connects to a wifi network based off the SSID it knows - if the operator of that wireless point wants they can sniff the traffic. Traffic that isn't encrypted is readable...am I misunderstanding something here.

My laptop will connect to a SSID that it had connected to before - if I send unencrypted traffic that can be snooped.

Re:Please Explain (1)

Straif (172656) | about 10 months ago | (#43996903)

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 device with a list of trusted SSIDs and not just Apple.

Fairly common problem... (1)

mlts (1038732) | about 10 months ago | (#43996593)

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, but getting access to a trunk switch or router tends to be a lot harder than compromising an AP in public.

Re:Fairly common problem... (2)

wbr1 (2538558) | about 10 months ago | (#43997497)

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

The NSA has access to those.

Definitely Entertaining (2)

dontbemad (2683011) | about 10 months ago | (#43996651)

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.

So the summary completely sucks (5, Informative)

Stewie241 (1035724) | about 10 months ago | (#43996657)

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.

Re:So the summary completely sucks (2)

DigitAl56K (805623) | about 10 months ago | (#43997091)

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:

TFS and TFA are both shit, look here instead (linked from TFA):
http://blog.skycure.com/2013/06/wifigate.html [skycure.com]

Re:So the summary completely sucks (1)

Anonymous Coward | about 10 months ago | (#43997681)

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. I noticed this when I changed my wifi router to a new one. The old one was setup for TKIP and the new one was setup for WPA2. I made the SSID and password the same just for ease of use, and I found that I didn't have to do a thing on any of my iOS devices. Not all wifi clients are like this.

In addition to the above, I'm fairly certain most iOS devices will also automatically connect to most unsecured access points without intervention (Like free wifi in any restaurant/cafe/etc).. So if you were to impersonate another AP with the same SSID and turn off security, an iOS device might connect to it automatically. The user will probably not notice the difference. This could be security issue.

By design (1)

guruevi (827432) | about 10 months ago | (#43996797)

This is entirely by design, large deployments of WiFi simply have the same settings on each base station and then use WPA2 Enterprise (instead of WPA2-PSK) to do access control.

If you have large deployment of unsecured wireless networks (such as guest networks), same thing happens, the client connects to the base station with the best signal and the given SSID.

I don't see where this is a problem:
- It is defined in the 802.11 standard for roaming
- If you use an insecure (open) network, by definition you don't have any security or encryption
- If you use a WPA2-PSK network, you should use a good key, if the attacker knows your key, regardless of whether they set up a fake base station they can decrypt your data
- This is all mitigated using WPA2 Enterprise since you have end-to-end per-user encryption

What the fuck does HTTPS have to do with this? This is an entirely different layer.

Re:By design (1)

Stewie241 (1035724) | about 10 months ago | (#43996993)

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?

Re:By design (0)

Anonymous Coward | about 10 months ago | (#43997267)

WPA2-Enterprise uses PKI to allow clients to validate the AP (well at least the RADIUS server). The RADIUS server has a certificate, the same way a https server has a certificate. If the certificate isn't valid the client will complain (or if it's MS Windows it will fail silently)

The OP doesn't know what they're talking about. Any device that can roam will behave the same way. In any mode but WPA/WPA2 Enterprise the client relies on the SSID and key to identify the AP. Some clients also match the BSSID but that's easily faked anyway. This article is elementary BS.

Re:By design (0)

Anonymous Coward | about 10 months ago | (#44014703)

WPA2-Enterprise uses PKI to allow clients to validate the AP

No, any use of PKI depends on EAP method negotiated between client and EAP server. WPA2 in no way implements or depends on PKI.

If the certificate isn't valid the client will complain (or if it's MS Windows it will fail silently)

Nobody configures this shit properly. By default windows clients require cert validation for the two shits thats worth. Everyone fails to enter the RADIUS server name and constrain the root certificate list. This renders cert validation meaningless cuz all an attacker has to do is obtain a valid certificate and ur fucked.

Re:By design (1)

guruevi (827432) | about 10 months ago | (#43997935)

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 server authenticates the username/password (or device using a client-side certificate) internally and then tells the base station to allow the client or not.

Re:By design (1)

petermgreen (876956) | about 10 months ago | (#43997693)

- 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" with limited connectivity so that the user can go through the steps needed (agreeing to terms and conditions, possiblly providing payment) to request full connectivity.

So in practice wifi hotspots tend to either use unsecure wifi with a "captive portal" for authentication or they use WPA PSK with the password printed on a peice of paper and stuck on the wall.

HTTP STS helps mitigate the damage to some extent but it doesn't solve the underlying problem of the lack of a suitable WPA mode for hotspot operators.

Re:By design (2)

guruevi (827432) | about 10 months ago | (#43997887)

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 built-in list of sites or sites telling you (with a time) to connect only through HTTPS to that site. HTTP STS still doesn't fix MITM attacks with valid signed certificates by a compromised or untrustworthy root.

Re:By design (1)

girlintraining (1395911) | about 10 months ago | (#44000675)

Even traffic on hotspots with a PSK are vulnerable as long as the attacker can get to the key.

I think you're underestimating your opponent!

~#: reaver -i mon0 -vv -b 'ImInUrWifi' > results.txt &
~# logoff

Now go to bed. When you come back, you'll have not just the PSK, but any PSK that router changes to in the future.

MITM on first visit (1)

tepples (727027) | about 10 months ago | (#44005979)

HTTPS is another layer entirely and already complains when the certificate isn't valid or isn't signed by a trustworthy vendor

If you're using Internet Explorer on Windows XP or Android Browser on Android 2.x, it also complains when the site happens to share an IP address with other sites using different certificates.

HTTP STS still doesn't fix MITM attacks with valid signed certificates by a compromised or untrustworthy root.

Nor does it fix MITM SSL-stripping attacks the first time you visit a site.

Re:By design (1)

petermgreen (876956) | about 10 months ago | (#44007303)

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.

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 wifi
3: 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 for interacting with captive portals.
4: deal with the captive portal, hope they used ssl to encrypt any authentication details.
5: make sure your VPN is configured to send all traffic through the VPN and not for "split horizon" operation
6: launch your internet using apps

This is awkward as heck on a regular desktop/laptop OS, i'm not sure it's feasible at all on most phone/tablet operating systems. I very much doubt any significant number of users are going to do it.

Re:By design (0)

Anonymous Coward | about 10 months ago | (#44014775)

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

WPA is just a pass-thru. It supports whatever modes you can dream up provided they are supported by client and server.

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" with limited connectivity so that the user can go through the steps needed (agreeing to terms and conditions, possiblly providing payment) to request full connectivity.

This is sometimes done using EAP-TLS without client certificate requirement. (e.g. 'noauth')

HTTP STS helps mitigate the damage to some extent but it doesn't solve the underlying problem of the lack of a suitable WPA mode for hotspot operators

The underlying problem is assumption the Internet is at all trustworthy. Securing the first hop does not magically secure all remaining hops... The only thing it does is make you "feel" safer.

Read the original blog post, not the TechWeek arti (1)

captrb (1298149) | about 10 months ago | (#43996821)

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.

Re:Read the original blog post, not the TechWeek a (1)

guruevi (827432) | about 10 months ago | (#43997961)

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

Security researchers... (0)

Anonymous Coward | about 10 months ago | (#43996917)

Listening to "security researcher discovers" more often than not I find myself being dismayed by what comes next.

Do I really need someone to enumerate all of the ways in which an insecure system may be abused?

Hey ARP messages are not authenticated so anyone else can forge them todo x y and z.

Hey SMB is not encrypted so I can inject or redirect 1, 2 and 3..

Shocking "discovery" LEAP is insecure when everyone already knew at the time MSCHAPv1 was broke.

Windows is insecure because OMG I can mount an unencrypted disk and access all of your files without knowing the administrator password.

While I love strict transport headers and I think this feature deserves a lot more attention than it has received (Microsoft please add to IE)...

These sorts of articles seem to be quite obviously designed to draw ill-deserved attention.

iphone lacks ability to "forget" old networks (1)

angryargus (559948) | about 10 months ago | (#43996991)

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.

Re:iphone lacks ability to "forget" old networks (1)

Anonymous Coward | about 10 months ago | (#43997129)

The iPhone can in-fact forget old networks. It has been able to do this for a long time.

Settings -> wifi

Hit the little blue arrow (not the name) next to the network you want to forget (it is a little I in a circle in iOS7). Then click on "Forget network". Your iPhone now has forgotten that network.

There is no "bulk" forget. If you want to forget all of them, iirc you can reset network settings.

iPhone can forget old networks (2)

sjbe (173966) | about 10 months ago | (#43997147)

I've wanted the ability to tell my iPhone to forget old networks

The iPhone can forget old networks [apple.com] or did you mean something else? To my knowledge it has always had this capability.

Re:iPhone can forget old networks (1)

angryargus (559948) | about 10 months ago | (#43997337)

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.

Re:iPhone can forget old networks (1)

sneezinglion (771733) | about 10 months ago | (#43998311)

Yeah, there is no way I have found to forget a network if it has been turned off, other than putting up your own "fake" network and then removing it.

Too bad I did not know this so I could create a list of every public network I ever attached to.

Re:iphone lacks ability to "forget" old networks (2)

quacking duck (607555) | about 10 months ago | (#43997195)

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

WiFiFoFun for Jailbroken iPhones & iPads... (1)

Dusty101 (765661) | about 10 months ago | (#43997377)

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

Re:iphone lacks ability to "forget" old networks (0)

Anonymous Coward | about 10 months ago | (#43997401)

It can...

No relation (0)

Anonymous Coward | about 10 months ago | (#43997065)

STS and rogue access points are only related insofar as they are both security-related terms. So no, STS doesn't mean Android is protected from rogue access points. Bad blog post, terrible news article, and worse summary.

Applies to a very specific case. (1)

EvilSS (557649) | about 10 months ago | (#43997665)

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. Vodaphone brings up a good point though: for their network, they use EAP-SIM auth, which is a two-way authentication protocol so it would not fall for a simple spoofing of the SSID.

Misleading article (1)

bjoeg (629707) | about 10 months ago | (#43998749)

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.

How often have many of you not been to Starbucks and used their free WIFI. Their WIFI (in most countries) is open with no security and all you have to do is agree to some terms on the webpage. So in the US, basically I should simply set up af network called attwifi. I really dont need to do a landing page with Starbucks/AT&T terms, many would probably not even wonder if they came directly on the internet. And then devices would begin to connect to my network, I could sniff through the traffic.

It is an old school man in the middle attack and not much Apples problem. And yes HTTPS protects you, no wait, it only protects your payload. Metadata is still floating through.

Who ever wrote this article is either a troll, or (1)

bloggerhater (2439270) | about 10 months ago | (#43999047)

Evil twin/ disassociation attacks are old hat and don't only work on apple devices.

I thought we had real geeks here?

The article didn't make sense and has been updated (1)

otuz (85014) | about 10 months ago | (#44000607)

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

Re:The article didn't make sense and has been upda (1)

WaffleMonster (969671) | about 10 months ago | (#44014647)

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.

EAP-SIM is broken.

Oh, really? (1)

bobmajdakjr (2484288) | about 10 months ago | (#44002673)

Not only is this not a discovery, since anyone with an ATT phone may notice their phone connecting to 'attwifi' when walking into mcdonalds and walmart, but it is not even iPhone specific. The LG Optimus G I got from ATT will join lolnetworks by default too. At least on that phone though it is more obvious to disable.

WiFi Pineapple (1)

netik (141046) | about 10 months ago | (#44007521)

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.

http://hakshop.myshopify.com/products/wifi-pineapple

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...