Hacker News new | ask | show | jobs
by woodruffw 904 days ago
This is adjacent to the classic free WiFi hack on airplanes, which is to boot another client off of their DHCP lease by spoofing their MAC.

It’s unfortunate that, below HTTPS and a light smattering of WiFi encryption, there’s essentially no authenticity controls on LAN management protocols.

2 comments

I work on SPR, http://github.com/spr-networks/super, we make it easy to use distinct WiFi 3/ WPA2 passwords to authenticate devices on the network for policy based access
>we make it easy to use distinct WiFi 3/ WPA2 passwords

If only we could get the industry to move to this model, we could dramatically reduce the amount of congestion due to APs broadcasting multiple SSIDs.

Great project, a lot of APs themselves support VLAN segregation using RADIUS, has SPR ever considered the scenario where it might be ideal if it were just the router and it controls APs (and even switches) that way?
SPR supports receiving VLAN tagged packets over a wired LAN interface today.

Soon we are planning to support an OpenWRT package that will allow people to link up into SPR from lots of APs, provided the AP card supports AP/VLAN mode which is critical for the segmentation.

We have no plan to work more closely with managing RADIUS right now, enterprise wifi authentication is difficult to deploy securely without client-side certificates for authentication. So that makes it less appealing due to our goal of supporting any kind of wifi capable device.

Lastly, SPR does have an upsell feature where we support leaf node APs running SPR that have backhaul into a primary instance.

Yeah I already do some combination of MPSK and MAC-based Security on Aruba AP-555 and AP-655 at home with a couple hundred IOT devices, OPNsense and FreeRADIUS. I segment by (vendor, device model) instead of /30 per individual device but that’s more setup convenience than anything (it’d be possible to uniquely dot1q every device, too).

I think SPR looks neat, it’s a more well-packaged version of essentially what I already do (albeit in a kludgey way), hence the curiosity about ambition.

Client isolation at the access point level does this.
Yes, this is part of the story of how SPR achieves this.

So the hostapd configuration for SPR has the following components: - ap_isolate=1 - per_sta_vif=1 - unique passphrases for devices - firewall rules

ap_isolate stops the AP from doing L2 forwarding between clients using the pairwise keys. the per_sta_vif=1 will also ensure that each client has a unique GTK so they can't use group key encryption to communicate without the AP.

Next, unique passphrases are used. Without this, it's possible for a malicious device to decrypt WPA2 traffic passively or spin up a Rogue AP to capture traffic from peers.

And lastly -- firewall rules with default deny connect devices by policy.

That ap_isolate alone is not enough is kind of interesting, as it's possible to instead push packets to the router that will then forward to the client destination. Most off the shelf routers have forwarding on without a default deny policy, enabling this. The subtlety here is the attacker uses the router as the L2 destination instead of the other wireless client. At the very least attackers can send UDP packets to bypass the intended isolation. This bypass is especially powerful when changing mediums between Wireless and Wired as the Wired victim receiving packets will be responding back to the router, and on many consumer routers a full TCP connection will be possible then.

Does this usefully support multiple APs with the same ESSID?
Yes, although it is part of our upsell and not in the core FOSS project. We need to update our documentation to be more clear as we have been getting this question more often.
I poked around the site, and it was entirely unclear to me that one could buy this feature or how it works.

Can it make it painless to manage multiple APs and to get fast roaming, etc working? UniFi pulls this off nicely — there’s nothing particularly fancy under the hood AFAICT, but it all just works. A more intelligent solution where clients got assigned to appropriate VLANs would IMO be extra nice.

(The enterprise vendors seem to have decent ACL and maybe even anti-spoofing measures for their wired networks, and they have some security features for wireless, but I haven’t seen anyone with a nice solution that makes wired and wireless security cooperate. I haven’t looked that hard.)

Every time I have to interact with a "captive portal", I'm annoyed at the hack implemented through DNS hijacking, rather than implementing and extending 802.1X and/or another layer-2 authentication scheme. The idea seems to have been tossed aside entirely. Instead, every device has to have a web browser. There's not even a way to do surrogate registration for devices that don't have browsers, with Apple TV and Nintendo Switch at launch (added later) being prime examples. IoT and headless gear is also a pain. On trips, I end up bringing my own travel router and using my laptop to auth it by proxy, but it's another thing to remember to bring.
I have a work laptop (government) that hates captive portals. It has a security system that won't let it connect using the local DNS. So it doesn't get captured. Those of us with such laptops all have tricks for getting to a hotel's wifi login page using IP addresses. But we have to do it fast, before the security software fully wakes up and blocks the hack.

