
Bad times in corporate wireless networks - todsacerdoti
https://rachelbythebay.com/w/2020/05/01/owned/
======
amaccuish
FreeRADIUS is great, and I wouldn't use anything else.

But to increase the adoption of EAP, what would be better is a super simple
daemon, you point it at LDAP or a file, and it sets itself up for PEAP or EAP-
TTLS and you just have to point your APs at it. FreeRADIUS is far to complex
for most use cases.

I note that many APs now come with nice web interfaces and can integrate with
LDAP and Active Directory directly, which is a great step forward.

Ideally AD would support something like SRP directly so you wouldn't even need
server certificates.

~~~
Chris2048
I want simple, non-enterprise wifi, but I want the "enterprise" feature of
per-user credentials.

Sadly, setting up a RADIUS server is the only way I can see this is possible..
way to complicated, I'd sooner just put a static file on the router, but I'm
not sure if this is possible.

~~~
rootusrootus
Some of the small business gear has this feature. I use Ubiquiti access
points, and through the Unifi interface I enabled the built-in RADIUS server
and added some users to it. Now I have enterprise-style WiFi authentication.

------
nerdbaggy
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

~~~
WrtCdEvrydy
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.

~~~
efreak
My phone used to do that. Now I have to force it to connect manually whenever
I need it, because it doesn't recognize the captive portal, and it only
recognizes it as a network that doesn't have internet access.

------
tialaramex
Edited to prefix:

Actually, on second thought, this doesn't really help Rachel's scenario. If
the imposter knows our PSK then WPA3 does not defeat that. Huh.

[Also there ought to be a way to zap that +Karma on a comment that I now
realise isn't helpful ]

Original post follows:

Note that WPA3 is intended to fix this, _but_...

* Your corp network probably doesn't talk WPA3 yet

* Even if it does it probably also allows WPA2 back compatibility for older devices

* Lots of devices can be fooled into accepting that just because the 'foocorp' AP it usually talks to is WPA3 maybe this 'foocorp' AP is WPA2-only and that's fine

* Cheap devices (maybe not your laptop or iPhone, but perhaps a cheaper phone and definitely other devices) are too constrained to safely run the secure algorithm.

WPA3 uses a PAKE here (it calls this "Simultaneous Authentication of Equals
but it's just the Dragonfly PAKE) so the advantage is that devices don't tell
anybody what the PSK is. But we're probably a decade from being able to tell
people (especially conservative corp sites) to turn off WPA2 altogether.

If you already use a sane 802.1x setup instead of a PSK WPA3 doesn't
meaningfully improve anything and you needn't rush to update, but of course
random cheap consumer WiFi gizmos that expect a PSK won't work.

~~~
stefan_
You might be thinking of Wi-Fi Easy-Connect or DPP where devices enrolled
through it no longer learn the PSK:

[http://w1.fi/cgit/hostap/plain/wpa_supplicant/README-
DPP](http://w1.fi/cgit/hostap/plain/wpa_supplicant/README-DPP)

------
rcarmo
This is why 802.1x and RADIUS are key. I used to maintain the RADIUS servers
at an ISP and dealt with the craziness that were the initial implementations
of 802.1x, and to this day I keep finding corporate networks that do crazy
things like rotating standard WPA Wi-Fi passwords via policies instead of just
setting up 802.1x properly.

Of course, vendors don’t help here. Spending six digits on Cisco gear to get
“out-of-the-box” end-to-end authentication (that then is weirdly inflexible in
hooking up to your corporate AD) is certainly not on most small companies’
radar, especially when they get cheap APs that “work”.

For home use, I’ve bee looking for decent APs (_not_ proprietary fancy mesh
setups) that support 802.1x and don’t cost an arm and a leg, and I’ve been
seriously considering ripping out my Airports (which are amazing Wi-Fi gear,
and sadly discontinued) and going with a combination of OpenWRT gear and an
embedded RADIUS server.

But I’ve been wondering if there are decent SOHO solutions out there for 6-12
APs and up to 50 users — it would be great for small companies/startups.

~~~
ComodoHacker
Look at MikroTik. 802.1x is supported in all products including SOHO ones.
Also their wireless management solution (CAPsMAN) is decent.

~~~
DyslexicAtheist
about MikroTik I'd be extremely worried about security - not exactly a good
track record:

 _MITRE /CVE's_: [https://cve.mitre.org/cgi-
bin/cvekey.cgi?keyword=Mikrotik](https://cve.mitre.org/cgi-
bin/cvekey.cgi?keyword=Mikrotik)

 _" Most MikroTik routers fail to get patched a month after severe security
issues disclosed"_ [https://portswigger.net/daily-swig/most-mikrotik-routers-
fai...](https://portswigger.net/daily-swig/most-mikrotik-routers-fail-to-get-
patched-a-month-after-severe-security-issues-disclosed)

 _" Finding and exploiting CVE-2018–7445 (unauthenticated RCE in MikroTik’s
RouterOS SMB)"_ [https://movaxbx.ru/2020/01/29/finding-and-exploiting-
cve-201...](https://movaxbx.ru/2020/01/29/finding-and-exploiting-
cve-2018-7445-unauthenticated-rce-in-mikrotiks-routeros-smb/)

 _" Coinhive malware infects tens of thousands of MikroTik routers"_
