On Oct 6, 2021, at 11:55 AM, Gabriele Bellicini <g.bellicini003@studenti.unibs.it> wrote:
I’m writing here because of a problem I’m having trying to do a specific thing with FreeRADIUS 3.0.17.
That's years out of date. I'd suggest upgreading/
For a university project, I need to setup a malicious access point that lets everyone connect to its Wi-Fi network in order to perform some traffic analysis.
Previously, using FreeRADIUS v2.2.8 I managed to do this by simply putting
update control {
Auth-Type := Accept
}
in the authorize section of the inner-tunnel. Everything worked fine and I could connect to the Wi-Fi network using any combination of username, password and authentication method (PEAP/TTLS for phase 1 and any other method in phase 2).
It could work for TTLS + PAP. It didn't work for PEAP.
Recently, however, I had to switch to a Raspberry Pi 3B+ to use as access point. Here I downloaded the 3.0.17 version, which is the only one available through apt-get.
It *is* possible to download newer versions. There's a whole web site and everything with source.
Configuring v3.0.17 in the same way I did with v.2.2.8, however, I get really weird results. Basically, using iOS (14, but I don’t think it’s a matter of version) I can still connect to the same Wi-Fi using any username and password.
If you read the debug output, you'll see it's doing TTLS + PAP.
If I use Android, instead, I can’t connect even using the correct password. A subportion of the logs I get from running in debug mode is this one:
(8) eap_peap: Session established. Decoding tunneled attributes (8) eap_peap: PEAP state send tlv success (8) eap_peap: Received EAP-TLV response (8) eap_peap: Client rejected our response. The password is probably incorrect
Exactly.
The log in its entirety is attached at the end of this post.
So FreeRADIUS sends an Access Accept, but the mobile phone rejects it.
As it should. Because PEAP does MS-CHAPv2 in the inner tunnel. And MS-CHAPv2 authenticates *both* the end user, and the server. If the server doesn't have the correct password, then it can't calculate the correct MS-CHAPv2 data. And the end user system refuses to connect.
Again, this only happens with Android smartphones, not with iPhones. The method I use, now only works for TTLS/PAP, not for PEAP or TTLS/MSCHAP.
Exactly.
Is there still a way to accomplish what I could do in v2.2.8 but in v.3.0.17? Did anybody notice a different behavior between iOS and Android smartphones?
No. "Auth-Type Accept" didn't work for PEAP in v2, either. This isn't a v2 versus v3 issue. PEAP / MS_CHAPv2 simply doesn't work that way, and hasn't worked that way since the beginning of PEAP. Alan DeKok.