On 11 September 2024 18:22:51 BST, Martin Pauly <pa...@hrz.uni-marburg.de> wrote: >Am 11.09.24 um 05:29 schrieb Daniel Lenski: >> But as an end user of eduroam, why should I actually be concerned if >> I've connected to a "counterfeit" eduroam access point, as long as it >> gives me real internet connectivity? The eduroam network doesn't >> really give me access to any particular internal network. There isn't >> really a trust boundary with eduroam. > >It all depends, e.g. on the network segmentation of the institution at hand. >The 802.1X "Evil Twin" situation has been really bad due to a combination >of circumstances: >1. SSID is the same everywhere around the world (sounds trivial, but makes >attacks even more effective) >2. Unlike HTTPS, IMAPS etc., here is no DNS step involved when the end device >makes > first contact with the local RADIUS server. It just starts EAP over LAN/WLAN > negotiations; the EAP messages carry the TLS stuff. The wireless > infrastructure forwards these > as EAP over RADIUS to their local RADIUS server which acts as SSL server > side, presenting its certificate. > So at least the client MUST talk to anyone claiming to be "eduroam" from > the start, including a rogue AP. >3. This will do no harm, IF the supplicant (client) checks the cert of the >peer, Server Name + CA is sufficient. > Both SHOULD be configured with the supplicant beforehand. If not, you will > get a "Trust this server?" question > on Windows and most Apple devices. >4. If the client skips cert validation, it will hand its password to whatever >RADIUS server it is talking to.
You skipped over an important detail there without calling it out explicitly: We choose EAP methods which involve handing our password in plain text (even if over EAP-(T)TLS) to the server we happen to be talking to. I feel that warrants more attention. > Turns out, this had been the case with ~90% of Androids in 2008, and ~30% > of Androids in 2020. > Due to the EAP-Success Bug of 2018, some iOS devices where also affected in > 2020, but only a small fraction. > >Why have Android supplicants been that ignorant? >First, users won't notice a difference, the gullible device connects to both >correct and rogue eduroam WiFis. >Second, the CA and Server name settings for a particular SSID seemed to slip >away at least with every update. >Also, a change to settings of some _different_ SSID could cause a silent reset >to CA = Do not validate. >Third, the fallback to connect anyway is _much_ more dangerous than the "Trust >on first use" approach >of other manufacturers. Phones are "always on", longing for a known SSID to >send their password to. > >All this adds up to a toxic mix and makes the attack trivial. >The real damage that comes out of this largely depends on what the attacker >can do with a stolen >eduroam password. If it gives the attacker access to e.g. the home >institution's VPN (which has been the case with >a great many institutions), the fun starts right away, as presumably happened >to us. >OTOH, in the rare case of client-side certs (EAP-TLS), the credential won't >leave the client, >and a rogue AP can hijack a single session at best. > >As to the current state of affairs, I can only guess. While we could watch >CA="Do not validate" >from most clients during 2020 because Google had removed it from AOSP, some >manufacturers would happily patch in >their old codebase, and there it was again e.g. in Motorola phones. >I can send a detailed report to anyone interested. Interestingly, there are >effective countermeasures >even if you use passwords with BYOD devices. > >Cheers, Martin > > _______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
