An interesting read, but sparse enough on details to be basically useless. Additionally, there's nothing that I can discern to be new here. The following is demonstrated, all of which are known (and in fact obvious) to people with even an elementary understanding of how wifi and TLS work:
* That wifi probes are public
* That wifi devices, by default, expose reasonably reliable evidence about their type and origin via their MAC address
* That many OS's automatically connect to 'trusted' wifi networks, regardless of their apparent physical location
* That many websites don't have TLS by default (or at all)
* That, if a user connects to a network you control and requests a URL not beginning with "https," it is trivial to present them with a fake page looking like the one to which they thought they were browsing (of course they won't see a lock) --(note: if the website has HTTP Strict Transport Security enabled and the user has previous visited that website with a supporting browser, then this part is non-trivial)
* That, if a user transmits unencrypted plain text over a wifi network to which you have access, it's trivial to glean the content of their transmission.
None of this is news, and it's all that this article seems to point out. Even more bizarre is that, almost without exception, it merely leaves these items implied, failing to describe the mechanism of action.
Seems like the moment a trusted wifi network is connected to, the system should try to geolocate itself and figure out if it is likely to be the same network.
Knowing what other networks are around is another approach. e.g. if I connect to network A, when networks B, K, L, T, U and X are all visible, the next time I connect to A, I can be reasonably certain that A is the same A as before if I see at least xx% of the networks that were visible the first time I connected to A.
Without setting up an evil-twin network, if the wifi network has client isolation turned on (i.e clients are only able to speak to the router), is it possible to perform ARP spoofing still?
Client isolation means, in most cases, that the router drops incoming packets on the wifi interface with a destination MAC address which is known to be on the same interface, effectively preventing wireless clients from communicating with each other. This prevents ARP spoofing if it's properly implemented.
This only help against MitM attacks, though. An attacker can still passively sniff traffic.
How was the hacker able to get Facebook credentials? Facebook uses HTTPS and so does Live.com. Even if I'm connected to a malicious router, only me and Facebook know about the data we're sending each other.
Am I missing something or should the author of this article provide more evidence on the type of attack?
I suspect it's not plain old sniffing. He might give fake DNS records to point to his own phishing site (facebook clone). It's trivial to re-post the credentials to the real facebook check the password and then actually log them in. curl can be used to do this, as I am sure many others.
Edit: SSL does not have to be used on the clone. Most people will not notice/care.
You can't spoof a certificate with DNS. Even if you spoofed a DNS response and made facebook.com point to 192.168.1.2 then the server at 192.168.1.2 (which could be yours) would still need a valid certificate for facebook.com.
The only way to have done this is by having the user click "continue" or "ignore" or something on an ssl error page. I know from experience that a company full of programmers will happily do that. Only a few percent would go "wait a minute, this is Facebook. That certificate should be valid." Some people here might reply "no way", but HN generally contains the one percent.
Edit: This is almost correct. You can actually prevent being redirected from http to https when typing in "facebook.com" without https:// in front. My bad.
Still though, the attentive user would notice the missing padlock. I check it 3/4 times, and 4/4 times when using a public network. I also refrain from using http sites where I log in (some forums I visit do that). But again, probably less than one percent of the tech people do that.
If you don't type the https url, you start by visiting the http website. Normally the http version will redirect to https, but a man in the middle can easily prevent this.
> If you don't type the https url, you start by visiting the http website. Normally the http version will redirect to https, but a man in the middle can easily prevent this.
This is not entirely correct. HSTS[0] was designed to protect against such attacks.
It's true, however, that not every browser out there supports it yet, and you must visit the website at least once without MITM for the server to successfully communicate HSTS header. (In Chrome certain domains are included in built-in list[1], though.)
Yes! I just thought of this and was going to edit it in, but you are quicker. Many websites still don't use HSTS, and in any case this article is from a few months ago (I remember reading it) and HSTS is pretty new.
also, most people are not savvy enough to check the ssl credentials or to even see that they are not on a ssl enabled site. even if the phishing attack was slow, people have lower expectations for speed in a coffee shop.
If an attacker controls the access point he could do the following:
* Redirect all HTTPS traffic to an HTTP spoof site. Many users probably wouldn't notice.
* If the attacker has access to a short, 2-3 character domain, they could redirect to a wildcard HTTPS connection like, https://facebook.aa.com/ - again, many users wouldn't notice. They'd see "facebook" and the lock icon and assume they're ok.
* In either case the attacker could simply proxy all HTTP requests from victim to Facebook (or any other site). So the user's browsing experience remains the same but all passwords, cookies and personal info are logged. Scary stuff!
Probably don't even need a short domain. Facebook.login.secureauthredirectsystem.moregibberish.com probably would seem sorta legit. After all, Microsoft's auth systems do crazy stuff like that. So does the moronic Verified by Visa system - it's something like "ww2.secpayment.com" and looks totally sketchy but it's legit.
Can you clarify the first point more? I would assume that if the user is able to connect to "facebook.com", then the connection would immediately go to HTTPS and the router could not "forcefully redirect" or do anything to the connection.
Alternatively, I could imagine a situation where the router hijacks the _DNS_ request for Facebook to a malicious site. Is that what you were referring to?
You can't redirect https traffic to http, without having valid certificate. But of course with all these CA problems, it could be possible to arrange one. It's then another story, if users use http -> https recirection in first place. Due to leaving the https prefix out from the url when connecting the site very first time. That's immediate security fail, but it's up to users to get this straight. HSTS won't help because due to privacy mode, all data between browser sessions will be purged, including HSTS data. Any failure to purge any data between sessions, could break privacy, because then it's known that you have already visited that site. But these questions are quite complex. Which is best configuration for each situation needs to be very carefully considered. I personally like DANE, if I would be running any serious service, I would configure it. Some of my friends have already done that.
In the original Dutch article (https://decorrespondent.nl/845/Dit-geef-je-allemaal-prijs-al...) the author explained in the comments that they used SSLstrip for facebook and live.com
So, the connection was over HTTP and not HTTPS.
They added a padlock favicon.ico image to give the impression the site was secure
Ah. I wonder how hard would it be to extend protocol to let Facebook, for example, state that they will never go https again, so that browser would scream.
Most people don't understand the WPA PSK security model and its insufficiency for anything but private networks where every device is trusted. When you give someone the PSK, you give them the capability to impersonate the access point.
That being said, is there any better solution for public networks? One where giving someone a password doesn't let them impersonate you. I'm not sure how good support for EAP-TLS is on common client devices. To actually make it secure the device would not only need to support it but also validate the AP's public key some way.
since theres no url associated any trusted ca-signed cert is valid (for example a cert from startssl).
if you use self signed that actually protects you since then the client complains.
SOME clients pin the certs (thus you cant impersonate the AP even with a trusted CA-signed cert) but its still quite rare.
But in theory the same CA infrastructure as used for the web could be used. The SSID of the network would be interpreted as the "domain".
So if I try to connect to SSID example.com securely, I would verify that the AP can identify itself as example.com (based on the CA roots which I trust) - exactly the same way as a web browser would if I tried to connect to https://example.com.
I think there are a couple of things that would have to happen in order for that to work:
1, we would have to set up a global registry for SSIDs, like we have for domain names. (Otherwise, what's to keep someone else from using a colliding or misleading name and getting a certificate for it?) And even then you run into the problem that the CA infrastructure used for the web is pretty terrible.
2, clients would need some kind of policy database to know what kinds of traffic must go over a "secured" AP and what kinds, if any, can go over the local coffeeshop's or convention hotel's wifi.
And all of this to secure just one link of the communication— all the rest remain vulnerable. Really what we want is end-to-end encryption, not link-by-link encryption. If you have #2, for example, you could instead use that policy database to implement mandatory IPsec (or equivalent end-to-end encryption; MinimaLT if you prefer) for all sensitive traffic, and bingo, you're secure against whole classes of attack even when you are using unknown APs.
Interesting but dated info for techies. I was hoping for something more along the lines of how retailers triangulate & track your movements inside their brick & mortar sites. Or how public providers scrape your browsing habits whilst on their net. I was even more interested in learning what other tricks they employ that I am not yet aware of.
With the ubiquity of broadband mobile I recommend avoiding public wifi whenever possible because the items listed in TFA are ubiquitous at most Starbucks, airports and other hi-profile public spots. I also highly recommend disabling any equipments' wifi by default, the world is full of liars, cheats & thieves smarter than myself. When you go for "free", what you get never is.
Yep. Whenever wifi is enabled, your device is sending out probe request frames, which includes your list of preferred networks/networks you've connected to before.
Could it be used as a sort of fingerprint to identify phones? I'm imagining using a scanner to create a list of phones in the area. You walk through the halls of congress to compile a list of devices. Do this every few days or over the course of a month, to eliminate visitors.
Now that you have your fingerprint, you can leave a few scanners around where you're trying to track the congressmen. IE, if you want to blackmail, put it around strip clubs.
It's called "active scan", and it's one of the default behaviours that I'd really like an option to disable, since (unless you hide the SSID) APs will broadcast beacon frames announcing their presence anyway.
For iOS you can use iPhone Configuration Utility or similar to add profiles for WiFi-networks, and set their SSIDs to be always broadcasting. That option should make it so that those names aren't included in the active scans, if it is to make any sense.
It also allows APs to be "hidden", by not broadcasting its own SSID, but relying on devices to send out a probe to ask if it's there. Of course, it's not hidden from packet sniffers if it's talking to someone.
To an extent it is; if your phone never connects to any WiFi device (and instead uses GPRS / EDGE / LTE etc... to a mobile carrier), and your laptop only ever connects to your phone, then the probes the attacker will see are for your laptop probing for the SSID of your phone. Given an appropriately vague SSID, this doesn't give the attacker much information (c.f. connecting to access points everywhere and giving away that list of SSIDs).
If you use WPA2 PSK and choose a long, random password (you want enough entropy that brute forcing it is impossible - for example, 20 completely random and independent characters taken from a dictionary of 62 characters gives you ~105 bits of entropy, which should be enough, while 8 characters or a few dictionary words might not cut it) impersonating your phone is not feasible if your laptop is configured to only ever connect using the saved pre-shared key.
Yes. They are called probe requests, and can be easily intercepted and viewed. Multiple programs exist to grab these requests off the air and stand up wireless networks with that SSID.[1]
You could brute force it by using common network names and seeing which ones get bites. Take it a step further and generate expected patterns ie. "2WIRE123". I'd expect "linksys" alone would grab a surprising amount to start, though.
Exactly, even if it's not broadcasting network names, almost every student in the Netherlands will have the train's WiFi hotspot in their list of networks.
One thing I still want to check out is whether the laptop will connect to an open network with the same name as a known network that was password protected.
Hm. So are there any 802.11_ proposals for cryptographically "signed" SSIDs? Using public key cryptography, this is surely doable in a way that is "anonymous" too, right? (i.e. doesn't reveal the identity of the AP you're probing for)
How sure are you that your cheap anonymous VPN isn't malicious and hasn't been hacked? Is that more or less likely than an attacker being on the same physical wireless network as you?
obviously people able to setup their own VPN arent the target. even when connecting on open wifi without vpn im pretty you would spot anything suspicious
True. But I'm able to send all traffic through an encrypted tunnel so that nobody listening locally can get their hands on it. And if I wanted to, I could then tunnel all traffic over some other service to anonymize it.
If you set up the VPN yourself they can be both cheap and relatively secure/private (e.g. EC2, Linode, etc).
I'm not sure how much I'd be willing to trust people selling anonymous VPN services. Many of them are located in untouchable countries and knowingly provide services which violate various laws (e.g. one I used to subscribe to had a specific tab for copyright notices).
If you dig down into who operates many of them you come up quite empty handed. No address, no name, just a few more shell companies and then a dead-end.
HTTPS certainly makes you more secure while using them, however you leak a lot of information in general as a lot of stuff is still HTTP. You trivially build a full picture of someone (name, literal picture, DoB, et al) over a week of watching their insecure web-traffic.
Plus if you're depending on HTTPS then what is even the point of an anonymous VPN? Might have well just use the dumb WiFi and assume that everything HTTP is world-visible.
PIA gets a lot of recommendations but no one ever mentions that a great number of sites prevent you from using them from the PIA addresses. I've had a lot of trouble with financial and e-commerce sites in particular (which are also the situations I really care about using a VPN).
I think it might be that PIA is frequently used for DDOS and abuse since it's so inexpensive.
Just something I wish I had known before signing up.
As a developer, I would actually have to read up to know exactly what a VPN is and what I can do with it. I have a rough idea, but as it has never been something I have worked with, I have little knowledge of them. Now how would you expect the general public to manage, without someone giving them a decent explanation of them.
Private internet access (dot com) provide a point and click interface for windows and mac os x. On linux one has to manually config but it's not that hard. I have had non-technical people use it with no issues. I am sure there are others out there.
Where did you read this? I haven't check in in a while, but I remember doing research to ensure the provider I used wouldn't be logging - and I settled on PIA.
People are just not aware of these problems, and when you tell them they often downplay them, because they seem far away and until something goes wrong they think it can't happen to them. Also, it's not easy to convince people to pay for prevention rather than to fix an existing issue.
> Considering how ridiculously cheap an anonymous VPN service is
You're already paying for your Internet connection at home, why bother getting another VPN service? At least in our FritzBox (free from the ISP) you can configure VPN. And besides, I trust the established ISPs here more than RandomSuperVPN Inc.
Depending on where you are in the world, home/SoHo broadband might not have enough upstream (1 megabit is common in Australia) to support a VPN - however it might be enough to do your banking or whatever. Now to make it user friendly.
I see a lot of comments here presenting HSTS as some kind of silver bullet for preventing MITM attacks. While it does help, it's not impenetrable. If a website hasn't been preloaded into the STS preloaded list, then the HSTS header can be stripped on the first visit and the client will never upgrade to SSL.
The only foolproof way to make sure you're not being MITMd is to visually verify that the domain checks out and that you are indeed connected using SSL.
I've read about this kind of thing before, so when I'm in public, or even at school I prefer to fire up my phone's personal hotspot instead of using any public wifi available.
why aren't 'know networks' gps-geofenced on smartphones? You have GPS, if your previous 'known network' (say, home) was in location X, it should not automatically connect (or even try to connect) to it at X + 20 miles.
This way you should be able to keep your phone from connecting automatically to (or even looking for) a network that shouldn't be there in that location in the first place, and if you always tether to it it would work for your laptop too...
For that to work the networks themselves would have to securely distribute a list of locations, or it would have to be configurable on the devices. Many business and educational networks (like eduroam) span multiple locations. Even my "home" network is available multiple places (home, cottage, boat...).
Smartphones mostly use wireless networks and cell towers to determine their approximate location, which can be easily spoofed, except for the current active cell (which could be miles away). If devices had to acquire GPS fix every time they reconnected to a network, batteries would drain much faster. And satellite navigation doesn't work properly indoors. Civilian GPS can also be spoofed.
Manufacturers would probably prioritize usability over rectifying such a "problem" which never had bothered anyone before, except maybe if there was PR involved. I think there's still no way to list all configured wireless networks on iOS devices? Fixing this would probably improve privacy more (if people cared) than this randomized MAC feature.
I am not really sure why networks would have to distribute a list of locations: the default for connecting is simply 'do not autoconnect or look for any network I have not already connected previously in this location'.
If the user does not want to incur the GPS battery impact triangulating with cell towers already should give you enough location information not to look for your home network at work, or the network you saw in Spain last month when you are in the Netherlands.
And finally obviously everything can be spoofed, however I don't think it's reason enough not to have a minimal set of protections: the user can decide how much battery to dedicate to the task (i.e. no checking, cell tower checking, gps checking in increasing order of impact)
Because the "WiFi in de trein" network could be anywhere. It's the name of the free wifi of one of the large public transport / train corporations in the Netherlands.
The only solution is to not autoconnect, ever, or some sort of clever certificate pinning type of solution. Like, I could download the certificate from the (https) site of the train company, and be sure that the network I see claiming to be "WiFi in de trein" is in fact theirs. Ziggo (a Dutch ISP) does something like that when they turn all their customers' wifi-routers into semi-public access-points (for Ziggo customers). Unfortunately their solution has a few snags, as well (but it's really cool, I basically don't need a data plan).
Most devices will connect if the SSID and the security protocol is the same. If they set up a network with the same SSID and security protocol, using the same password (that they asked the waitress for!), then devices will automatically connect to it.
WLAN only cares about SSID. This is how you get roaming mode where you move between access points without losing connectivity (most Universities, company campuses, etc will have this setup)
You can't, of course. But even if you could, many networks allow for ARP spoofing so connecting to the right access point is not really the solution. And if ARP spoofing is not possible then you run airmon-ng and wireshark.
You would have it stored from a prior connection to the network. Of course, it's trivial to spoof that too so the additional check doesn't do any good.
I wonder if it's true that iOS 8 only randomizes device's MAC when the SIM cart is not installed[0]. Was stoked to learn about this feature, too bad it apparently doesn't work as you'd expect it to.
An interesting read, but sparse enough on details to be basically useless. Additionally, there's nothing that I can discern to be new here. The following is demonstrated, all of which are known (and in fact obvious) to people with even an elementary understanding of how wifi and TLS work:
* That wifi probes are public
* That wifi devices, by default, expose reasonably reliable evidence about their type and origin via their MAC address
* That many OS's automatically connect to 'trusted' wifi networks, regardless of their apparent physical location
* That many websites don't have TLS by default (or at all)
* That, if a user connects to a network you control and requests a URL not beginning with "https," it is trivial to present them with a fake page looking like the one to which they thought they were browsing (of course they won't see a lock) --(note: if the website has HTTP Strict Transport Security enabled and the user has previous visited that website with a supporting browser, then this part is non-trivial)
* That, if a user transmits unencrypted plain text over a wifi network to which you have access, it's trivial to glean the content of their transmission.
None of this is news, and it's all that this article seems to point out. Even more bizarre is that, almost without exception, it merely leaves these items implied, failing to describe the mechanism of action.