New AirSnitch attack breaks Wi-Fi encryption in homes, offices, and enterprises

That guest network you set up for your neighbors may not be as secure as you think.

See full article...

 

[NetMage]

I would have appreciated a bit more about the infrastructure issues and work arounds for those that have to run enterprise networks with guest WiFi as well as the client side information.

 

[negolith]

So I understand the MitM aspects of the attack and how that can break client isolation on guest networks. What I'm not seeing is how that works to grab trusted client data.

 

[Trumplethinskin]

Interesting, but Wi-Fi encryption has never been considered very secure. That's why we have proper encryption between individual devices or use VPN's.

also, https://www.eff.org/pages/openwirelessorg

 

[Xyler]

Wait, I am having a very hard time understanding the severity of this potential attack.

Does it require Physical access to anything? If so, it's kind of odd to think of a someone who works with network stuff. I can't wrap my head around how this isn't just easily thwarted by proper VLAN management.

No exposed data ports should have the same VLAN as any of the access points, and especially any of the SSIDs. I don't get how the man in the middle in this case would work. Seems like several things need to be wrongly configured to make this attack work well.

Does this potentially break WIFI encryption? Yeah. But it seems like the traditional "If the attacker can get this exploit done, then you've had bigger problems before" type of exploit.

I just need to know how easy it is to get this exploit done on a properly configured enterprise level network, with VLANs and other security measures set. Just because you splice into a cable physically doesn't mean Layers 2 to 7 suddenly become vulnerable...

 

[afidel]

Haha, I read the paper and the attack only works if you put the guest SSID on the same vlan as the enterprise SSID or the networking equipment. Nobody doing an enterprise network is going to be doing that. Heck, my home network has an isolated vlan for the guest SSID because nobody has ever thought that guest isolation was impervious.

 

[equals42]

It appears that you can mitigate threats to internal networks by putting guest wifi onto its own VLAN with no access to the internal VLANs. Just setup the guest wifi as only allowed WAN access. Still sucks for public wifi and for guest wifi at large public spaces though.
This is directly quoted from page 13 of the white paper:

Improving Network Isolation. To improve isolation mechanisms on single APs, untrusted BSSIDs (e.g., guest networks) can be put in isolation groups, i.e., VLANs. VLANs logically separate network segments, meaning an attacker on one VLAN cannot send packets to or snoop on another VLAN. This prevents a client in the untrusted BSSID from launching the port stealing attack to redirect traffic destined to the victim in a trusted BSSID.

[edited to add source.]

 

[feydreutha]

It seems to only work in same VLAN , so an issue for domestic guest WiFi which tend to be in same vlan as production (same subnet) but not for proper enterprise setup with a vlan per SSID and general assumption that everyone on same vlan is at same trust level.

 

[Xyler]

It appears that you can mitigate threats to internal networks by putting guest wifi onto its own VLAN with no access to the internal VLANs. Just setup the guest wifi as only allowed WAN access. Still sucks for public wifi and for guest wifi at large public spaces though.

I've configured a few public WIFI stuff. And in the back-end, especially in businesses and enterprise settings, you always segment the Guest/Public Wireless. Some even go as far as having a separate WAN link dedicated to guest to fully isolate Guest from Internal services.

 

[siliconaddict]

by contrast, requires that the attacker already have some sort of access to the Wi-Fi network.

And this folks is why I told Comcast to shove their router with WIFI up their exhaust port. Outside the fact that I'm not here to build out their infrastructure for their VOIP business unless they pay me, I don't want to allow ANYONE I don't know to be on the same network as my stuff.

 

[siliconaddict]

It seems to only work in same VLAN , so an issue for domestic guest WiFi which tend to be in same vlan as production (same subnet) but not for proper enterprise setup with a vlan per SSID and general assumption that everyone on same vlan is at same trust level.

Good to know. I put all my IOT crap on its own isolated VLAN and have "production" e.g. my day to day devices on its own VLAN.

 

[EricM2]

Wait, I am having a very hard time understanding the severity of this potential attack.

Does it require Physical access to anything? If so, it's kind of odd to think of a someone who works with network stuff. I can't wrap my head around how this isn't just easily thwarted by proper VLAN management.

