[HN Gopher] Bad times in corporate wireless networks
___________________________________________________________________
Bad times in corporate wireless networks
Author : todsacerdoti
Score : 46 points
Date : 2020-05-02 20:29 UTC (2 hours ago)
(HTM) web link (rachelbythebay.com)
(TXT) w3m dump (rachelbythebay.com)
| booleandilemma wrote:
| The finance company I worked for simply didn't use wifi at all.
| Everything was done over ethernet.
| nerdbaggy wrote:
| This is even easier, broadcast these SSIDs and you will be amazed
| how many devices auto connect.
|
| - attwifi
|
| - Google Starbucks
|
| - xfinitywifi
|
| - hhonors
|
| The list goes on and on. Depending on what AP you are using you
| can easily do 16+ SSIDs
| [deleted]
| WrtCdEvrydy wrote:
| Broadcast, sslstrip (probably not valid) or provide a self-
| signed certificate and just log the traffic?
|
| I was pissed when my Android phone connected to the McDonald's
| wifi without me telling it to do it.
| kyuudou wrote:
| HP Officejet $(<array of existing officejet model #s)
|
| naughty!
| clairity wrote:
| yes, at least turn off "auto-join" for popular APs like that if
| you don't want to delete them from your network list.
|
| the main advantage of saving a network is not to retype the
| (should-be-)hard-to-remember password, but the popular ones are
| usually open, in which case that advantage goes away. but when
| you've curated the order of the list just so, you may not want
| to delete them outright, but rather turn off auto-join.
| EdJiang wrote:
| This threat vector is interesting, but is it really a huge deal?
| I don't think many company devices restrict the networks you can
| connect to (certainly not ones you bring on Caltrain) so why even
| target a corporate pre-shared-key network and instead host
| xfinitywifi or another popular public SSID?
| db48x wrote:
| Because the people working for the target of your attack might
| never connect to an xfinity wifi network, but they are pretty
| likely to connect to the wifi at their office.
| jsjohnst wrote:
| Exactly, this would likely work fairly well for a targeted
| attack. Yes, shared Wi-Fi names _might_ work for some
| employees, but using the employee's work's Wi-Fi SSID /psk is
| virtually guaranteed to work (if they use WPA PSK anyway).
| martin8412 wrote:
| Any modern enterprise WiFi setup will support containing rogue
| APs. So this vector won't work if configured correctly.
| jsjohnst wrote:
| > Any modern enterprise WiFi setup will support containing
| rogue APs. So this vector won't work if configured correctly
|
| You misunderstood the issue. Modern enterprise wifi won't
| detect a "rouge AP" that's setup near a worker's home (or
| coffee shop), only ones in radio range of the corporate APs.
| joahua wrote:
| Not quite on the enterprise wifi side, but I have been
| pleasantly surprised that iOS has alerted me when I connect
| to a wifi network with the same name, at a new location. So
| endpoints can play a part in this.
|
| I'm not sure if there is some kind of MDM policy that would
| restrict locations that are valid for wifi use, but expect it
| is coming soon.
| godzillabrennus wrote:
| Corporate WiFi networks are capable of Creating multiple SSID's
| tied to different VLAN's. Creating a VLAN with client isolation
| while using WPA2 personal should be trivial.
|
| Giving that network a VLAN to exist on with just an internet
| gateway should be trivial.
|
| Coupling the VLAN with client isolation should be adequate for
| most companies.
|
| Any reasonably administered corporate network should be able to
| then provide company issued devices with more reasonable
| security.
|
| Posture assessment and other aspects of network management are
| important for compliance.
|
| None of that should scare anyone. You can still stream music in
| the bathroom while offering more security for corporate devices.
| rocqua wrote:
| Is that going to prevent phones and laptops in random places
| from automatically connecting to a spoofed network?
|
| To my knowledge, it will not. So you'd need that SSID and VLAN
| to be something like a guest wifi. Preferably with a key that
| rotates often enough that people will not try and remember the
| network.
|
| Cause otherwise, it just became a whole lot easier to get a
| layer 1 MitM on anyone who has that network on auto connect.
| mrkramer wrote:
| Interesting way of cloning networks but still MAC addresses would
| differ. Original network has a MAC address of a router and clone
| network has a different MAC address of an access point.
| jsjohnst wrote:
| > but still MAC addresses would differ
|
| You mean BSSID. It looks like a MAC address and in some cases
| it actually is one, but it's not required to be. Each AP
| broadcasting for a given network will have a different one and
| I'm not aware of client side native behavior to alert or
| enforce a whitelisted set. Even if there was, you could easily
| spoof the BSSID too, just would need to war drive to get it.
| mrkramer wrote:
| I just mentioned basic security check but I don't know
| anything about corporate networks or how to manage them. One
| thing I know is that Microsoft has robust network directory
| service called Active Directory which "authenticates and
| authorizes all users and computers in a Windows domain type
| network--assigning and enforcing security policies for all
| computers and installing or updating software." So for
| example you could register all corporate access points to a
| Windows domain and no way you get connected to a wrong access
| point.
| [deleted]
| Thorrez wrote:
| Ah yes, the evil twin attack.
|
| https://en.wikipedia.org/wiki/Evil_twin_(wireless_networks)
| chris_wot wrote:
| I am genuinely curious: what is the best resource for
| understanding wifi and wifi security in depth?
| redprince wrote:
| Unfortunately the proposed solution WPA Enterprise has its own
| set of pitfalls. Unless one opts for EAP-TLS, which is quite
| secure, some fun can be had with certain other EAP methods if
| implemented insecurely. It is especially inadvisable to use AD
| credentials and skip certificate validation or make it optional.
| For further research:
| https://github.com/opensecurityresearch/hostapd-wpe
| jpablo wrote:
| Wait you already have the wpa preshared key? Why would you go the
| trouble of creating a clone network when you can already join the
| actual network and arpspoof at will?
| redprince wrote:
| * It may have client isolation enabled though that thwarts
| certain critical use cases like having those private, wifi
| enabled boom boxes on the corporate WLAN...
|
| * The goal stated in the article is to lure clients onto a
| rogue AP far away from the office anyway.
| ChuckMcM wrote:
| One might choose to do this because the admins thought they
| were "smart" and said, "Oh, I know, we will only allow 'known'
| MAC addresses to connect to the network! That will fix it."
|
| And it does, kinda. Except it doesn't stop you from capturing
| clients on your "fake" network, and the goal isn't necessarily
| to be on the "real" network, the goal might be to just man-in-
| the-middle a juicy site or two, with is on the big Internet
| (say, the company's bank)
|
| Capture the controller's login into the bank and win "free
| money"
| jpablo wrote:
| Mac address restriction provide zero access control. It's
| trivial to sniff and spoof them.
| ChuckMcM wrote:
| Not disagreeing with you here, I am wondering however if
| you have ever surveyed or even had casual conversation with
| people who self identify as "an IT person at company <X>."
|
| In my discussions with such people[1], I have found that a
| preponderance of them believe that a MAC address filter is
| a strong protection against unauthorized equipment on their
| wireless network.
|
| [1] I have had many occasions in my career where I have
| hired people in the IT/Ops role and during the interview
| process I have often probed their understanding of the
| plumbing of IT beyond the parameters necessary to enter on
| a screen in order to get something "up." My admittedly non-
| scientific sampling suggests that "knowing the plumbing" is
| not a valued skill for many of these people.
| jedberg wrote:
| It's a way to capture them away from the office.
| jpablo wrote:
| So the attack is:
|
| 1. Have access to their computer to retrieve the wpa key. 2.
| Create a clone of the wifi network, spoof a bunch of sites
| and hope to catch one that doesn't use http.
|
| Why can't I replace step 2 with: Install a root kit since I
| already have access to their machine.
| jedberg wrote:
| No, it's "have access to any of their co-worker's
| computers". Or be a former coworker who still has the
| access key. Or even be a current coworker.
| jpablo wrote:
| Seems a bit complicated:
|
| 1. Find some one to steal a key from but which I don't
| care about. 2. Locate a third person that I want to
| target and move close to them in non office hours. 3.
| Create a clone of their wifi and try to spoof some
| website. Hopefully I can be close enough to their device
| that it would join my clone instead of their other
| preferred networks.
|
| At step 2 seems like a better idea to move close to the
| office and start probing around?
| jedberg wrote:
| To get that close to the office would be very obvious.
| You'd have to loiter all day or set up a remote host with
| some power.
|
| To get near a target in the wild isn't that hard,
| especially if you know where they like to go on a regular
| basis.
|
| It's lot easier than a lot of other methods, especially
| for a high level target like a C-level exec who might
| have access to bank accounts with millions of dollars and
| like to work at a local coffee shop on weekends.
| ChuckMcM wrote:
| You don't have to spoof sites. If you capture the client
| they will invariably use DHCP to get an address and you can
| pass along that you are the web proxy for HTTP/HTTPS.
| Voila, all your bases are belong to us, right?
| jedberg wrote:
| This is a good way to target individuals too. If know someone
| uses wireguard and has it set to automatically connect except
| when on their home wifi, you can pretend to be their home wifi to
| lure them into a false sense of security.
|
| I would contend that this is a problem with wireguard. It
| shouldn't be trusting the name of the wifi network.
___________________________________________________________________
(page generated 2020-05-02 23:00 UTC)