Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

ndss-symposium.org

Post reply on HN
Print view View original

141–150 of 204 posts

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#141

Post by vanhoefm »

NetMageSCW wrote: post #123
vanhoefm wrote: post #112

Earlier quoted context omitted.

I'm a co-author on the paper: I would personally indeed not use the phrase "we can break Wi-Fi encryption", because that might be misinterpreated that we can break any Wi-Fi network. What we can do is that, when an adversary is connected to a co-located open network, or is a malicious insider, they can attack other clients. More technically, that we can bypass client isolation. We encountered one interesting case whe…

Do separate VLANs behind the different SSIDs provide protection?

That should definitely help. You still have to double-check the IP routing tables between the VLANs, but most of the time, that should prevent attacks between SSIDs.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#142

Post by vanhoefm »

blobbers wrote: post #131
vanhoefm wrote: post #112

Earlier quoted context omitted.

I'm a co-author on the paper: I would personally indeed not use the phrase "we can break Wi-Fi encryption", because that might be misinterpreated that we can break any Wi-Fi network. What we can do is that, when an adversary is connected to a co-located open network, or is a malicious insider, they can attack other clients. More technically, that we can bypass client isolation. We encountered one interesting case whe…

Hi! In the case of accessing the private Enterprise SSID, was the network VLAN isolated or some other type of virtualization of the bssid? Thanks for your work on the topic! This is quite interesting!

When testing our own Enterprise devices, VLANs were not used. This was done to understand the impact of client isolation on its own.

For the university networks that we tested, I'd have to ask my co-author. But perhaps my other comment can further contextualize this: https://news.ycombinator.com/item?id=47172327 Summarized, I'm sure that it is possible to configure devices securely, and VLANs can play an important role in this. But doing so is more tedious and error-prone than one may initially assume, e.g., there is often no single setting to easily do so.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#143

Post by kittikitti »

Other members of my household frequently invite people to my own place that have malicious intent against me. They don't like me for reasons like not being a fan of Trump, Drake, or N3on. Unfortunately, this is a risk that many people other than me have to face. This is an eye-opening article as I do provide my guest password to them.

I plan on disabling the guest network entirely and utilizing a completely different router for the guest network. As the paper states, an isolated guest network isn't standardized. I plan on revisiting my network security once it is.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#144

Post by ProllyInfamous »

pluralmonad wrote: post #135
ProllyInfamous wrote: post #83

Earlier quoted context omitted.

For all users reading this on their own home network: DISABLE ALL GUEST NETWORKS It seems as if approved guest access now == system-wide access (at the hardware level). User compartmentalization no longer works .

Is this still true if the guest network is on its own isolated vlan?

Correct; this appears to be a hardware-level problem.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#145

Post by devilbunny »

simoncion wrote: post #125
wtallis wrote: post #104

Earlier quoted context omitted.

More precisely: the manufacturer's software on your consumer grade routers refuses to expose that functionality to the end user. They're almost always relying on VLANs behind the scenes to separate the WAN and LAN ports.

> They're almost always relying on VLANs behind the scenes to separate the WAN and LAN ports. I don't believe this is true. I expect that what's going on there is the WAN and LAN ports on the switch [0] are in separate bridges. Why do you believe that they're using VLANs behind the scenes? It seems silly to add and remove a whole-ass VLAN tag to traffic based on what port it comes in on. Do you have switch chip or ot…

"Use WAN as LAN" is a pretty common option in aftermarket firmwares like DD-WRT or OpenWRT. I know that OpenWRT displays them as VLANs.

That said, this is in no way my area of expertise.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#146

Post by blobbers »

vanhoefm wrote: post #139
delBarrio wrote: post #128

Earlier quoted context omitted.

Hi and thanks so much for the valuable research!! I know it has been asked a lot here already, and probably some in-deep reading would help figure that out by myself. But I’ve noticed that you used Cisco 9130 APs, and noticed only part of the attack work on those. So wanted to ask whether you tested those with just IP based network separation, or also the VLAN-based one? Also, since you’ve mentioned the findings have…

