Windows 10 Wifi-Sense - Discuss how to detect and block.
-
I have just read about this ridiculous feature that is going into Windows 10 that gives your contacts the passwords to wireless networks that you connect to. I guess the staff at Microsoft product development are unaware of social engineering hacks.
http://www.theregister.co.uk/2015/06/30/windows_10_wi_fi_sense/I am reasonably certain how I am going to implement this but I am also interested in how others think they would do it.
How would you do the following on pfSense and why?
1. Detect wifi-Sense capable devices (Windows 10 and Windows Phone 8.1) that connect to your network by any means.
2. Automatically lock out all Windows devices that have Wifi-Sense capability, deny them network service.Some ideas to start you thinking…
-
A captive portal with device/browser detection.
-
Prior physical identification. MAC address access list on switches and access points.
-
Isolate all secured wireless networks on site. Must have credentials to the only VPN available to escape the containment.
-
As above but make all wireless networks open, no password needed for wifi but credentials needed for VPN out.
One special case to consider is Windows 7 devices that currently have access must be denied service after upgrading to Windows 10.
-
-
It is my considered opinion that Microsoft's Wifi-Sense feature breaches my organisation's network security policy by:-
1. Disclosing the WPA2 PSK to an unauthorised third party (Microsoft).
2. Using the PSK transmitted to Microsoft to bypass the organisation's access controls by providing unauthorised third parties access to private resources.
3. Bypassing a necessary step in the audit trail by failing to submit a completed Access Request Form to be considered before being granted or denied access.So how best to detect and block Windows 10 devices?
-
Normally when some Microsofts crap comes out -The open source world would come out with a return volley like WPA3 to upsurp the effect but with WPA in so much hardware this is a tough cookie….I was messing with FreeRadius2 authentication but it has drawbacks with regard to legacy products... We really have zero alternatives in reality.
-
http://www.windowsphone.com/en-us/how-to/wp8/connectivity/how-do-i-opt-my-network-out-of-wi-fi-sense
To opt your network out of Wi-Fi Sense, you can change your network name to include the phrase _optout in it—for example, mynetwork_optout. (The network name is often called the SSID.)
That's a wonderful solution to this "brilliant" idea, really! Pure genius!
-
The thing is with '_optout' or '_nomap' is that you are expected to trust the organisation that would be breaching your network security policy to respect your wishes.
I am thinking about reconfiguring all of my wireless access points to open configuration without WEP, WPA or WPA2. However, these wireless networks will only have access to a single host, a captive portal on port 80 that is also a VPN endpoint.
The portal will display an agreement that must be accepted to open the network to further ports and destinations. This agreement will provide the portal operator the ability to conduct any/total surveillance on their use of the resource provided including saving captured packets for offline analysis. It is this agreement that provides the legal basis to identify and discriminate against Windows 10 or other devices.
After 'digitally fingerprinting' the connected device (Panopticlick), the portal decides if a submitted access request has been granted and offers a download link for a self-signed certificate from a private intermediate certificate authority. The certificates will have a short expiry, I am thinking a day to seven days maximum. A VPN can then be established to private network resources. The VPN system will have to be capable of preventing a connection for expired or revoked certificates.
pfSense provides a large number of these building blocks so I am going to look at putting a system together that can do this.
-
The thing is with '_optout' or '_nomap' is that you are expected to trust the organisation that would be breaching your network security policy to respect your wishes.
I was not suggesting that as a solution at all. If they were actually concerned about security and privacy, they'd tell people who wish to send their wifi credentials to MS to put _optin into SSID instead. (And I definitely can see the huge crowd doing so… ::) :P)
-
I have started to wonder if other devices may already be copying PSKs to an undisclosed central server. Perhaps, it is safer to assume that all devices are compromised in this way and to build an access control system that works in this situation.
I have been thinking about using a blockchain to record the comings and goings of all devices: ARP, NDP, Mobile VPNs etc. The blockchain would be distributed to all clients and servers on my network. Obviously, this is going to need some development; but I like the idea of a multiple distributed copies of verifiable access logs.
-
There certainly are Android apps doing similar things… (No idea about Bitten Fruit -- these are banned for mental sanity sake here. :P)
-
At my work I have a seperate subnet for WiFi, and give the very simple password to everyone. Without VPN you are limited to a few ports. This is a rather simple setup.
An other option would be to not use a PSK, and use the 'WPA enterprise' options. This uses a radius server.
However, I would still like to block windows 10 and windows 8.1 phones. Give them 'access' but let them only access a page that says 'go away, get a real phone' or 'please upgrade your operating system'. ;D
-
You would have to block talking to where ever it is they send the info.. But as soon as they are one some other network they would be able to share this.. I really have to think this whole thing changes.. Your going to see massive move to using other authentication methods other than just knowing the psk that is for sure.
Vs being _optout on your ssid it should have to be something that opts you in like _share or _wifisense or something..
When will MS ever learn? This is a horrific idea when it comes to security.. For open guest networks sure great, you don't have to know the psk for billys tavern, etc.. But why would billy have a psk on their open wifi in the first place?
Can tell you user will no longer get my psk to my normal wifi segment, and they will have to use the guest wifi without any psk on it with voucher system going forward.
-
Use wpa radius EAP-TLS, and make sure whenever a client connects, you tie mac+cert together in the radius server database. Then each user needs a separate certificate for each device that he or she wishes to connect to the network. Problem solved.
-
I'm fairly sure Wifi Sense does not work- and will never work- with WPA2 Enterprise networks. I just set up a separate VLAN with a guest wifi AP using WPA2 Enterprise. I set up long-term RADIUS user accounts for different people that come over regularly, and I'll create a generic Guest account for one-off guests.
Honestly, I wish everything supported WPA2 Enterprise. It's much better than WPA2-PSK, even if you only use a single username/password. Anyone with the PSK can trivially capture and decrypt other users' traffic. WPA2 Enterprise, on the other hand, negotiates a different key for each client. I'd move everything to WPA2 Enterprise if I could, but unfortunately I have too many devices that don't support it (e.g., Chromecast).
-
So you don't think wifi sense could store a username and a password vs just the psk??
The point is not that they can sniff other users traffic while on your network, the point is that they could get on your network in the first place.. Using something like EAP-TLS would prevent the sharing of the username and password from allowing access to the network.
As to your enterprise vs psk for stuff that doesn't support it - then just run a ssid that uses psk for those devices.
-
So you don't think wifi sense could store a username and a password vs just the psk??
Could it? Sure. But it would be an incredibly stupid move. I don't think Wifi Sense was a great idea to begin with, but I can understand why someone would view it as a compelling feature with minimal security impact. In practice most people are pretty quick to share Wifi passwords. At least this way you don't need to directly hand over the password. And users still decide what they will share. If you give your friend your wifi password, there's nothing stopping them from turning around and sharing it to others. The semi-automatic nature of this makes me uncomfortable, though.
But, there's absolutely no expectation that users would share EAP/PEAP credentials in the same way as WPA-PSK passwords. So, there's no legitimate reason to do it, and there's certain to be a lot of angry corporate customers if they did.
The point is not that they can sniff other users traffic while on your network, the point is that they could get on your network in the first place.. Using something like EAP-TLS would prevent the sharing of the username and password from allowing access to the network.
As to your enterprise vs psk for stuff that doesn't support it - then just run a ssid that uses psk for those devices.
While it wouldn't happen, Microsoft could just as easily share EAP-TLS keys as WPA-PSK or PEAP passwords (assuming they're "soft" credentials, not keys on smart cards). If you don't think Microsoft has any common sense left, EAP-TLS is any better than PEAP.
Anyways, my comments on WPA2 Enterprise were more of an aside, rather than being directly related to Wifi Sense. My point was merely that if you're running a wifi network where you're fairly widely sharing the key(s) to access it, you're much, much better off if you use WPA2 Enterprise, rather than WPA2-PSK.
-
Hello everyone,
pfSense comes with a really good captive portal that can perhaps be used to solve this clients out.
If I visit the Adobe website, and want to update or download a new version of their flashplayer,
the Adobe website is knowing my OS and the by me used browser! Even I do so! So there must
be code inside of the website to find this out, to offer me the right flash version for my OS and
used browser, likes:Windows 7 64Bit and Opera as an example.
So if now this code will be placed inside of the captive portal "Welcome page" of pfSense it must
be also able to gain up those informations like, Windows 10 or MS WiFi Sense from the WiFi clients
that tries to join the captive portal page, or am I wrong now with this?And based on this informations the user will be then lead;
- to another website (redirected) with a explanation or declaration about
their OS status and that they would be, let us call it, classified or judged
as a security problem and can´t join exactly this network, related to MS
WiFi Sense or Windows 10 or what ever. - Or likes all others XP,7,8,8.1 will be directed to the real login page of the captive portal
Is this able to realize with the captive portal homepage, some rediretion pasges and some
code like the code used by the Adobe website?- captive Portal is there
- redirection pages must be defined (login and deny page)
- the code must be adjusted or updated for sure?
- to another website (redirected) with a explanation or declaration about
-
"My point was merely that if you're running a wifi network where you're fairly widely sharing the key(s) to access it, you're much, much better off if you use WPA2 Enterprise, rather than WPA2-PSK."
Somewhat agree - running a enterprise in an open wifi network would be a PITA.. It is clearly way more complicated of a setup, for guests I would put them on their own wireless network vs one shared with say employee's anyway. Be it your employees used enterprise or psk.
Your point about enterprise support on devices is key point here, you can not be sure that the device a guest is using will not balk at invalid cert, or even support it at all. For sure it is way more complicated for "guests" to connect to that is for sure. Shoot many users have problem with something as simple as captive portal, and if it does not support and use a valid cert for the ssl connection even more sore. Shoot apple devices log in method will not even work without a valid cert and user has to launch a browser and accept the invalid cert to even get to the portal some times, etc.
If your using a guest network you should have no expectations that the traffic is not being viewed by others on the same network and take precautions on your own to secure your traffic if your worried, etc. All of which is beyond comprehension of your day to day users sad to say.
-
Somewhat agree - running a enterprise in an open wifi network would be a PITA.. It is clearly way more complicated of a setup, for guests I would put them on their own wireless network vs one shared with say employee's anyway. Be it your employees used enterprise or psk.
Your point about enterprise support on devices is key point here, you can not be sure that the device a guest is using will not balk at invalid cert, or even support it at all. For sure it is way more complicated for "guests" to connect to that is for sure. Shoot many users have problem with something as simple as captive portal, and if it does not support and use a valid cert for the ssl connection even more sore. Shoot apple devices log in method will not even work without a valid cert and user has to launch a browser and accept the invalid cert to even get to the portal some times, etc.
Agree, mostly, on all points. Certainly it's good to separate your enterprise network from your guest network.
But, I think WPA2 Enterprise support is complicated because we've (the collective "we") have allowed it to be complicated. If you let your devices connect to open or WPA2-PSK networks (as nearly everyone does), then there's no reason not to let them connect to WPA2-Enterprise networks without warning about certs. There should, of course, be a way to configure certain profiles/networks that will enforce cert checks, but I don't see why they are always checked, given that in other situations we're happy to connect to unauthenticated APs.
(Presumably the poor device support for WPA2-Enterprise is due in part to the more computationally-intensive crypto required. But I'm sure things like a Chromecast or Roku have the power to set up a TLS pipe. It seems like much less of an issue today than it might have been 10+ years ago.)
And while I agree with your general point about not trusting guest networks, I think it's a bad model if different wifi users on even a trusted network can snoop on each other. There's very little justification for that, given just about any device now can do a TLS negotiation in a reasonable amount of time.
@BlueKobold:
And based on this informations the user will be then lead;
- to another website (redirected) with a explanation or declaration about
their OS status and that they would be, let us call it, classified or judged
as a security problem and can´t join exactly this network, related to MS
WiFi Sense or Windows 10 or what ever. - Or likes all others XP,7,8,8.1 will be directed to the real login page of the captive portal
If you're using captive portal, why even lock out Win10 users? Wifi Sense isn't going save and share the captive portal username/password.
- to another website (redirected) with a explanation or declaration about
-
The initiate thread was started by @vbentley with one of this main questions;
A captive portal with device/browser detection.
And yes I consider to do so and believe this way.
If you're using captive portal, why even lock out Win10 users?
This was the entire question starting this thread along it was changing a bit of
course this is normal in a discussion and it comes closer to the second question
set by @vbentley;So how best to detect and block Windows 10 devices?
As today WiFi networks and also the local country laws are quite different from
each other I would be not suggest everybody the same idea, because he can
surely get much problems in his country, this at first.And for sure it is really often not the same if I am inside of a corporate network,
inside a coffee bar with public WiFi access or inside a auto garage that offers also
public WiFi inside of the car store!To setup a open public WiFi network can be a good choice if you are hired and there
is a party, smaller music concert, lan party or a unique events, for sure this could be
running to narrow down the entire cost and complexity. Or perhaps an official installment
like an public park with from the major or cityhall offered open WiFi mesh network, this is
really often to see more and more in today days. But in all other fields this is a NoGo area.In our company network we use a captive portal with a voucher system, that delivers
the voucher to each mobile device, so that guest can fast connect to the Internet only
if we have meetings in the company. We were setting up it in this direction:- company network cable based devices auth. over LDAP server - internet & company network
- company network cable less devices auth. over Radius server in an extra vlan - internet & company network
- WiFi Guests over the captive portal with voucher system in an extra vlan - internet only
- private devices, but from the employees, checking their email in the lunch break in an extra vlan - Internet only
WPA2 AES-CCM & 2048Bit certificates installed local at the company devices
client isolation is enabled on all WiFi vlansOSSec - host based IDS
Snort - network based IDS -
@BlueKobold-
I understand the original question of the OP. But in the OP itself, along with the follow-up posts, it seems like @vbentley is concerned about blocking WiFi sense devices from sharing information sufficient to get access to network resources.Now, I always hate it when people jump on OPs asking how to do something in a thread only to tell the OP that their proposed solution is wrong and they should do it a different way. The situation here is a little different. The OP has laid out a fairly coherent list of concerns with the impact of Windows 10's WiFi Sense feature on their network.
As far as I can tell, any plausible solution to (strongly) blocking WiFi Sense involves some combination of: 1) separate VLANs for guests, 2) client isolation, 3) captive portal, and 4) WPA2-Enterprise using EAP-TLS or PEAP. And any combination of those technologies sufficient to guard against WiFi Sense appears to be sufficient to protect your network even if Windows 10 devices (with WiFi Sense enabled) get on your network.
While the OP asked about blocking Windows 10 devices, it appears to either be based on: 1) a mistaken belief that it would help address the threat of WiFi Sense, or 2) general rage against Microsoft and/or Windows 10, resulting in a desire to block such devices out of spite.
There may be legitimate reasons to want to block Windows 10 devices, but I didn't see any concern listed in this thread that would justify that. And if you have a legitimate reason to block Windows 10 devices, I'd think you'd want to use something stronger than just a User-Agent check, which is probably all Adobe (and other websites) do. FreeRADIUS supports Microsoft Statement-of-Health claims with PEAP. I bet you could configure it to look at the Windows version number to reject Windows 10 devices.
-
My point was that EAP-TLS with MAC locking would just automatically block any attempt to share the network connection with another host, period, including wifi-sense.