No exposed data ports should have the same VLAN as any of the access points, and especially any of the SSIDs. I don't get how the man in the middle in this case would work. Seems like several things need to be wrongly configured to make this attack work well.

Does this potentially break WIFI encryption? Yeah. But it seems like the traditional "If the attacker can get this exploit done, then you've had bigger problems before" type of exploit.

I just need to know how easy it is to get this exploit done on a properly configured enterprise level network, with VLANs and other security measures set. Just because you splice into a cable physically doesn't mean Layers 2 to 7 suddenly become vulnerable...

Same confusion and basic questions here. I found the linked paper to be somewhat clearer, especially in stating that specifically WLAN device isolation is affected in the first place, not WIFI encryption as such.
So- if I got that correctly - the attack vector starts with a valid access to a "guest" or normal WLAN and from there you need to solely rely on WLAN's built-in device isolation to be vulnerable.

 

[Tactical Finesse]

And this folks is why I told Comcast to shove their router with WIFI up their exhaust port. Outside the fact that I'm not here to build out their infrastructure for their VOIP business unless they pay me, I don't want to allow ANYONE I know to be on the same network as my stuff.

Presuming ISPs were as foolish in configuration as they frequently are at the install points....that could make take this from being a "problem", to being a really big deal.

 

[Billiam29]

It appears that you can mitigate threats to internal networks by putting guest wifi onto its own VLAN with no access to the internal VLANs. Just setup the guest wifi as only allowed WAN access. Still sucks for public wifi and for guest wifi at large public spaces though.

This is what I was thinking as well. I can kind of see how maybe you might be able to DOS a production client from a guest vlan with this attack but that's about it. As soon as you tried to mitm, wouldn't layer 3 come into play and then you...the attacker...would be on the wrong segment?

 

[jmurtari]

Nice article - good explanation of a complicated topic!
Thanks for the effort you put in on this - much appreciated!

 

[siliconaddict]

Presuming ISPs were as foolish in configuration as they frequently are at the install points....that could make take this from being a "problem", to being a really big deal.

The X factor is I have no idea how Comcast configures the isolation on these devices. Is it a straight up VLAN or something else? Doesn't really matter to me. I have a zero trust relationship with these devices.

 

[Tactical Finesse]

The X factor is I have no idea how Comcast configures the isolation on these devices. Is it a straight up VLAN or something else? Doesn't really matter to me. I have a zero trust relationship with these devices.

It isn't just Comcast, Spectrum officers a similar thing IIRC. It seemed like a neat idea--but now a really dumb one.

 

[ERIFNOMI]

It isn't just Comcast, Spectrum officers a similar thing IIRC. It seemed like a neat idea--but now a really dumb one.

It was always stupid. Random people hopping on your AP wastes your airtime and your already oversubscribed, congested DOCSIS link back to a shit ISP that couldn't give less of a fuck about you because they have an effective monopoly with essentially no regulation.

 

[archtop]

There's always Ethernet, if conditions permit.

 

[echoRelay]

"..including those from Netgear, D-Link, Ubiquity, Cisco, and those running DD-WRT and OpenWrt."

^^ Ubiquiti **

 

[Aurich]

I approve of the upper deck and sub heading for this story.

 

[Jeff S]

Wait, I am having a very hard time understanding the severity of this potential attack.

Does it require Physical access to anything? If so, it's kind of odd to think of a someone who works with network stuff. I can't wrap my head around how this isn't just easily thwarted by proper VLAN management.

No exposed data ports should have the same VLAN as any of the access points, and especially any of the SSIDs. I don't get how the man in the middle in this case would work. Seems like several things need to be wrongly configured to make this attack work well.

Does this potentially break WIFI encryption? Yeah. But it seems like the traditional "If the attacker can get this exploit done, then you've had bigger problems before" type of exploit.

I just need to know how easy it is to get this exploit done on a properly configured enterprise level network, with VLANs and other security measures set. Just because you splice into a cable physically doesn't mean Layers 2 to 7 suddenly become vulnerable...

What is physical access to Wi-Fi? I mean, yes, you have to be in range of the wifi devices. But that might be having a nearby repeater device outside the premises.

Keeping in mind that this IS about Wi-Fi and not ethernet, but, perhaps your confusion is because of some things the article said about ethernet. If I'm understanding correctly, the references to Ethernet are because, Wi-Fi at a low level, basically is Ethernet over radio, with a few tweaks like SSIDs, and then encryption layered on top of that.