[https://searchsecurity.techtarget.com/news/252446369/Coinhiv...](https://searchsecurity.techtarget.com/news/252446369/Coinhive-
malware-infects-tens-of-thousands-of-MikroTik-routers)

~~~
iso1210
> "Coinhive malware infects tens of thousands of MikroTik routers"
> [https://searchsecurity.techtarget.com/news/252446369/Coinhiv...](https://searchsecurity.techtarget.com/news/252446369/Coinhiv..).

"Kenin said malicious actors were exploiting a vulnerability in the routers
that MikroTik had patched in April -- just one day after the flaw was first
discovered."

So an exploit was found (it happens) and patched within 24 hours.

From memory this was only vulnerable if you didn't block incoming winbox
traffic on your wan port (which is of course good practice, and I believe the
default configuration).

Upgrading a mikrotik router is a matter of running "system package update
install". You could stick that in a scheduled script if you wanted.

Upgrading a cisco or juniper router requires things like support contracts,
tac accounts, and other nonsense, then in many cases doing things like using
tftp (!!) to copy a binary to the router, then ensuring you have a serial
connection (!!) to the switch for when it breaks.

~~~
icedchai
Upgrades on Mikrotiks are so simple. I used them for over 10 years and never
once had a problem.

In my previous experience both from my ISP days and some time in a corporate
IT "networks" department, almost nobody upgrades their "enterprise" (Cisco)
routers or switches. It's too risky.

------
thelittleone
Corporate WiFi networks should be untrusted. Once a device is connected to the
WiFi users should then be required to connect via VPN before internal network
access is granted.

~~~
greglindahl
That sounds like a usability problem.

~~~
daviddoran
We use the described setup at our company and the VPN software (Viscosity)
auto connects so seamlessly that you never really need to do anything
manually. Works really well.

~~~
dtrailin
Basically every big corp uses always on VPNs and it works fine. You can even
do stuff over group policy on Windows to get the VPN configured and auto join
enabled.

~~~
hnaccy
Really? I've worked at a couple large bay area companies this wasn't true.

------
redprince
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](https://github.com/opensecurityresearch/hostapd-wpe)

~~~
stefan_
This comment is not nearly as dramatic as the situation is in practice. Here
is how to connect to Cornell WiFi as a student:

[https://it.cornell.edu/wifi/connect-eduroam-
android](https://it.cornell.edu/wifi/connect-eduroam-android)

Notice this does not setup certificate validation (and therefore does not
authenticate the AP is actually from Cornell). It also tells you to use the
completely broken MSCHAPV2 and login with credentials that allow access to a
number of other university services. So in this setup, not only can you still
trivially impersonate a Cornell AP, all clients also give you their specific
login credentials in a way that allows you to recover their passphrase.

~~~
tialaramex
It's true that it doesn't (and can't) authenticate that the AP is "actually
from Cornell" and indeed that's the point of EduROAM.

But it _will_ be talking to Cornell to authenticate you and so no you can't
"recover their passphrase".

EduROAM is a global federation. So what's happening goes like this:

Let's say I'm a Cornell student

1\. I follow these instructions, probably while on campus to make my, let's
say, iPhone work with WiFi. My "NetID" is tialaramex for this example.

2a. Probably my phone automatically concludes that network-
access.it.cornell.edu is really network-access.it.cornell.edu because it has a
Web PKI cert that says so, just like on an HTTPS website.

2b. But if not I have a step where I tell the phone this certificate looks OK.
This is effectively TOFU (Trust On First Use) because I'm a naive user which
isn't great but it'll protect against many attacks later.

3\. I go to the University of Sydney, in Australia, as an example.

4\. My device sees an AP named "eduroam" because I'm at a university in a
developed country and the Network Effect means it makes sense for all
universities to join eduroam.

5\. My device says "Hi I'm tialaramex@cornell.edu † let me in"

6\. Sydney's AP talks to an Australian server which talks to Cornell, which
agrees to talk to my device about this, over TLS

7\. My device confirms that this TLS connection matches the certificate we saw
earlier, or has a trusted certificate for network-access.it.cornell.edu

8\. Using the risible MSCHAPv2 protocol (but happily inside TLS) my device
proves I am really tialaramex@cornell.edu

9\. Cornell tells Sydney that yup, I am an authorised Cornell network user,
let me in.

10\. I get the same privileges as a local Sydney student/ professor in terms
of network access. If there's any problem (maybe I use 40GB in one day from
PornHub) Sydney know which Cornell user I am and they can take it up with
Cornell. In extremis they can "blacklist" me.

† It is possible to arrange that the local institution does not find out your
"real" username at your home institution, since they don't need to know that
in order to connect to the right authentication service. But mostly nobody
cares.

------
Thorrez
Ah yes, the evil twin attack.

[https://en.wikipedia.org/wiki/Evil_twin_(wireless_networks)](https://en.wikipedia.org/wiki/Evil_twin_\(wireless_networks\))

------
kragen
You could imagine a system where you configure your laptop with a public-key
hash of the wireless network, maybe using ssh-style TOFU (trust on first use),
to defeat this kind of attack. You could even use the OPIE or BIP39 or
bubblebabble wordlists, or randomart images, to confirm that first use.
There's really no reason the Wi-Fi standards, developed decades after ssh was,
need to be less secure.

------
booleandilemma
The finance company I worked for simply didn't use wifi at all. Everything was
done over ethernet.

------
some1else
Once I had to reconfigure some Airtame devices out in the field. They couldn't
connect to the cloud, but I made a hotspot with the same SSID and credential
settings as one of our guest networks at work. The devices were able to
connect to it, and I successfully reconfigured them. Some time later at work
my phone was feeling warm. I was surprized to see I was subsidizing random
office internet traffic with my cellular data plan.

Access protection is usually done more diligently for important networks, but
the simplicity of a MITM attack makes it apparent that all corporate networks
need RADIUS or similar protection.

------
mbn12
It's interesting to see a website that just copy and paste content from other
sources without any sort of credit or referencing having this attraction
(usually in the HN top ranks).

In fact the way it's presented it even seems that was 'authored by rachel, the
anonymous valley dev'.

Harmless attitude when it's just someone trying to land a hotsite and earn
some extra bucks/attention. But later don't complain when the same attitude is
in place by big companies/VCs draining your career.

Tech scene really reached a new low these days: "put the minimum effort; try
to extract and profit the most" \-- while trying to be 'smart/efficient'
people lost the self perception of predatory behavior.

Maybe could be renamed to Grasshopper By the Bay. :P

------
EdJiang
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
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
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).

------
bathtub365
Some great stuff happened when I was moonlighting as IT at a company. One time
someone randomly plugged in a cat5 cable and created a loop in the network,
causing an ARP packet storm.

The company also had 2 different networks, one for data and one for VOIP. They
had wall plates in the conference rooms that had a data RJ45 and a VOIP RJ45.
Someone decided to plug a cable from the VOIP port into the conference phone
(which had a pass through), and plug a cable from the pass through on the
phone into the data port, causing all kinds of weird chaos. That was a fun one
to track down.

~~~
lathiat
Spanning Tree is under-rated :) Although I read a twitter thread earlier where
someone did this and they had spanning tree which in theory prevents this but
the switch had some kind of bug causing it to crash and reboot right after
disabling the port with spanning tree.

~~~
bathtub365
It was a long time ago and most of the equipment was either hubs or dumb
switches with no budget to overhaul. That’s a really great bug to have in your
equipment out in the wild

------
jpablo
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?

~~~
ChuckMcM
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
Mac address restriction provide zero access control. It's trivial to sniff and
spoof them.

~~~
ChuckMcM
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.

------
red_admiral
I still don't get who Rachel means with the "beekeepers" analogy linked to in
the post. Can someone enlighten me?

~~~
KarlKemp
Uber and Lift?

------
bawolff
Interesting idea, but im pretty unconvinced its a threat in practise. People
will connect to any free wifi they can find, you don't need to trick them into
it. Use HSTS if you need security. (The author of course says its easy to
forget on some obscure part...well yes. Security is hard for a reason)

~~~
orev
You are thinking about a coffee shop scenario, when the article is about an
office environment. They are talking about spoofing the office SSID that
devices already connect to automatically, not people manually connecting to
open networks.

~~~
bawolff
They were talking about people autoconnecting to an office ssid on the bus. If
you use your office phone on the bus, you probably use it at the coffee shop
too.

------
Avamander
Is it possible to use Web PKI to prove that an AP is under the control of a
domain? Basically protect against evil twin APs without deploying certs.

~~~
tialaramex
It _would_ have been trivially possible to use the Web PKI here if APs
advertised an FQDN instead of a short text string as their visible name.

If you were signing into "Starbucks.com" then logically we can arrange that
the AP needs to prove it has a certificate for starbucks.com or some-wifi-
made-up-prefix.starbucks.com or something and it could use the Web PKI to make
that work safely for everybody.

But APs do not have FQDNs. The WiFi industry has talked about trying to get to
roughly the same place by a circuitous route, but the problem they run into
is: Who is allowed to call their AP "Starbucks" and why? If you decide it's
fine we'll hide a signifier elsewhere, then the user doesn't know why _this_
Starbucks and _that_ Starbucks don't interoperate. Their experience is
disappointing and even if you claim it's for security reasons they're left
puzzled.

However, there is no need to involve "deploying certs" anyway.

You can use your existing (very likely) Active Directory or similar and
single-sign-on infrastructure to allow employees WiFi devices to prove who
they are to the WiFi AP, without giving away any secrets. There are an
impressively confusing array of different ways to do this, but the good news
is that even the really terrible ones are safer than a PSK.

You can even federate this system, a good proportion of all degree institution
students and staff in the industrialised world have EduROAM, their laptops
(iPhones, whatever) connect to any AP that claims it is EduROAM (maybe in
Venice, or New York, or Sydney) and they tell it their email address with
their home institution (e.g. where they're employed or registered to take
classes) and then they give _that_ institution credentials to connect. The
local institution can see that e.g. OK this NYU student is on our network, and
if there's a problem (looking at PornHub in class? Not here) they can tell NYU
about it and if necessary blacklist a problem user. But they don't get
credentials for the user, and the user doesn't get local credentials. No more
need for toxic "guest" networks for visitors.

~~~
Avamander
> If you were signing into "Starbucks.com" then logically we can arrange that
> the AP needs to prove it has a certificate for starbucks.com or some-wifi-
> made-up-prefix.starbucks.com or something and it could use the Web PKI to
> make that work safely for everybody.

So there's really no way to do so currently, correct?

> There are an impressively confusing array of different ways to do this, but
> the good news is that even the really terrible ones are safer than a PSK.

Which would be actually the safest one that would primarily avoid evil twin
attacks?

> But they don't get credentials for the user

Assuming there's no easy misconfigurations made by the user? E.g. they can't
click "accept this invalid cert" somewhere?

~~~
tialaramex
> So there's really no way to do so currently, correct?

AFAIK Nobody does this today. It would be difficult to retrofit.

> Which would be actually the safest one that would primarily avoid evil twin
> attacks?

Ah. Unfortunately this "evil twin" impersonates an AP and 802.1x does not end
up giving us confidence in the identity of the AP per se.

For example say you're using PEAP-EAP-MSCHAPv2 (a common way to set things up
with an Active Directory service authenticating your users) - if the bad guys
can connect to the server you're doing PEAP-EAP-MSCHAPv2 on from their "evil"
AP then your users will consider everything looks fine. The bad guys can't
directly learn their credentials in the process because there's a TLS layer,
but your users end up connected to their "evil" AP.

