That guest network you set up for your neighbors may not be as secure as you think.
See full article...
See full article...
New AirSnitch attack breaks Wi-Fi encryption in homes, offices, and enterprises
- Thread starter JournalBot
- Start date
I'll admit that a few years ago I just gave up on WiFi (or ethernet VLANs even) providing more then token security. Instead I switched to having everything important either being hard isolated or using an internal Wireguard VPN. Even if you connect to the main network it still gets you no access to anything sensitive. Wireguard performance has gotten good enough that it's either no or insignificant speed burden on a wireless network. It'd be nicest of all if the phy interface could just be trusted, but absent that I think simply doing an internal overlay has gotten fairly doable. Apple's lack of native support is now the biggest irritation but not the end of the world. Maybe the industry should just standardize on tunneling higher up the stack given how miserable the industry consortium has been about security.
That does leave the challenge of protecting legacy devices/appliances if one needs to, I've been experiment with using SBCs as a sort of network slug, where they go between the device and rest of the network and transparently provide encryption functionality. I think there'd be a market if some hardware maker released a set of dongles that slapped a nice GUI on the whole configuring/deployment/herding aspects. It's also a cool approach for things like making a "USB hard drive" which is actually backed by a NAS.
That does leave the challenge of protecting legacy devices/appliances if one needs to, I've been experiment with using SBCs as a sort of network slug, where they go between the device and rest of the network and transparently provide encryption functionality. I think there'd be a market if some hardware maker released a set of dongles that slapped a nice GUI on the whole configuring/deployment/herding aspects. It's also a cool approach for things like making a "USB hard drive" which is actually backed by a NAS.
Upvote
4
(4
/
0)
These types of exploits is why I VPN encapsulate EVERYTHING, including DNS, from my host to my VPN server (which also provides DNS service), and encrypt everything from the VPN server to the target host. Nothing on my LAN is in the clear, and nothing leaves my LAN in the clear.
Upvote
-3
(2
/
-5)
Is it safe to say using a VPN solves this problem and a bunch of other things. Easiest fix
Upvote
-6
(2
/
-8)
According to my quick research, Wi-Fi routers use the following power levels depending on the band used:
- 2.4 GHz: about 50–100 mW, i.e. 0.05–0.1 W, with many APs defaulting to 100 mW (20 dBm).
- 5 GHz: about 50–200 mW, i.e. 0.05–0.2 W, with common defaults around 200 mW (23 dBm) on lower channels and higher limits (up to 1 W or more) allowed on some channels in some regions.
- 6 GHz (Wi‑Fi 6E/7): roughly 60–130 mW, i.e. 0.06–0.13 W for low‑power indoor access points, depending on channel width; for example, a 20 MHz channel at the low‑power limit is about 63 mW (18 dBm) and a 40 MHz channel about 126 mW (21 dBm).
As the greatest transmit power of a Wi-Fi router is a little over 1 watt, it is highly doubtful that in the frequency ranges that routers use, 2.4 GHz, 5 GHz, and 6 GHz, that they would have the power to reach a satellite.
A satellite may have the output power to reach a router, but a router would not have the output power to reach a satellite. With such a one-way connection, it does not seem that this exploit would work.
Upvote
7
(8
/
-1)
I appreciate that. I am aware. It was more the "good info to know, I have part of the puzzle, but I haven't ever implemented the actual solution of VLANs".
I guess I should add, welp, and now I have a really solid good reason to implement VLANs.
Upvote
4
(4
/
0)
Just don't accidentally point your parabolic WiFi bridge up at space and you'll be fine.
Upvote
14
(14
/
0)
It's indicated in the comments here (and has subsequently been added to the article) that the implementation of VLANs is not necessarily a helpful measure (without restricting an access point to a single VLAN):
https://meincmagazine.com/civis/threa...ffices-and-enterprises.1511831/#post-44274656
Upvote
6
(6
/
0)
The article seems to claim that the attacker spoofing the victim's MAC address on another radio allows for "bidirectional" MitM, but doesn't explain how. The key in a MitM attack is to be in the middle, between the victim and their network. How does messing with an AP's forwarding table coerce the victim to send their traffic to the attacker? Also as soon as the victim sends any data to the AP that will fix the forwarding table so at best the attacker is going to only see some of the data.
Upvote
17
(17
/
0)
Just pointing it out because it's a common mistake people who just know enough to know the term VLAN make. Networking is magic to most people.
Upvote
7
(7
/
0)
Upvote
-6
(3
/
-9)
Phsyical access, like being able to touch the AP, the switches or cables.
But besides that, all this seems to point to MAC Address Spoofing, which is not Layer 1. In the OSI Model, that's Layer 2. Layer 1 is literally the radio waves. It seems the attack utilizes broadcasts to learn the MAC Address of the gateway. Then, using the exploit, spoofs the gateway and so traffic is routed towards the attacker's PC, rather than the actual gateway.
Has nothing really to do with what I was worried about, which is Inter-SSID hopping. Guest Networks are always treated as hacked, and should always be segmented as best you can. If you can use this to hop SSIDs, then that's a worry. You literally cannot encrypt layer 1 though, as that's the physical media. The radio waves, the electricity running down a wire, the laser light in a fibre-optic cable, that's the layer 1. Which is why I was so confused. This isn't exploiting the layer 1, it's technically exploiting the layer 2.
The article mentions Layer 7, so I'm assuming they're referencing the OSI model:
Physical
Data Link
Network
Transport
Session
Presentation
Application
MAC Addresses live in Layer 2, as part of the Ethernet Protocol. This targets the fact APRing reveals the MAC, and does trickery to redirect traffic to the attacker. You literally cannot encrypt the Physical layer, because that's just the raw representation of 1 and 0, be it electricity, radio waves, or light. Hell, sonar/sound could be a layer 1 if you want.
Upvote
23
(23
/
0)
I significantly disagree with this. Client isolation within a given SSID has some measures of "security theater."
You don't implement network segmentation with the expectation that someone on one VLAN is able to arbitrarily cross that boundary and MITM the traffic on another segment. Similarly, you don't implement multiple SSIDs in an enterprise setting with the expectation that someone on one is able to hop across to another.
It is always best practice to treat networks as untrusted but in no way is the arbitrary crossing of SSID and VLAN boundaries a "nothingburger." Guest networks in most major enterprises are broadcast out of the same APs as the enterprise networks because there is an expectation of network segmentation to protect the enterprise traffic.
For sure this is a lot less of a crisis than it would be a decade or so ago, since encrypted traffic is the vast majority of traffic that's sent across a network. But the attacks that do exist (such as unencrypted DNS) are still problematic, and as we progress down the path of quantum-resistant algorithms, you'd still prefer to reduce the amount of "collect now, decrypt later" attacks. Sure, people can get privileged position elsewhere in the chain but that doesn't mean that we want to allow some random guy in the parking lot to bulk collect network data.
This is a meaningful finding. It's not making me open a Sev. 1 bridge with our CISO for immediate remediation. But it will certainly make me consider where and how we permit wireless access to untrusted clients in my company.
Upvote
25
(26
/
-1)
Thanks for the useful context!
I would very much appreciate any home router recommendations for decent level security and no forced consent to allow tracking. (Assume the user knows enough to follow directions and configure it appropriately without a phone app, but doesn’t want to DYI a pi-hole, etc).
Upvote
4
(4
/
0)
The main part of the article seems to focus on untrusted parties getting access to networks on a public access WiFi network:
The only upside, in my opinion, is that my router sends me alerts when it sees MAC IDs where it doesn't expect them. I'll have to pay more careful attention to those alerts from now on.
The bit that worries me more, from a home WiFi network perspective, is that I keep my untrusted IoT devices on their own private network, isolated. This attack means that if any of those devices is actually compromised (by a threat actor or by the vendor/manufacturer themselves), it would be possible to use the device to transit to all networks managed by the same router and act as an agent in the middle against all other devices using the router, once discovery is complete.
The only upside, in my opinion, is that my router sends me alerts when it sees MAC IDs where it doesn't expect them. I'll have to pay more careful attention to those alerts from now on.
Upvote
6
(8
/
-2)
I’m not sure I agree with the characterization of this attack as “broader but less severe” than WEP hack.
To individual users, probably, but it makes public WiFi a lot scarier than it was yesterday.
But breaking device isolation and WLAN segmentation in corporate config is a very big deal. Suddenly, if your network isn’t configured just the right way in terms of VLANs, “high security” limited access networks are neither. Even without guest networks, there may be networks that ordinary employees aren’t allowed to access.
And corporate hackers tend to be well resourced and determined.
Bad day to be a CTO.
To individual users, probably, but it makes public WiFi a lot scarier than it was yesterday.
But breaking device isolation and WLAN segmentation in corporate config is a very big deal. Suddenly, if your network isn’t configured just the right way in terms of VLANs, “high security” limited access networks are neither. Even without guest networks, there may be networks that ordinary employees aren’t allowed to access.
And corporate hackers tend to be well resourced and determined.
Bad day to be a CTO.
Upvote
11
(11
/
0)
- Add bookmark
- Featured
- #56
I'm sorry I'm having such a hard time explaining this process in a clear way. I just updated the section following the "Stuck in the Middle with You" subhed in an attempt to do better. The attacker intercepts the target's downlink traffic by replacing the target's MAC with the attacker's MAC. This is essentially a classic port stealing attack from the early Ethernet days, except it has been adapted for Wi-Fi. It completes the first half of the MitM.
To make the MitM bidirectional the attacker needs a way to redirect the intercepted frames back to the target. To do this, the attacker restores the MAC > port mapping to the original one, i.e. the one that associated the target's MAC to the port. The attacker does this by sending a ping from a random (i.e. not the attacker's) MAC . This ping must be wrapped in the Group Temporal Key.
Then, the attacker repeats these two steps over and over, in rapid succession. Please also see the diagram that I added.
Does any of this help clarify?
Upvote
21
(23
/
-2)
- Add bookmark
- Featured
- #57
Yes. The broad top-line conclusion of the paper on this topic is:
The most fundamental, basic element of the attack is happening at layer one (the shared radio medium).
From the paper, that's this part:
From there, they were able to pivot to other attacks that facilitated hopping over to a protected BSSID and (for example) carrying out attacks against the RADIUS authentication.
They had to add a rogue AP and rogue RADIUS server to demonstrate an attack that pivoted from a guest SSID to a WPA2/3 enterprise SSID, but that's easy enough to build into an attack kit that it's still viable.
So what mitigations are actually viable?
Well, the vendors will probably patch stuff, which will help. But there are also other important elements to consider.
Separate APs
The only perfect solution would seem to be isolating the SSIDs on different APs. Notably, however, they did demonstrate attacks against different APs sharing the same distribution network. Piecemeal won't cut it.
Separate internal/virtual bridges
At a step short of that, the DD-WRT and Open-WRT deployments tested demonstrated resilience against several elements of the attack by isolating the different SSIDs on separate internal bridges. I expect that, or something very similar, will feature prominently in how the other vendors approach resolving many of these elements.
Rogue detection
As a detective control, rogue AP detection would be very effective here. I'm not seeing any significant portion of the attack chain that can be carried out without a rogue AP. That's not practical for (most) home deployments, but it's a common feature in enterprise tooling.
WPA3 Enterprise Public Key
I think WPA3 enterprise in public key mode is safe, but I'd need to go over it in more detail to say that for certain.
They explicitly note that the data link attack primitives won't work there directly.
The demonstrated a pivot from an attack on guest SSID to an attack on an Enterprise SSID specifically attacked the RADIUS setup. And I can't think of a way to do the equivalent for a PubKey setup.
(edit: spelling, clarity in final paragraph)
Last edited:
Upvote
17
(18
/
-1)
- Add bookmark
- Featured
- #58
The AirSnitch MITM works best when targeting a victim on the same SSID (and likely VLAN), but separate SSIDs/VLANs may not be enough depending on how the WAP handles the traffic, and even with VLAN isolation an attacker can still drop frames into the victim VLAN, even if they can't do a full MITM.
WAPs handle VLAN tags (typically by SSID), but not the same way as a physical ethernet switch; there isn't a physical port to lock a client to. The AirSnitch bugs let an attacker stuff traffic into the "port" for a target client. The bidirectional MITM might be trickier to across SSIDs or VLANs, but its likely going to depend on the specific device behavior.
Separate from the MITM, there are other ways to abuse the injection issue. An attacker can inject a UDP request for something like NetBIOS/mDNS/SSDP/SNMP that bounces a response back to the internet, instead of to the attacker's wireless client, and be able to extract useful data this way.
Upvote
14
(15
/
-1)
DNSSEC would mitigate the DNS spoofing.
HTTPS (SVCB subset) record with preloading of protocol level.
And so on.
Get to it.
HTTPS (SVCB subset) record with preloading of protocol level.
And so on.
Get to it.
Upvote
-3
(1
/
-4)
Ahhhh. So, it sounds like I'd really need a guest AP segmented to a VLAN and a separate network AP on the home network AP and not allow the two to comingle wireless traffic at all.
Grrrr.
Upvote
3
(3
/
0)
Despite being up to my neck in it since I was in my teens back in the mid 1990s (yay, I predate wifi!), I won't lie that every once in awhile it feels like magic still. I certainly don't deal with it as a job, just dabbling with my home network. A lot of stuff I worked on in college though. I actually worked with some pre-cert 802.11g stuff. That was BRAND spanking new in our college labs and seemed magical. I actually worked an internship in college to see if it was worthwhile rolling out 2g network connected PDA's to state police officers so they could remotely access state criminal databases while on patrol or on calls.
But other than working as a system analyst for a few years right after college, my professional work moved away from IT and more on to the business side of things (dealing with IT, but as the customer for IT systems, not the designer of).
Upvote
4
(4
/
0)
Good time for CTOs to migrate their infrastructure to a ZTNA model. Actually, 5-8 years ago was a good time to do that. Split off service access from network access and ensure it's all encrypted.
Upvote
3
(3
/
0)
How do we mention HD Moore in the article and not mention that he created Metasploit? Seems like an oversight in the article.
Upvote
9
(9
/
0)
Also, wireless Cain & Able FTW! Just need to go find my old download and update it for this attack.
What's the over/under on how long before this attack is in Kali?
What's the over/under on how long before this attack is in Kali?
Upvote
2
(2
/
0)
I guess I follow this in terms of how a WAN-to-target packet will first reach the attacker by MAC spoofing, then the attacker restores the MAC table and forwards that packet onto the target.
But I still don’t understand how this can be used for the reverse direction, target-to-WAN. Does the attacker use the same method to spoof the MAC of the default gateway? (In which case outbound packets for all clients, not just the target, would hit the attacker.)
Honestly it all sounds terribly impractical, if I’m understanding it right. For every single packet in each direction, the attacker needs to spoof the MAC of its intended destination, then restore the MAC table using ICMP?
Upvote
16
(16
/
0)
Some please correct me if I'm wrong. But, the authors seem to be...sensationalizing their finds, as is par for the course now.
They seem to be making the unstated assumption that all Wi-Fi security is somehow built entirely on top of client isolation so that breaking it breaks all of Wi-Fi Security. It's like saying, you think having a physically separate laptop from the attacker protects you at the coffee shop? Think again! They could plugin a rubber ducky when you go order your next latte! And attackers can do cookie stealing or DNS attacks now that they can talk to other Wi-Fi clients? I wouldn't exactly call these hypothetical attack chains novel.
They seem to be making the unstated assumption that all Wi-Fi security is somehow built entirely on top of client isolation so that breaking it breaks all of Wi-Fi Security. It's like saying, you think having a physically separate laptop from the attacker protects you at the coffee shop? Think again! They could plugin a rubber ducky when you go order your next latte! And attackers can do cookie stealing or DNS attacks now that they can talk to other Wi-Fi clients? I wouldn't exactly call these hypothetical attack chains novel.
Upvote
12
(14
/
-2)
A few years ago, I would have agreed. But since then, Starlink and TMobile are cooperating on delivering Satellite service to TMobile phones. Hard to imagine that the RF power output of a cell phone is much over 1 watt to avoid the RF <-> brain cancer thing. Plus cell phone antennas aren't exactly large. Seems those Starlink satellites have some pretty sensitive receivers.
I would think the trick to satellite survalence of wifi would be filtering out the needle from the very large haystack of wifi signals. But Starlink seems to be able to capture the cell signal of the sat phone from the haze of millions of cell signals.
Upvote
7
(7
/
0)
Yup this was going to be my exact reply as well. I'm just not making that leap to bidirectional; even the diagram added to the article doesn't show any interception the other way. (And just for background, I am very familiar with the IEEE 802.11 standard; I've written hundreds of lines of code to implement WPA-2 handshakes in software.)
Upvote
10
(10
/
0)
However the paper mention Vlan on AP as being an efficient defense :
«
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. »
And
«
We have verified via experiments that TP-Link EAP613 can put guest SSIDs into separate VLANs, which effectively nullifies the exploitation techniques listed in Table VI. »
So I am pretty confused if this is more for basic guest isolation like home router do or if this is able to traverse usual vlan setup of guest in enterprise, which tend to share AP with corporate, and will require a redesign of guest access at lots of companies
Upvote
10
(10
/
0)
Upvote
7
(7
/
0)
An explanation? Some account with 5 comments in its history, sounding like an LLM, saying "actually, MAC spoofing can break VLAN isolation... somehow" is not terribly authoritative, sorry.I mean, in this context HD Moore IS the citation!
What more do you want?
Upvote
-10
(4
/
-14)
The leap to bidirectional, comes when the attacker restores the MAC > port mapping to the original one, i.e. the one that associated the target's MAC to the port. The attacker does this by sending a ping from a random (i.e. not the attacker's) MAC . This ping must be wrapped in the Group Temporal Key.
Can you help me understand what's unclear about this?
Upvote
1
(3
/
-2)
Military drones loitering at high altitude could do this. I wouldn't worry about the commercial satellite mega constellations, however, unless you have an idea how they can turn wifi hacking into a profit making enterprise.
Upvote
7
(7
/
0)
Yeah this is decidedly not a layer 1 attack (which would be something like jamming the radio transmissons or surrounding stuff with a faraday cage). This doesn't work by interfering with/intercepting layer 1 traffic (hell, you can't not intercept layer 1 traffic with wifi, everyone sees all the radio waves), it's strictly a layer 2 and up attack.
Also, I skimmed the paper very briefly and the attack doesn't work on DD-WRT/OpenWRT (and some others) between SSIDs with standard guest setups. That's pretty reasonable: a sane well-crafted setup shouldn't allow traffic that's supposed to go over one SSID to be sent to a client on a different SSID. So, this attack is an issue, yes, but probably not all that big a one in most cases.
Upvote
10
(10
/
0)
Who, you know, just happesn to be a founder of Metasploit and the CEO/Founder of a cybersecurity company. Who commented on this exploit. In this article.
Did you even bother reading the fucking article?
Upvote
8
(14
/
-6)
For the average person worried about their home network, this should be the takeaway.
Upvote
17
(18
/
-1)
This is an excellent paper. We built supernetworks a few years ago after identifying many of these weaknesses in wifi deployments. While I think most people have been aware of the isolation deficiencies what this paper does particularly well is demonstrating full bidirectional man in the middle attacks, which have not been publicly disclosed before now.
Essentially the project we built works by design to defend against these flaws. The WPA2/3 password binds as an identity that carries out into the network policy at layer 3. Each device is placed always in an individual VLAN and subnet keyed off of that credential. Then firewall policy decides what can talk to what. Multicast/mdns is supported too.
Doing this by hand is kind of insane -- so we do this with UI and manage with group names and tags rather than VLAN IDs and IP addresses.
Onto the attack, to understand the bidirectional aspect consider this:
in hostapd the flag they set for client isolation is:
ap_isolate=1
This prevents layer 2 bridging meaning that if I send a wifi packet to the AP with the MAC destination of another peer, it will be blocked instead of forawded by the BSS to the other station.
Now what happens if I instead send the IP packet with the MAC destination of the AP itself, and the AP has IP forwarding on because it is a router?
At layer 3, the IP packet happily gets forwarded to the desintation. Great, we can spoof DHCP replies and so on if we guess the security id or perhaps inject some DNS with some brute force also. But not particularly useful. What we really want is TCP.
If the client tries to respond it will end up sending back to the AP with the MAC destination as the attacker MAC. This ends up being filtered. So it's not bidirectional.
If instead the destination would be wired, or upstream, that bridge filter on the AP does not matter because the packet wont go back that way. So one could possibly spoof upstream IPs to get a bidirectional comm out that way.
Now to go one step further, its possible to mess with the state of the AP layer 2 bridging with a variety of tricky techniques that the paper covers. Some of these use shared GTKs. Others use broadcast packets. Or other flaws, that train the router how to forward back to the attacker despite ap_isolate=1.
Essentially the project we built works by design to defend against these flaws. The WPA2/3 password binds as an identity that carries out into the network policy at layer 3. Each device is placed always in an individual VLAN and subnet keyed off of that credential. Then firewall policy decides what can talk to what. Multicast/mdns is supported too.
Doing this by hand is kind of insane -- so we do this with UI and manage with group names and tags rather than VLAN IDs and IP addresses.
Onto the attack, to understand the bidirectional aspect consider this:
in hostapd the flag they set for client isolation is:
ap_isolate=1
This prevents layer 2 bridging meaning that if I send a wifi packet to the AP with the MAC destination of another peer, it will be blocked instead of forawded by the BSS to the other station.
Now what happens if I instead send the IP packet with the MAC destination of the AP itself, and the AP has IP forwarding on because it is a router?
At layer 3, the IP packet happily gets forwarded to the desintation. Great, we can spoof DHCP replies and so on if we guess the security id or perhaps inject some DNS with some brute force also. But not particularly useful. What we really want is TCP.
If the client tries to respond it will end up sending back to the AP with the MAC destination as the attacker MAC. This ends up being filtered. So it's not bidirectional.
If instead the destination would be wired, or upstream, that bridge filter on the AP does not matter because the packet wont go back that way. So one could possibly spoof upstream IPs to get a bidirectional comm out that way.
Now to go one step further, its possible to mess with the state of the AP layer 2 bridging with a variety of tricky techniques that the paper covers. Some of these use shared GTKs. Others use broadcast packets. Or other flaws, that train the router how to forward back to the attacker despite ap_isolate=1.
Last edited:
Upvote
0
(4
/
-4)
Maybe we are using different definitions of bidirectional? To me it's 2 directions of packets: server-to-client, and client-to-server.
The article explains how server-to-client intercept can work: attacker spoofs the MAC of the client, the packet hits the attacker first, the attacker then uses this ping trick* to restore the proper MAC/port mapping, and sends the packet on to the client.
(*If the client doesn't answer to ping, does this mean the MAC/port mapping can't be restored?)
How does the client-to-server direction work, is what I can't figure out.
Upvote
12
(12
/
0)
Unless I'm misreading the paper, isolating BSSIDs in separate VLANs does provide effective mitigation:
"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." (Section VIII(C))
This won't prevent clients within the same BSSID from breaking client isolation, but it should prevent a client on the guest network from being able to MITM a client on a secure network.
"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." (Section VIII(C))
This won't prevent clients within the same BSSID from breaking client isolation, but it should prevent a client on the guest network from being able to MITM a client on a secure network.
Upvote
14
(14
/
0)
Easy mistake to make. Unlike the author profiles, there's nothing in the user profile establishing it as being linked to the expert cited in the article. And there was no preamble in the comment establishing who they were, or that they were claiming to be the expert cited in the article.
And even if that was understood, seeking citations and clarifications was not inappropriate. Even experts make mistakes - @hdmoore had to correct the comment @miken32 was asking about.
Upvote
14
(14
/
0)