But the very lowest level of the stack, that goes out over the radio waves, isn't encrypted and validated against known keys. So MAC address spoofing can happen, which it sounds like is the basis of this attack - that the malicious device spoofs another device, then forwards traffic as a machine-in-the-middle.

Any traffic that gets decrypted at the router, normally, like DNS, can thus be decrypted by the MITM using the MITM's provided keys, I think is what's being said here. Which is yet another argument to use encrypted DNS.

What we really need, I think, though, is a modern Wi-Fi replacement/updated version that uses strong key-based encryption/authentication at Level 1 of the network stack? Is that the right takeaway here?

 

[azazel1024]

It appears that you can mitigate threats to internal networks by putting guest wifi onto its own VLAN with no access to the internal VLANs. Just setup the guest wifi as only allowed WAN access. Still sucks for public wifi and for guest wifi at large public spaces though.

Thanks to you and Afidel. I had wondered about that. My guest network is already setup as WAN access only for my guest network. I'll admit I don't have VLANs setup (but I can, my switch and AP support VLANs).

 

[Jeff S]

I approve of the upper deck and sub heading for this story.

<image snip>

Aren't you supposed to hold vinyl records by the edges so you don't risk damaging the grooves?

 

[ERIFNOMI]

Thanks to you and Afidel. I had wondered about that. My guest network is already setup as WAN access only for my guest network. I'll admit I don't have VLANs setup (but I can, my switch and AP support VLANs).

If guest devices are on the same subnet as everything else, it sounds like you'd be vulnerable to this. This sounds like spoofing at layers 1 and 2.

Just turning on VLANs doesn't do anything. You have to segment your network. VLANs are a tool that allow you to segment your network without duplicating every switch and AP on your network for each subnet.

 

[YardOfLard]

Nice article - good explanation of a complicated topic!
Thanks for the effort you put in on this - much appreciated!

Needs more em—dash

 

[tycho55]

For anyone who wants to read the paper, the link is a bit buried, but here you go:

https://www.ndss-symposium.org/wp-content/uploads/2026-f1282-paper.pdf

 

[Aurich]

Aren't you supposed to hold vinyl records by the edges so you don't risk damaging the grooves?

I do not worry about touching my records, but even if I was precious with some of them I would not be with my novelty 45 I bought for a dollar in 1998 for the Reservoir Dogs connection.

 

[Martin Blank]

What is physical access to Wi-Fi? I mean, yes, you have to be in range of the wifi devices. But that might be having a nearby repeater device outside the premises.

Repeaters add delay. Most attackers will use an antenna. A 9 dBi yagi antenna is inexpensive and can get you several hundred meters of distance with a little practice.

What we really need, I think, though, is a modern Wi-Fi replacement/updated version that uses strong key-based encryption/authentication at Level 1 of the network stack? Is that the right takeaway here?

Wi-Fi has the same basic problem as SMTP: it has fundamental weaknesses that are extremely hard to fix without utterly shattering backward compatibility that too many things rely on. It's good enough for most things, and there are a pile of fixes to address the problem.

My first thought on this was increasing the security of the perceived reconnection. Require it to be encrypted by the last key used or signed by the last DH key negotiated. If it's not, don't let it connect and don't put it in the CAM table. Require a timeout from the last known good connection before letting it reconnect. However, this could affect devices that sleep for long periods and could set up a DoS attack by connecting with a known MAC address that one wants to block.

 

[GaitherBill]

I blame uncle Terry for this.

He’s always going to totallylegitaibotbettingsite.russia.

 

[McTurkey]

I have a question that I lack the wisdom to know if it's silly or not.

Is there a potential intersection between the hardware capabilities of the cellular-capable satellite mega constellations and WiFi attacks? My understanding is that these satellites use what is essentially a software defined radio, which means they could transmit and receive on pretty much any frequency, with sufficient capability to connect to something as low-power a cell phone (albeit with very low bandwidth). Given this, does the potential exist for interception of and attacks on WiFi traffic, assuming ground density is low enough?

 

[TheShark]

And this folks is why I told Comcast to shove their router with WIFI up their exhaust port. Outside the fact that I'm not here to build out their infrastructure for their VOIP business unless they pay me, I don't want to allow ANYONE I don't know to be on the same network as my stuff.

