Security issue - WiFi authentication logging a fake username

[Alan DeKok]

On May 18, 2021, at 10:47 PM, Roberto Franceschetti <roberto at logsat.com> wrote:
> First - AWARENESS. Admins need to be made aware that the information in syslog and in the radacct table can easily be faked - the usernames you see being logged are NOT necessarily the real usernames used to authenticate in your environments. You cannot rely on that data alone during audits/reports/investigations.

  This was explained very slowly to you last time.  It's (a) RADIUS, and (b) how you set up your system.

> Second - for the freeradius developers. freeradius is a very valid product that offers a lot of flexibility, but it's seriously lacking in auditing. I'm not disputing the RFCs that allow for inner/outer identities, and the fact that freeradius can be configured to require them to be the same. But you as as developers don't get to tell sysadmins "you should require them to be the same and if you don't it's your fault".

  We do get to do that.  If you don't like it, then start your own RADIUS server project, and deal with entitled people who believe that they can order you around.  It's not pleasant.

> The RFCs allow for that, and if business requirements allow them to be different freeradius needs to deal with it. Basic security practices require applications to log and record the account used to authenticate. freeradius is NOT doing that. Freeradius must, out-of-the-box, log and audit all parameters used to login, meaning it needs to capture and log *both* the inner and outer identities, along with the certificate details if certs are used to login. Just like we did with the lack of logging for certificates in the other post, I'm sure we'll be able to address and fix this issue as well. But this (not logging the correct authenticating username) should have never been allowed to happen. You can't have a product that is used to authenticate a variety of devices NOT log the login information unless admins make complex changes to database schema and get creative with config files in order to log and audit basic authentication data that should be logged by default.

  As we said last time, please suggest improvements.  The caveat is that these improvements must work for everyone, and must not cause problems for anyone.

  FreeRADIUS works in a wide variety of environments, including systems which don't use EAP-TLS.  FreeRADIUS uses a particular schema, and upgrading that schema is hard.

  You keep posting the same messages, trying to describe what's going on in more and more detail.  This shows that you're not learning.  We've already agreed as to everything in your scenario.  Posting more and more strident messages about "THIS IS WRONG" just makes you look like you're not paying attention to anything we say.

  Since you want this fixed, I have a challenge for you.

1) stop posting descriptions of the problem.  It's wasting your time, and ours.

2) post a solution.

  No, I don't mean a solution which *works for you*.  No, I don't mean a solution *which works just on your system*.

  Post a solution which won't severely affect ISPs.

  Explain what the upgrade path is for people who have existing databases, with existing schemas.  Explain how the new queries / schemas work with existing databases.

  Go ahead.  Do that.

  Because if you keep complaining that the server is broken, it won't end positively.  We've been down that path, and it's not productive.  You showed that you were unable or unwilling to understand issues outside of your local environment.  So I'm giving you one last opportunity to do some good work.

  The problem here is that you're asking *us* to do all of that work.  The work you're doing is to wave your hands frantically, and loudly shout "OMFG IT'S BROKEN".  But you're doing precisely *zero* to fix it.  You're demanding that we work for you, for free, because you want us to do something.  Worse, you don't understand our answers as to why the fix is either not appropriate, or difficult.

  So go do the work.  Come up with a solution, and explain what it is.  Convince us that there is a fix, and that it works, and that it can be implemented in the default configuration, without breaking existing systems.

  Your choices here are:

1) post a fix as I suggest

2) drop the subject entirely

  You can continue asking questions about anything else, but this subject is no long appropriate for the list.  It's been beaten to death, and you need to contribute instead of complaining (and not paying attention to our answers)

  Pick one of those positive paths forward.  Any other choice won't end well.

  Alan DeKok.