If you really want to be scared about wifi, using airbase I can spoof your probes into thinking you're at home/work/school and your device will just automatically connect to me.
Lets say you go to starbucks and I've got my honeypot running, you will automatically connect to my laptop and I'll just spoof your probes into thinking I'm your network. While connected to my smartphone or even starbucks wifi I can see everything you do in clear text, spoof ssl, and then with driftnet see all the images you look at, and use ettercap to steal your sessions if need be.
And the best part, if I show up and starbucks is already full of people I'd like to play with, I can just deauthenticate them all for a moment, and when I turn off the kill switch they all connect to me. None the wiser.
No offense, but it doesn't sound like you know fully what you're talking about.
As someone else said, for WPA, you can't simply spoof the home base. You have to know whatever password the device is configured for. And even if you did know that, you'd have to spoof the same MAC address for most computers to communicate with the device, which is more likely to just break everyone's internet connection, since the whole communication protocol relies on MAC addresses being unique.
> And the best part, if I show up and starbucks is already full of people I'd like to play with, I can just deauthenticate them all for a moment, and when I turn off the kill switch they all connect to me. None the wiser.
Once again, the only way they're going to auto-connect to your network is if you have the same MAC address and password, and the interference would kill you. You're more likely to get fish on the hook if you make an AP with the same name and hope you trick some people who are frustrated with you shutting down the other network into trying it.
> Wifi security is a misnomer.
Not if you actually use WPA2, pick a good password, and make sure your users aren't connecting to random unsecured networks with the same name.
> No offense, but it doesn't sound like you know fully what you're talking about.
About that ...
MAC addresses are not checked unless you use an extra tool for this. For example, a large institution (university, company, etc) can have many access points, each with a unique MAC address. However the SSID is unique among all Access Points. Your device will only check the SSID, try to connect (using mutual authentication), but no MAC address checks take place. You don't need to know or use the MAC address of the target network to clone it. You can just use any MAC address you want, that is if you know the password of it, or are cloning an unprotected network.
Yeah, I wish I could edit my post, but I believe I was wrong about the MAC address needing to be the same. The major point is that the network needs to be unsecured and/or you already know the password. At that point, creating your own faux base station doesn't make a lot of sense when you can just sniff the packets on the wire or do arp poisoning to route traffic through you (if you want to modify traffic in real time, which is what I'm assuming he was referring to when talking about the SSL stuff).
Either way, Wi-Fi security certainly != "a misnomer."
That's fine, you can say no offense and then just say I don't know what I'm talking about, but I've used this all too often. The point of airbase-ng is to do all the things I described. You can read about what it's capable of here:
Starbucks, and most other 'portal' WiFi, is unencrypted. It would be nice if there were some (automated) method of 'upgrading' the connection (i.e. providing encryption without requiring the user to acquire and input a password). Maybe providing it over an SSL connection after you've agreed to the ToS?
The cheap (flawed, but better than nothing) way is to have the SSID be something like "Businessname Public (Password: iev8eiM9)" or similar, or just have it on a blackboard inside, which has the bonus of stopping people outside using it so easily.
The whole standard it a mess; it should have opportunistic encryption on open networks, then clients can display a warning if this doesn't happen for whatever reason ("Anything you send or receive over this network may be readable by others" or similar).
Wifi encryption is not going to help you much if anyone is able to connect to the network by just asking for the password, it won't protect you inside the network. If you want to be safe use a VPN or SSH tunnel onto a server you trust.
Sure it is. Each separate WPA connection involves a unique nonce (actually four, IIRC); my laptop and your laptop aren't using the same key even if we sign in with the same password. (This gets to the problem that WPA is being used for access control, which is not what it's actually "for", but that's a separate question.)
If you are sniffing the 802.11 frames (and you should assume someone is) and you catch the entire 4-way handshake and the nonce generation is predictable you could reverse-engineer it, but then again you can say the same thing about a TLS connection too.
All WPA or WPA2 secured networks use mutual authentication. Since you do not know the password of my home network, my device will refuse to connect to it. In particular the 4-way EAPOL handshake will fail, since the challenge-response algorithm detects that you don't know the password. This is "only" an issue if you have open networks in your Network List.
I do agree with you that 802.11 security is lacking, but it's not always as straight forward as you make it out to be.
It's early and I may be forgetting something....but assuming their home network isn't an open network, how would you get a client to authenticate to your rogue network? Even though the client would think it was the same network, authentication should fail because the client would attempt to use the stored credentials, and you almost certainly wouldn't know their passkey. Thus, causing the client to receive a message indicating an issue with authentication.
Are you inferring that you would brutal force the WPA2 passkey for their network with something like cowpatty? Are dictionary attacks really that easy to pull off these day? Mind you, it's been almost ten years since I've played around with WiFi cracking.
It's so much easier than you think. Your laptop sends out a probe asking if "home" ssid is there. My laptop says "yep, I'm home!" and it connects. As easy as that. It doesn't matter if your home network was WPA2 or PEAP, it connects you and you're good to go.
Usually in a place like starbucks the open wifi is open so I can just pretend to be that network and force everyone to connect to me instead.
I just checked my wireless controller to verify my thought process, and each time I switched wireless profiles (all of which are saved on my device) the 802.1x auth(EAPOL) process is used. I'm a little rusty on my wireless security, but wouldn't this same process occur for the rogue network?
Like you said though, if you sit in an area with existing open wireless, none of that will come into play.
Almost positive, I tested it on my machines and my friends laptops while in college. I remember it working because I could see the SSID that their machine connected to, which at the time was LEAP or PEAP authentication and they were able to browse the web without fail. Their machines were macs if that makes any difference.
So... my home network's SSID needs to be set to "home" for that to work? You are just spoofing an SSID? That's not so bad. Usually when TWC, ATT, etc, give you a router/modem it is set to some random string. A lot of people don't change that (lived in 7 apartments in 5 years), so you'd only grab the people that literally set their SSID to "home" then.
If your laptop is used to connecting to "home01284", it will send out a probe "hey home01284, are you out there?". Anyone nearby who gets this packet can respond, "yes, I'm home01284, connect to me!" They don't have to know a priori what SSID you were looking for, because your machine specifically advertises it.
If you're already connected to the same network/AP you can just ARP spoof[1] to MITM your victim, but any service halfway serious about security is already using HSTS[2] for some time now so SSL stripping/downgrade attacks are not going to work, well except of course for those Lenovo laptops equipped with SuperFish, thanks Lenovo!
What you're talking about works for unencrypted networks, but you can just grab that data off the air anyway. It won't work for WPA2.
>spoof ssl
Only if either they blindly accept invalid certs, or you somehow already installed a root CA on their boxen.
Sounds to me like you found an all-in-one tool, which doesn't make you understand how the process works or its limitations. I would agree that many wireless networks are hideously insecure (why I SSH tunnel my traffic when I'm on one), but it isn't that bad unless you're either running unauthenticated or using WEP.
From what I read about Android elsewhere, if you originally connected to the network by typing its name, it will broadcast the network name when searching. If, however, you originally connected to the network by selecting it on the list of nearby networks, it won't broadcast the network name when searching.
There's an app called "WiFi Advanced Config Editor" (https://play.google.com/store/apps/details?id=org.marcus905....) which shows in detail how a saved wifi network is configured. I believe that whether it will broadcast the network name or not is displayed as the "Hidden SSID" checkbox.
If I'm reading that code correctly, it sets the "scan_ssid" variable (WifiConfiguration.hiddenSSIDVarName is a public static final String containing "scan_ssid") according to the value of the WifiConfiguration.hiddenSSID variable. As documented in the WifiConfiguration class (http://androidxref.com/5.1.0_r1/xref/frameworks/base/wifi/ja...):
"This is a network that does not broadcast its SSID, so an SSID-specific probe request must be used for scans."
But were these networks added by selecting from the list, or by typing their name? From what I read, that's what makes it set the internal "hidden SSID" flag, not whether the network actually has a hidden SSID or not.
See for instance the post at http://forum.xda-developers.com/showthread.php?t=2634042 ("Any network added manually with the '+' icon will have scan_ssid=1. Any network picked from the list of scan results will not have a scan_ssid property.")
It does this for networks picked from the scan results - I might have been mistaken about one or two networks, but I see the probes for multiple networks I'm sure I picked from the list.
This is worrying. When I tested some time ago (at home, so next to my home SSID), I saw only a broadcast probe quickly followed by it connecting to the network. Perhaps I should try again, but powering down the AP first.
Did you try the "WiFi Advanced Config Editor" or similar to see what Android thinks about these networks, to see if there's a pattern?
I looked at my wpa_supplicant.conf. None of the networks have scan_ssid set. I'm unsure how often this happens. I have a probe logger running 24/7 at my apartment with four radios, but it only logs the first probe it sees for a given SSID for each client radio MAC address. The only time related piece of data I have is one instance where I know there were about three days between the first time I connected to a network and when it showed up in my log, but that really doesn't say a whole log.
scan_ssid
SSID scan technique; 0 (default) or 1. Technique 0 scans for the
SSID using a broadcast Probe Request frame while 1 uses a
directed Probe Request frame. Access points that cloak them-
selves by not broadcasting their SSID require technique 1, but
beware that this scheme can cause scanning to take longer to com-
plete.
So presumably a (default) broadcast Probe Request would not disclose saved network names but somehow this doesn't appear to be true? Hence my question?
This may be a bug in wpa_supplicant, I'm not sure. I looked at the code, and it seems to be trying to avoid using the SSID in a probe unless this value is set to 1, but the code is structured such that the check needs to be done in many places so one of them may have omitted it. Should be in scan.c.
What makes this particularly bad for iOS users is the fact that you cannot delete a wifi connection if you're not there. The interface just doesn't show all your previously authenticated networks.
So imagine that you travel, go to a few hotels and use their wifi networks. Once you're back home, the fact that you used these networks is still broadcast everywhere, and there is no way in the interface to turn that off.
This is especially frustrating as a transit user whose bus goes by multiple Starbucks/local cafe chains. Even at 40 km/h, that's enough time for my phone to say 'WIFI NETWORK MUST HAVE', which results in my internet suddenly not working anymore until I figure it out and turn WiFi off entirely, forget the network (if it doesn't disconnect before I can get at it), or just finish an article while it times out.
WiFi probes are indeed a huge information/privacy leak. I'm guessing a lot of this has to do with the fact that WiFi was not designed from the beginning with security in mind.
Simply using something like Kismet[0] yields a lot of information, even before any rigorous analysis is done. You'll see some probe requests with huge lists of SSIDs. Some of those SSIDs are comprised of an address (presumably a home address), others are obviously office/work SSIDs and still others are public ones. (Starbucks, etc.) From this you can infer a device's movement and thus likely a person's. This is all from a superficial analysis.
Others have done much more research into large-scale collection and analysis of WiFi probes. The information you can collect is immense. See Snoopy[1] and this research paper entitled, "Signals from the Crowd: Uncovering Social Relationships through Smartphone Probes". [2]
Some of these use a SSID-to-geolocation database to assign a physical location to specific SSIDs. WiGLE is an example.[3] Google, Apple, et al. maintain their own databases that are likely more accurate, used to provide geolocation services to mobile users.
On Android, https://play.google.com/store/apps/details?id=net.kismetwire... Kismet can help with this. I'd be very surprised if you had anything like this on iOS: the Sony app that can make my Android tablet connect to my camera instructs you to connect manually on the iPhone.
Wi-Fi Privacy Police is an Android app that solves this problem by disabling these kinds of probe requests. It's open source with extensive documentation to boot.
It blows my mind how the Wi-Fi workflow seems to be inverted in ways that are atrocious for privacy and security.
There was a devious little company called WiFast that provided WiFi hotspots to local businesses. You'd have to authenticate with e-mail or Facebook to get access. The devious part is that they could then match your device's MAC address to your identity and track you as you moved throughout any city where they had merchants in their network. They built personalized profiles by spying on exactly where you moved throughout the day. This model is a big reason Apple started randomizing disconnected MAC addresses in newer versions of iOS.
I don't understand why devices are responsible for broadcasting by default in WiFi. Naively, it seems like the default case should have base stations broadcasting their IDs, and your device should only try to connect when it recognizes one. (This also seems like it would be more efficient for battery life.)
Obviously, hidden could SSIDs pose a problem, but does anyone know why WiFi devices broadcast so much data before they've even found a base station to pair with?
I guess it could have something to do with power consumption, at least when it comes to mobile devices. I imagine just pinging your surrounding from time to time until you get a reply could be a lot more efficient than actively scanning for known devices all the time.
This might not help a lot, but at least Google does not map if your SSID is ending with "_nomap". By using this, you will at least not give away your home location. You will of course not be able to add this to every public network you're using.
The solution is to use Pry-fi: https://play.google.com/store/apps/details?id=eu.chainfire.p... . It also has a nice feature where it randomly cycles your MAC address quickly to ruin datasets of places who spy on wireless probes to track people's locations.
This will not hide or remove your full history of connections. It will change your MAC so you'll look like another person who lives at your house and works with you. But the published list of networks remains the same.
Wrong. It probes without announcing any networks, and compares the list it gets to the list you have saved. If it finds a match, it then probes specifically for that network without announcing any others it knows.
The main drawback is that it doesn't work on Windows (wpa_supplicant on Linux already does this by default); on my laptops I just remove all networks when I am finished with them - entering a 15-20 char password every couple of months isn't so bad, especially as I only really use my laptop when travelling.
If the recent research by Yves-Alexandre de Montjoye et al is anything to go by, recording and tracking 4-5 requested SSIDs per a connecting device should be enough to uniquely identify most users - even without the location library.
I've been running some custom software for sniffing probe requests from my apartment (my log shows over 30k unique devices). The most interesting one I've seen is Teslas... They'll probe for "Tesla Service", and sometimes other networks (perhaps the owner's home?) as well.
In addition to probing for Tesla wifi networks (found at service centers and showrooms), you can configure the car to use additional wifi networks, like your home and work networks. The car's always on 3G; the main purpose of wifi seems to be lowering Tesla's data bill for sending out over-the-air updates.
Actually, probing is disabled by default in wpa_supplicant. That doesn't mean all no linux systems publish the information. For example gnome doesn't expose the switch in the network configuration anywhere, which likely means the network is actually probed by default.
Since wifi security isn't going to change anytime soon, I have a solution; don't remember network connections. I already do this to avoid connecting to rogue 'linksys' ssid's, and on mobile you might save some battery by not searching for access points all the time.
> In order to connect to known networks which don’t broadcast their presence, almost all your wifi-enabled devices: laptops, tablets, phones, etc. will try to probe for networks they know about
But aren't nearly all APs configured to broadcast SSID? So why is that probing necessary in general?
Some devices still probe, even for APs that broadcast their SSID. I honestly don't know enough about it to explain why, but I know some Android phones will probe (my Note used to, my nexus 5 doesn't)
"all your devices try to broadcast your previous connections" Does all the apps on iOS and Android who ever have access to the location, can collect all these info ?
Lets say you go to starbucks and I've got my honeypot running, you will automatically connect to my laptop and I'll just spoof your probes into thinking I'm your network. While connected to my smartphone or even starbucks wifi I can see everything you do in clear text, spoof ssl, and then with driftnet see all the images you look at, and use ettercap to steal your sessions if need be.
And the best part, if I show up and starbucks is already full of people I'd like to play with, I can just deauthenticate them all for a moment, and when I turn off the kill switch they all connect to me. None the wiser.
Wifi security is a misnomer.
Here is an example I made in 2008.
https://www.youtube.com/watch?v=Wx5vGfxBanI