The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Martin Pauly <pauly AT hrz.uni-marburg.de>]

Hi,

Am 11.05.21 um 19:15 schrieb Stefan Paetow:
> >         IMO, the "Do not validate" setting has proven THE most dangerous 
> > thing in eduroam.
> Undoubtedly. As is technically the server cert pinning that iOS uses if 
you do not use geteduroam or an MDM profile (as issued by eduroam CAT).

really for iOS? In all Apple supplicant history I have seen so far, they 
always tried the TOFU approach (as does Windows),
i.e. at setup time, ask the user. If there is no user reaction, nothing will 
happen.
This is far from perfect, but WAYS better than what so many Androids do:
Whenever they see a known SSID, they do not bother to check _anything_ and 
actively push their credentials to the server,
be it a real or a fake one. So with TOFU, you have a short vulnerable period 
each time you set up a device -- which you
have to do more often than intended because only the server cert itself is 
pinned, _not_ the long-lived root cert.
With said Android you're _always_ vulnerable, typical mobile devices never 
turn off WiFi.

Apple, OTOH used to have a similar problem but, "achieved" it in a different 
way. It was the EAP-Success issue or CVE-2019-6203
that plagued Apple devices until April 2019 and finally gave rise to the -s 
flag in hostapd-wpe:
https://sensepost.com/blog/2019/understanding-peap-in-depth/#vuln

In 2020, we did an empirical investigation into that matter. We worked with 
our legal department
(big THX to them!) to create a legal basis for an Evil Twin attack on our 
own users (and, inevitably, on visitors).
The Rogue AP was as simple as can be: Kali Linux + hostapd-wpe + self-signed 
cert (timestamp recent, though)
The result was pretty much what we had guessed: Of 800 WiFi devices around, 
25% happily connected to the
Rogue AP. Almost all 200 vulnerable devices delivered MS-CHAPv2 credentials. 
The vast majority of these was Android as expected.
A much smaller proportion were Apple; we attribute them to said EAP-Success 
issue which may not have been patched on some devices.

A less expected result was: Of the devices using an anonymous outer ID, very 
few were vulnerable.
There was not a single one of our own clients, but a few from neighbouring 
universities which seemingly used very old configurations.
Conclusion: Forcing your clients to use an anonymous outer ID will protect 
you from this trivial attack almost completely!
NB: Most of this could be avoided by methods like EAP-TLS in the first place, 
but this is future work for most of us.
The vulnerability has been present all the way from the start of eduroam 
until _now_.
And: EAP-PWD won't help either as the users have to configure it, just as 
cert checking.
I promise to give a sensible write-up of the results some time this year.
Sorry, the focus shift and additional work introduced by Covid hampered us to 
the point
that we were hardly able to conduct the research at all.

The need to require an anonymous outer ID brings us back to that big Korean 
manufacturer ...
> >         in most Samsung devices (with the notable exception of the Galaxy 
> > S21).
> Is it possible that the S21 has already received a fix for this issue? I have a Samsung device here that did display the problem 
> when I upgraded to Android 11. I'll power it up and check whether it's getting any updates.
I should be more precise here: Our specimen of a Galaxy S21 which is the 
German/Germany version of
this model, did not exhibit the "Samsung Bug". It just worked.

Regards, Martin

--
  Dr. Martin Pauly     Phone:  +49-6421-28-23527
  HRZ Univ. Marburg    Fax:    +49-6421-28-26994
  Hans-Meerwein-Str.   E-Mail: pauly AT HRZ.Uni-Marburg.DE
  D-35032 Marburg

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature