Security issue - WiFi authentication logging a fake username

Alan DeKok aland at deployingradius.com
Thu May 20 18:19:56 CEST 2021


> On May 20, 2021, at 12:03 PM, Roberto Franceschetti <roberto at logsat.com> wrote:
> 
> I had tried to use this in the post-Auth of the inner-tunnel:
> 
> 	update outer.reply {
> 		User-Name = "%{request:User-Name}"
> 	}
> 
> But it doesn't help. That User-Name gets re-updated with the anonymous identity later on during the exchange with the AAA client.

  This has been documented in sites-available/default and sites-available/inner-tunnel since 3.0.19, in 2018.

  i.e. this EXACT scenario has been documented for many years.

> Setting "use_tunneled_reply = yes" in the peap section of the eap.conf helps a bit as the user name is now the correct one in the Access-Accept, but in the syslog and in the database the account being logged is still the anonymous one.

  Then your NAS is broken.

  https://datatracker.ietf.org/doc/html/rfc2865#section-5.1

      It MAY be sent in an Access-Accept packet, in which case the
      client SHOULD use the name returned in the Access-Accept packet in
      all Accounting-Request packets for this session.  If the Access-
      Accept includes Service-Type = Rlogin and the User-Name attribute,
      a NAS MAY use the returned User-Name when performing the Rlogin
      function.

  This is not just a "SHOULD".  It's what all sane NAS equipment does, for precisely the situation you're running into.

> In any case, making changes like these to the config files would only resolve the issue in *my* specific scenario. They change how freeradius is configured and may not apply for everyone. This is not an ideal solution.

  Which is why this behavior has been documented since 2018.  And the default configuration has contained examples, and instructions, for how to fix this exact scenario.

  So this entire issue could have been resolved by (a) reading the documentation / examples which come with the server, and (b) your NAS wasn't broken.

> The only solution I can think of, which can be applied without impact to existing users as there are no configuration changes involved, is for freeradius to start logging/auditing all the relevant information used during the authentication process. Both inner and outer identities need to be logged, along with the certificate details if those are used to authenticate. I really don't understand why some developers are bashing me saying it's my fault if the system is misconfigured when it is the software should be responsible for logging authentication information. Arguing is useless at this point. 

  You don't understand the issues after they have been explained to you repeatedly.  This is a problem we cannot solve.

> Just as I did in the other post, for the admins who share my concerns (thank you all for the emails), I'll update the thread when (and if) we come up with the changes necessary to log both inner and outer identities, making the change applicable to everyone without altering their "running" configurations (except for the database schema).

  Don't waste your time.  This was solved years ago.  And documented.

  Everyone else manages to read the documentation and follow it's instructions without engaging in hysterics.  Learn how to behave properly.

  Alan DeKok.




More information about the Freeradius-Users mailing list