Even with certificates (say EAP-TLS) this is no different, if the bad guys are
able to talk to your legitimate service they can have your users authenticate
with your legitimate service on their AP.

So the main thrust ends up being: Do not trust the network. Use TLS and other
technologies to secure your traffic so that you don't care who is providing
the network, whether it is who you expected or somebody else.

Sorry.

> Assuming there's no easy misconfigurations made by the user? E.g. they can't
> click "accept this invalid cert" somewhere?

Good point. That would definitely vary by client device. There's no good
reason why a device should let you do that, but I wouldn't be surprised if
lots of them do.

------
kristianc
This is worrying - not least because every WeWork in the world has the same
WiFi password.

------
chris_wot
I am genuinely curious: what is the best resource for understanding wifi and
wifi security in depth?

~~~
WilliamEdward
Seconding this. I personally do not understand any of the jargon used here at
all, let alone what the implications of it is.

~~~
lennartkoopmann
I wrote a blog post a while ago: [https://www.wtf.horse/2017/09/19/common-
wifi-attacks-explain...](https://www.wtf.horse/2017/09/19/common-wifi-attacks-
explained/)

~~~
WilliamEdward
nice thanks

------
novok
This is why you treat the office wifi connection as any other connection,
don't create a 'turtle shell' (hard outside, soft inside) infra and control
the DNS configuration of your employee's laptops.

