by ricksta on 10/18/14, 6:48 PM with 110 comments
by jMyles on 10/18/14, 11:32 PM
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.
by sktrdie on 10/18/14, 8:55 PM
Am I missing something or should the author of this article provide more evidence on the type of attack?
by ambrop7 on 10/19/14, 5:57 AM
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.
by tunap on 10/19/14, 2:49 AM
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.
by fredsted on 10/18/14, 8:49 PM
by ris on 10/19/14, 11:12 AM
by xamolxix on 10/18/14, 9:01 PM
by byoung2 on 10/18/14, 9:52 PM
I thought for sure that name was fake!
by z92 on 10/19/14, 5:21 PM
VPN accounts are cheaper than ever before. You can also install one on a cheap DO box.
by VexXtreme on 10/19/14, 4:25 PM
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.
by tiatia on 10/19/14, 1:03 PM
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
by JoshGlazebrook on 10/19/14, 12:15 AM
by tetraodonpuffer on 10/19/14, 4:25 PM
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...
by tcdent on 10/18/14, 8:59 PM
by goblin89 on 10/18/14, 10:09 PM
[0] http://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac...
by yuhong on 10/18/14, 8:22 PM
by ColinWright on 10/18/14, 7:11 PM