Just curious if the Alta Labs team had any comment to make on the AirSnitch attack paper that was being reported on yesterday. I understand if there’s not much to say at the moment since I believe the paper was just published and reported on 
Context for anyone who didn’t catch it:
First off, I want to say that we as Alta Labs love Mathy and his teams’ work, and appreciate the efforts he puts into improving Wireless security for everyone. We also want to emphasize the importance of using hybrid Wireless security combined with industry-standard TLS 1.2/1.3 protocols, as most browsers and applications already do today, especially for anything that is mission critical.
Much of this work hinges on an attacker knowing an easy-to-guess or publicly available guest password. It also assumes that critical and non-critical traffic is potentially handled on the same VLAN.
Now, I’ll dig in to specific parts of the paper:
GTK abuse:
This gets to the heart of a core concept of Wi-Fi security, the Group Temporal Key. Since this key is shared and known by all authenticated clients, it is easy for an attacker to spoof broadcast traffic, and in most cases today, even unicast traffic.
Based on the popularity of this paper, it’s very possible that we will soon see client vendors deny L2 unicast frames that were accepted via GTK frame decryption. Since these frames are sent without AP’s knowledge, there isn’t much AP vendors can do, other than work with standards bodies to improve WiFi encryption in general. For Alta Labs’ part, we will be looking into enforcing GTK rekeying more aggressively.
When using separate VLANs for security, Alta Labs APs do mitigate much of this GTK abuse risk by ensuring a separate GTK per VLAN. Based on the conclusions of this paper, and honestly coming from common sense, critical unencrypted traffic absolutely should not be allowed on VLANs that have easy public access, regardless of AP vendor.
Gateway bouncing: We are looking into improving Route10’s handling of forwarding Layer-3 frames unnecessarily, making gateway bouncing possible. As stated in the paper, nearly all other router manufacturer’s are in the same boat here, but we will make efforts to improve forwarding handling to lead the way in closing this hole.
Port-stealing: This can be mitigated by using a separate VLANs for non-critical passwords/SSIDs, especially for open WiFi networks. This is no more straightforward and easier to implement than in Alta Labs’ management platform.
Client isolation: Alta Labs employs client isolation in a scalable manner, i.e. not on a per-AP basis. This is done through AltaPass’ Network Types, and when a non-Standard network type is used, Alta Labs proprietary Client Isolation is automatically enabled, which offers the best client isolation that is available today, acknowledging that GTK abuse is something that the entire industry needs to take seriously.
As a summary, some of the the easiest and best steps to protect your WiFi network (and network infrastructure) today are:
Even in the IT security industry, we are bombarded with equipment that requires accepting self-signed certificates, not just for initial install but for long-term use, and we at Alta Labs believe we can do better than that!
We appreciate your feedback, and thanks for being Alta Labs fans!
For those with a Route10 who want to mitigate the gateway bouncing aspect of that, it’s already possible to configure Route10 to block such attempts in filter rules.
Browse to Settings, Firewall, Filter. Add a new rule there. Source is the source IP subnet of one specific VLAN (10.6.1.0/24 in the depicted example), with Destination set the same. Zone In is LAN, and Zone Out is LAN. If you have multiple VLANs and want to permit inter-VLAN routing but block gateway bouncing, then the Interface In and Interface Out fields must be configured for the bridge interface of the VLAN in question. For VLAN 1, that is br-lan. For other VLANs, that is br-lan_N where N is the VLAN ID (e.g. br-lan_2 for VLAN 2). If you have only one VLAN, then the Interface In and Out fields can be left blank. At the bottom of the window, choose block or reject. Reject is generally preferable for LAN rules as it is friendlier to LAN clients in that they won’t have to await a timeout to know their traffic has been blocked. If your network is IPv6-enabled, you will need to add the same rule to cover IPv6, just changing the IP Version, Source, and Destination accordingly. If you want to prohibit gateway bouncing on multiple VLANs while still allowing inter-VLAN routing, you will need to add one filter rule per-VLAN and one per-IP Version.
Caveats
There are a couple obvious consequences of doing this. One is NAT reflection. This will block NAT reflection since that’s gateway bounced traffic and must be to function. If you add a rule to pass that specific traffic before blocking bounced traffic, that will keep NAT reflection working while gateway bouncing is still blocked. The second is hosts with misconfigured subnet masks who are relying on the router for same-subnet connectivity. Such as if you have a /24 static IP host on a /22 network, then the router is handling part of the same-subnet connectivity for that host.
Beyond those obvious ones, there are nearly limitless possibilities for this to break things in other edge cases. Essentially every router ever created will “gateway bounce”, so it’s a certainty some other scenarios are dependent upon it. In sane configurations, Windows, macOS, iOS, Android, and common Linux distributions won’t have any problems. But I strongly suspect there are some buggy IoT devices out there which are dependent upon gateway bouncing, among other possibilities. We won’t really know how prevalent that is until people start configuring routers this way much more widely than today.
We’re evaluating how to make this easier to configure, and what the appropriate defaults should be going forward, with great caution because of the aforementioned certainty of introducing problems in edge cases. This manual configuration can be applied in the mean time.
Thank you so much for the in-depth responses @Alta-Jeff and @Alta-cmb ! Very much appreciated 
If anything like the more aggressive GTK rekeying or gateway bouncing mitigation gets implemented in a firmware update, I think it’d be great to call it out in the release notes in relation to this so people know the what and why for the change.
Thanks again!