------
mrkramer
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
> 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
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.

~~~
close04
The article does make the same point. Basically companies _could_ configure
their WiFi in a more secure fashion but many won't. I'm certain many small
companies use very basic setups similar to a home WiFi and at best will just
change the WiFi password periodically.

This is why major OS providers are taking it on themselves to tackle some of
these issues independently of the WiFi setup - like taking the location in
consideration and warning you if you connect to the same network in a
different location.

------
jedberg
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.

~~~
PureParadigm
I just keep Wireguard on even when on my home network. With NAT Loopback on
the router this works fine. Is there a reason to have it off?

~~~
jedberg
Wireguard kills the battery on my phone so I like it off when I’m home.

Also my wireguard box isn’t fast enough to handle gigabit speeds so on my home
network it slows things down too much.

------
martin8412
Any modern enterprise WiFi setup will support containing rogue APs. So this
vector won't work if configured correctly.

~~~
jsjohnst
> 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
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.

~~~
jsjohnst
> 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

Actually, that’s the exact opposite of what I was quoting. That’s client side
detection, not “rogue ap containment” which is an entirely different thing.
Rogue AP containment is where a Wi-Fi controller detects unauthorized APs
within its AP’s radio range and sends client disconnects to the devices
connected to it, effectively isolating (“containing”) users from it.

------
godzillabrennus
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
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.