I never used the 'xfinititywifi' or whatever it's called that comes with their router. I always used my own cable modem and router. But surely it doesn't dump the random xfinitity customers onto the same LAN as your own stuff. I mean if it did, that gives you the opportunity to do all sorts of hilarious stuff to the unwanted visitors on your network.

 

[hdmoore]

Hi folks! Great comments and questions on whether VLAN isolation helps here.

Edit: Original comment indicated that VLANs didn't help, I had misread the cross-BSSID attack details.

The paper is clear that the inject/MITM is cross-BSSID but not cross-VLAN (assuming the device isolates correctly).

Thanks for the feedback!

 

[ERIFNOMI]

I never used the 'xfinititywifi' or whatever it's called that comes with their router. I always used my own cable modem and router. But surely it doesn't dump the random xfinitity customers onto the same LAN as your own stuff. I mean if it did, that gives you the opportunity to do all sorts of hilarious stuff to the unwanted visitors on your network.

I would not at all be surprised if it just does client isolation, which as this exploit demonstrates is not all that isolated.

 

[Edified]

That was a lot of words to read for basically no technical details.

 

[chrisaj]

My takeaway from this is that to be secure, you need to get a separate physical WiFi network switch and put your guest network on that. Guest networks and VLANs on your main switch won't help you, since the attack is at a lower level. Is that correct?

 

[ERIFNOMI]

Hi folks! Great comments and questions on whether VLAN isolation helps here. The short answer is that VLANs are not a practical barrier -- if your APs advertise more than one SSID (ex: Guest and Work) networks, its implied that those are on different VLANs, and that the WAP itself is enforcing the VLAN segmentation.

The AirSnitch attacks are effectively "physical" layer - an attacker can use shared group keys and the broadcast injection to target a client in any VLAN. The alternative is to limit each WAP to a single VLAN at the switch level, but then you can't use the same physical WAP for multiple SSIDs, and its impractical to deploy multiple WAPs in the same physical space when multi-SSID/VLAN modes are built into the product.

There may be specific devices where AirSnitch can't cross VLANs, but those are likely in the minority here.

I haven't read the paper (I will if I find some time later today), but this made me go re-read the description of the attack here.

If there wasn't too much lost in the game of telephone, it looks like the attack is MAC spoofing to get the traffic from another client and...that's it? And you're suggesting these APs are happy to send traffic tagged for VLAN100 to a client connected via BSSIS tagged VLAN200?

 

[sryan2k1]

Client isolation has always been security theater. Treat any network as untrusted, and don't click through certificate warnings (in fact at work we disable user's ability to bypass cert warnings). This seems like a nothingburger. Your data can always be intercepted at any point along the path.

 

[Deleted member 221201]

Have Eero routers ever been tested in these scenarios?

 

[TheShark]

So I didn't read the whole paper, but I did skim it. Mainly because I wanted to see how they were getting the upstream traffic. I think the short version is, all the games you can play with wired ethernet switches in terms of ARP and MAC spoofing can be done on WiFi. Downstream, you can connect to the WiFi with someone else's MAC and start getting their traffic. Just like one a wired ethernet you can spoof someone else's MAC and get the CAM table to point to your port instead of theirs. And to get upstream traffic you can connect to the WiFi with the routers MAC and start getting all the upstream traffic. Which you can also do on a wired ethernet. On the wired side, these aren't new attacks and there are mitigations for them. But those mitigations aren't always configured by default, and I'm not surprised that they aren't always present on WiFi based ethernets.

That said, WiFi may make some of these easier because in most cases an attacker has access to essentially multiple switches at once. For upstream traffic especially, it's one thing to steal the gateway MAC but then you are left with the problem of getting the traffic to the actual gateway after it's been viewed/edited so that clients perceive a working end to end connection. It looks like based on the paper that an attacker could connect to both 2.4GHz and 5GHz radios, spoof the gateway on one frequency and get all the upstream traffic from client on that freqency and then resend those packets on the other frequency to the actual gateway without breaking the spoof on the first frequency.

Anyway, interesting paper. SSL and HTTPS are your friends. And don't trust WiFi any more than your ISP. Which is to say not at all.