We don't have a CVE number. Whether devices/networks are affected also highly depends on the specific configuration of the device/network. This means that some might interpret some of the identified weaknesses as software flaws, but other weaknesses can also be seen as configuration issues. That's actually what makes some of our findings hard to 'fix': it's easy to say that someone else is responsible for properly en…

I think you could apply specific CVEs to specific devices + setting combination, as:

CVE 1 : router brand X software version Y.Z configured with client isolation does not provide sufficient isolation that it cannot be broken with air snitch.

CVE 2 : router brand A software version B.C configured with client isolation does not provide sufficient isolation that it cannot be broken with air snitch.

etc.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#147

Post by spockz »

vanhoefm wrote: post #139
delBarrio wrote: post #128

Earlier quoted context omitted.

Hi and thanks so much for the valuable research!! I know it has been asked a lot here already, and probably some in-deep reading would help figure that out by myself. But I’ve noticed that you used Cisco 9130 APs, and noticed only part of the attack work on those. So wanted to ask whether you tested those with just IP based network separation, or also the VLAN-based one? Also, since you’ve mentioned the findings have…

We don't have a CVE number. Whether devices/networks are affected also highly depends on the specific configuration of the device/network. This means that some might interpret some of the identified weaknesses as software flaws, but other weaknesses can also be seen as configuration issues. That's actually what makes some of our findings hard to 'fix': it's easy to say that someone else is responsible for properly en…

CVE are handed out like candy in Java land for artifacts that have code that only opens up a vulnerability when another package is available and the first artifact is misconfigured. So I think you would be fully in your right to claim a CVE and list all affected versions of devices/firmwares there.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#149

Post by wtallis »

simoncion wrote: post #125
wtallis wrote: post #104

Earlier quoted context omitted.

More precisely: the manufacturer's software on your consumer grade routers refuses to expose that functionality to the end user. They're almost always relying on VLANs behind the scenes to separate the WAN and LAN ports.

> They're almost always relying on VLANs behind the scenes to separate the WAN and LAN ports. I don't believe this is true. I expect that what's going on there is the WAN and LAN ports on the switch [0] are in separate bridges. Why do you believe that they're using VLANs behind the scenes? It seems silly to add and remove a whole-ass VLAN tag to traffic based on what port it comes in on. Do you have switch chip or ot…

It's trivial to look up the switch port configuration of a consumer router once you put OpenWRT on it. The most common topology is the CPU has two RGMII/XGMII or similar links to an 8-port switch chip, five more ports of the switch are connected PHYs for external ports and configured for the LAN VLAN, and the last port is connected to a PHY for an external port and configured for the WAN VLAN. This does not result in any VLAN tags being emitted over the wire, but from the perspective of the switch silicon it's just one of many possible VLAN configurations. Changing which physical port is the WAN port is as simple as assigning a different switch port to that VLAN. If you did want VLAN tags emitted on a particular port, it's a single checkbox or single-character config file change.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#150

Post by TeMPOraL »

dijit wrote: post #48
tialaramex wrote: post #29

Earlier quoted context omitted.

The attacker doesn't need to be connected to the victim's network, only to the same hardware, the hardware's loss of isolation is the unexpected problem. Their University example is pertinent. The victim is an Eduroam user, and the attacker never has any Eduroam credentials, but the same WiFi hardware is serving both eduroam and the local guest provision which will be pretty bare bones, so the attacker uses the means…

I should reinforce this point by saying that it's the default position for "guest" networks to be using the same hardware as "secure" office wifi and such.

I'd further reinforce this by pointing out that this is what the specific term, guest network, means - it's the common name used by router manufacturers to describe an optional feature of serving secondary network from the same hardware, intended for the specific, common use case of serving transient and/or less trusted users.

This is in contrast to more genetic, descriptive terms like "additional network", "separate network for guests", etc.

Post reply on HN