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.
* DNS and TLS (SNI) don't hide domain names, so you can't hide the fact that you're using certain sites/apps, even if they're HTTPS-only.
* If the OS doesn't require NTP encryption, HSTS can be bypassed: https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-By...
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.
This only help against MitM attacks, though. An attacker can still passively sniff traffic.
Am I missing something or should the author of this article provide more evidence on the type of attack?
Edit: SSL does not have to be used on the clone. Most people will not notice/care.
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.
* 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!
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?
There is a bit of a weak link with DNSSec, but in truth there are WAY easier ways to get someone's Facebook ID once you can spoof traffic to them.
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.
And to passively decrypt all network traffic.
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.
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.
Or is this already supported but nobody uses it?
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.
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.
Seems like a major security hole to me.
At least for Android, someone else agrees: http://code.google.com/p/android/issues/detail?id=65890
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.
Keep in mind that your devices are also broadcasting a variety of globally unique identifiers everywhere you go.
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.
People struggle with connecting their laptops/tablets to WiFi. Expecting them to configure a VPN on their own is a stretch.
You could start a small SaaS business that could make "lifestyle business" type money if you did this well.
I don't think ease is a barrier anymore. I think it's just lack of education about how necessary these measures are.
I am not associated with them in any way.
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.
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.
I thought for sure that name was fake!
http://www.rtlnieuws.nl/editienl/betrapt-door-wifi-ik-ga-vre...
VPN accounts are cheaper than ever before. You can also install one on a cheap DO box.
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.
import random
import os
mac=''
# os.system('/etc/init.d/networking stop')
os.system('ifconfig wlan1 down')
os.system('ifconfig eth1 down')
for i in range(0,3):
r=random.randint(16, 256)
mac=mac+":"+str(hex(r))[2:]
mac="00:07:E9"+mac
print mac
os.system('ifconfig wlan1 hw ether '+mac)
os.system('ifconfig eth1 hw ether '+mac)
os.system('ifconfig wlan1 up')
os.system('ifconfig eth1 up')
# os.system('/etc/init.d/networking stop')
os.system('/etc/init.d/networking start')
os.system('ifconfig')
print "echo 'MAC changed..."
print "new random MAC "+mac
Seriously, just VPN over the hotspot.
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...
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.
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)
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).
[0] http://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac...