We used to just login on our phones, then tether the work laptop to the phone over USB. The security people caught up to that a couple years ago and disabled USB tethering. So now I alter my laptop's MAC to be the same as that from the work laptop. That tricks about 90% of hotel wifi into allowing the work laptop to connect without need of a splash page. But for the other 10%...

(Not a joke, I do this) I sometimes login to the hotel wifi on my personal phone, tether that phone to my personal laptop, then setup that laptop as a router. The work computer can then connect to the wifi from the personal laptop, which tethers into the phone, which is on the hotel wifi. All of this just avoid another ridiculous wifi login page.

Why not just get a travel router and be done with all the “hacks”. They are so small these days they take up very little space. With mine I get connected to hotel WiFi then all my family devices just connect to it, just like they are at home. I even tunnel all hectic traffic back home though a Tailscale exit node.
> I have a work laptop (government) that hates captive portals. It has a security system that won't let it connect using the local DNS.

Does the OS not pay attention to DHCP option 114:

    This document describes a DHCP option (and a Router Advertisement
    (RA) extension) to inform clients that they are behind some sort of
    captive-portal device and that they will need to authenticate to get
    Internet access.  It is not a full solution to address all of the
    issues that clients may have with captive portals; it is designed to
    be used in larger solutions.  The method of authenticating to and
    interacting with the captive portal is out of scope for this
    document.

* https://datatracker.ietf.org/doc/html/rfc8910

* https://developer.apple.com/news/?id=q78sq5rv

It is more layered than that. The work machine initiates a VPN automatically at login. Once that VPN is up, all traffic goes through the VPN, including DNS. It will actively ignore/block anything that isn't coming from the VPN. So we do tricks to get to the hotel splash page before the VPN software wakes up. These are corporately-managed windows machines. The boot/login process isn't exactly quick.
Why do you try to solve the problem at all? Wouldn't it be better to say "sorry I can't do any work from this location because of our IT policy" and let your organisation sort it out if they need you to work from a hotel?
> I sometimes login to the hotel wifi on my personal phone, tether that phone to my personal laptop, then setup that laptop as a router. The work computer can then connect to the wifi from the personal laptop

Why go through a laptop? Isn't this exactly what generating a hotspot from the phone does?

This was the reason why I bought a travel router/wifi repeater. You connect your corp laptop to the travel router then use your phone to log into the hotspot. Hotels are now using Meraki Air Marshal to block them on 2.4Ghz networks though
I wasn't familiar with Air Marshall. I understand it complicates your work-around, but I'd probably pay extra to stay in a hotel that cared enough about security to deploy it
No, i think it's a great feature. Definitely increases security. I don't believe it works on 5GHz networks though.
I've been reading up on it. Seems like it sends spoofed de-Auth packets to AP's it deems "rogue". That sounds highly illegal.
Does the laptop also prevent wireless tethering to your phone? Turning your phone into a hotspot is pretty trivial, at least on iOS. I often have to do it due to similarly arcane security configuration settings on my work laptop.
Yes, but unless you have a phone with two wifi connections then you will have to use your cellphone's data plan rather than the hotel wifi. When traveling, doing a teleconference or having your work laptop perform a windows update over your cellphone data connection isn't cheap. We used to just tether to our work phones, but they locked that down after seeing the international roaming bills.
Connecting to wifi and enableing the hotspot at the same time works on my phone (pixel 5), it probably just uses different bands. It's pretty useful to avoid typing passwords twice.
Android on certain phones can hotspot a WiFi connection both over wireless and USB.
I don't know if it's more or less ridiculous, but I bring a small travel router running OpenWrt to do said bridging so I don't need to have my laptop running so I can use my Chromecast on the hotel TV.
> Nintendo Switch at launch (added later)

The Nintendo Switch actually had a browser either at launch or close to it, then removed it in an update, and didn't add it back until about 3 years later.

It's really hilarious that a device that touted its portability from the beginning was literally incompatible with most public Wi-Fi for years.

> Every time I have to interact with a "captive portal", I'm annoyed at the hack implemented through DNS hijacking, rather than implementing and extending 802.1X and/or another layer-2 authentication scheme. The idea seems to have been tossed aside entirely.

It has not: it's simply easier (less infrastructure) to not implement 802.1X.

Basically every corporate / enterprise-y password where you use your AD/LDAP credentials to log into Wifi has gone through the effort. Not everyone wants (or needs) to do that. (Source: recently implement 802.1X as IT when we moved to a new work office.)

neverssl.com