Security issue - WiFi authentication logging a fake username
Imagine if the Windows CTRL-ALT-DEL login screen, in addition to the username/password fields, also had a field for you to enter an "ALIAS". You then login Windows with your username, but what gets logged in the Security event logs and/or Domain Controller was NOT your username, but the bogus name you entered for the Alias. Your login would be untraceable, and some security admins would go ballistic. This is exactly what is happening with freeradius. It's a scenario similar to what was reported in http://lists.freeradius.org/pipermail/freeradius-users/2021-March/099613.htm..., but worse. See this screenshot showing the WiFi settings on an Android phone (https://www.smugmug.com/gallery/n-vQJqzB). If the WiFi network supports PEAP, in addition to their login credentials users can enter an "Anonymous identity". Unbelievably, if someone does that, what gets logged by freeradius is NOT their login username used to authenticate, but the bogus "Anonymous identity" they entered. I can login via WiFi with my credentials, but enter the username of *another* employee in the "Anonymous identity". If I do this, the *other* employee's username will be logged in the radacct table, and in syslog there will be a "login ok" for the *other* user. I can then perform whatever nefarious acts I want, knowing that my FramedIPAddress will be logged in radacct in the record for the *other* user. The *other* user will thus be investigated and possibly be jailed as all logs will point to them, not me. This post is two-fold. 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. 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". 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. Now to the details. Below are these are the relevant entries you'll see with freeradius -X when authenticating with the settings as seen in the screenshot: #MAC address: of the wireless device is: 60-a1-0a-89-12-34 #Real Active Directory Username used to authenticate: roberto #Anonymous Identity in PEAP WiFi settings: HACKER rad_recv: Access-Request packet from host 10.252.59.26 port 43972, id=201, length=286 User-Name = "HACKER" ..................... [peap] EAPTLS_OK [peap] Session established. Decoding tunneled attributes. [peap] Peap state WAITING FOR INNER IDENTITY [peap] Identity - roberto [peap] Got inner identity 'roberto' [peap] Setting default EAP type for tunneled EAP session. [peap] Got tunneled request EAP-Message = 0x0208000c01726f626572746f server lwap-clients { [peap] Setting User-Name to roberto Sending tunneled request EAP-Message = 0x0208000c01726f626572746f FreeRADIUS-Proxied-To = 127.0.0.1 User-Name = "roberto" ..................... [mschap] Creating challenge hash with username: roberto [mschap] Client is using MS-CHAPv2 for roberto, we need NT-Password [mschap] expand: --username=%{mschap:User-Name:-None} -> --username=roberto ..................... Login OK: [roberto] (from client 10.252.59.26 port 0 via TLS tunnel) ..................... Sending Access-Challenge of id 210 to 10.252.59.26 port 43972 EAP-Message = 0x010b002b19001703010020e885af0d8fcdc4bd84c0f31439ad983a38ae207bf5faa41bd351a7c209434ab7 Message-Authenticator = 0x123456000000000000000000000000000 ..................... rad_recv: Access-Request packet from host 10.252.59.26 port 43972, id=211, length=373 User-Name = "HACKER" ..................... Login OK: [HACKER] (from client 10.252.59.26 port 8 cli 60-a1-0a-89-12-34) ..................... ++update reply { ++} # update reply = noop [sql] expand: %{Stripped-User-Name} -> [sql] ... expanding second conditional [sql] expand: %{User-Name} -> HACKER [sql] expand: %{%{User-Name}:-DEFAULT} -> HACKER [sql] expand: %{%{Stripped-User-Name}:-%{%{User-Name}:-DEFAULT}} -> HACKER [sql] sql_set_user escaped user --> 'HACKER' [sql] expand: INSERT INTO radpostauth (username, message, nasipaddress, reply, authdate, CallingStationid, TLS_Client_Cert_Common_Name, TLS_Client_Cert_Serial, TLS_Client_Cert_Issuer) VALUES ( '%{User-Name}', '%{Module-Failure-Message}', '%{NAS-IP-Address}', '%{reply:Packet-Type}', '%S', '%{Calling-Station-Id}', '%{TLS-Client-Cert-Common-Name}', '%{TLS-Client-Cert-Serial}', '%{TLS-Client-Cert-Issuer}') -> INSERT INTO radpostauth (username, message, nasipaddress, reply, authdate, CallingStationid, TLS_Client_Cert_Common_Name, TLS_Client_Cert_Serial, TLS_Client_Cert_Issuer) VALUES ( 'HACKER', '', '10.252.59.26', 'Access-Accept', '2021-05-14 11:47:45', '60-a1-0a-89-12-34', ..................... Sending Access-Accept of id 211 to 10.252.59.26 port 43972 MS-MPPE-Recv-Key = 0x233bb553a75bf91234567897259fa357c32c6e3ca4cd1e42166817f0f3ebe MS-MPPE-Send-Key = 0xf19b1d7b899c99c12345678987178c5c09d9b77fb729827550c8667a0d29a50 EAP-Message = 0x030b0004 Message-Authenticator = 0x12345600000000000000000000000000 User-Name = "HACKER" Reply-Message = "Welcome to LWAP Controllers" Finished request 278. ==================================================== FYI there is one single item that may be used to see that something is wrong if you're collecting syslogs. In addition to the entry showing the *other" username and the MAC address used to cross-reference and validate the radacct table: Login OK: [HACKER] (from client 10.252.59.26 port 8 cli 60-a1-0a-89-12-34) There will be a vague entry without any corresponding entry in the radacct table, and with no MAC address that can be used as a reference: Login OK: [roberto] (from client 10.252.59.26 port 0 via TLS tunnel) So if you either read this post or are a very thorough investigator and do not trust your radacct table (you shouldn't), you will see that at around the same time that HACKER logged in, there is also an event showing my real login used to login (but without any other useful information). That should prevent the victim I tried to blame from going to jail for reasonable doubt, but it will not prove that I am the true culprit. Roberto Franceschetti
On 19/05/2021 03:47, Roberto Franceschetti wrote:
Imagine if the Windows CTRL-ALT-DEL login screen, in addition to the username/password fields, also had a field for you to enter an "ALIAS". You then login Windows with your username, but what gets logged in the Security event logs and/or Domain Controller was NOT your username, but the bogus name you entered for the Alias. Your login would be untraceable, and some security admins would go ballistic.
This is exactly what is happening with freeradius. It's a scenario similar to what was reported in http://lists.freeradius.org/pipermail/freeradius-users/2021-March/099613.htm..., but worse.
Yes, and not even two months ago, in that exact thread, we told you to properly configure and test your system before going into production. I'm not going to waste my time doing the same again. -- Matthew
On May 18, 2021, at 10:47 PM, Roberto Franceschetti <roberto@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.
1, if its your system, ensure you are logging in the inner-tunnel and not relying on outer tunnel 2, if you want to, use the outerid == innerid policy This has been the case since outerids existed alan On Wed, 19 May 2021, 03:47 Roberto Franceschetti, <roberto@logsat.com> wrote:
Imagine if the Windows CTRL-ALT-DEL login screen, in addition to the username/password fields, also had a field for you to enter an "ALIAS". You then login Windows with your username, but what gets logged in the Security event logs and/or Domain Controller was NOT your username, but the bogus name you entered for the Alias. Your login would be untraceable, and some security admins would go ballistic.
This is exactly what is happening with freeradius. It's a scenario similar to what was reported in http://lists.freeradius.org/pipermail/freeradius-users/2021-March/099613.htm..., but worse.
See this screenshot showing the WiFi settings on an Android phone ( https://www.smugmug.com/gallery/n-vQJqzB). If the WiFi network supports PEAP, in addition to their login credentials users can enter an "Anonymous identity". Unbelievably, if someone does that, what gets logged by freeradius is NOT their login username used to authenticate, but the bogus "Anonymous identity" they entered.
I can login via WiFi with my credentials, but enter the username of *another* employee in the "Anonymous identity". If I do this, the *other* employee's username will be logged in the radacct table, and in syslog there will be a "login ok" for the *other* user. I can then perform whatever nefarious acts I want, knowing that my FramedIPAddress will be logged in radacct in the record for the *other* user. The *other* user will thus be investigated and possibly be jailed as all logs will point to them, not me.
This post is two-fold.
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.
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". 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.
Now to the details.
Below are these are the relevant entries you'll see with freeradius -X when authenticating with the settings as seen in the screenshot: #MAC address: of the wireless device is: 60-a1-0a-89-12-34 #Real Active Directory Username used to authenticate: roberto #Anonymous Identity in PEAP WiFi settings: HACKER
rad_recv: Access-Request packet from host 10.252.59.26 port 43972, id=201, length=286 User-Name = "HACKER"
.....................
[peap] EAPTLS_OK [peap] Session established. Decoding tunneled attributes. [peap] Peap state WAITING FOR INNER IDENTITY [peap] Identity - roberto [peap] Got inner identity 'roberto' [peap] Setting default EAP type for tunneled EAP session. [peap] Got tunneled request EAP-Message = 0x0208000c01726f626572746f server lwap-clients { [peap] Setting User-Name to roberto Sending tunneled request EAP-Message = 0x0208000c01726f626572746f FreeRADIUS-Proxied-To = 127.0.0.1 User-Name = "roberto"
.....................
[mschap] Creating challenge hash with username: roberto [mschap] Client is using MS-CHAPv2 for roberto, we need NT-Password [mschap] expand: --username=%{mschap:User-Name:-None} -> --username=roberto
.....................
Login OK: [roberto] (from client 10.252.59.26 port 0 via TLS tunnel)
.....................
Sending Access-Challenge of id 210 to 10.252.59.26 port 43972 EAP-Message = 0x010b002b19001703010020e885af0d8fcdc4bd84c0f31439ad983a38ae207bf5faa41bd351a7c209434ab7
Message-Authenticator = 0x123456000000000000000000000000000
.....................
rad_recv: Access-Request packet from host 10.252.59.26 port 43972, id=211, length=373 User-Name = "HACKER"
.....................
Login OK: [HACKER] (from client 10.252.59.26 port 8 cli 60-a1-0a-89-12-34)
.....................
++update reply { ++} # update reply = noop [sql] expand: %{Stripped-User-Name} -> [sql] ... expanding second conditional [sql] expand: %{User-Name} -> HACKER [sql] expand: %{%{User-Name}:-DEFAULT} -> HACKER [sql] expand: %{%{Stripped-User-Name}:-%{%{User-Name}:-DEFAULT}} -> HACKER [sql] sql_set_user escaped user --> 'HACKER' [sql] expand: INSERT INTO radpostauth (username, message, nasipaddress, reply, authdate, CallingStationid, TLS_Client_Cert_Common_Name, TLS_Client_Cert_Serial, TLS_Client_Cert_Issuer) VALUES ( '%{User-Name}', '%{Module-Failure-Message}', '%{NAS-IP-Address}', '%{reply:Packet-Type}', '%S', '%{Calling-Station-Id}', '%{TLS-Client-Cert-Common-Name}', '%{TLS-Client-Cert-Serial}', '%{TLS-Client-Cert-Issuer}') -> INSERT INTO radpostauth (username, message, nasipaddress, reply, authdate, CallingStationid, TLS_Client_Cert_Common_Name, TLS_Client_Cert_Serial, TLS_Client_Cert_Issuer) VALUES ( 'HACKER', '', '10.252.59.26', 'Access-Accept', '2021-05-14 11:47:45', '60-a1-0a-89-12-34',
.....................
Sending Access-Accept of id 211 to 10.252.59.26 port 43972 MS-MPPE-Recv-Key = 0x233bb553a75bf91234567897259fa357c32c6e3ca4cd1e42166817f0f3ebe MS-MPPE-Send-Key = 0xf19b1d7b899c99c12345678987178c5c09d9b77fb729827550c8667a0d29a50 EAP-Message = 0x030b0004 Message-Authenticator = 0x12345600000000000000000000000000 User-Name = "HACKER" Reply-Message = "Welcome to LWAP Controllers" Finished request 278.
====================================================
FYI there is one single item that may be used to see that something is wrong if you're collecting syslogs. In addition to the entry showing the *other" username and the MAC address used to cross-reference and validate the radacct table: Login OK: [HACKER] (from client 10.252.59.26 port 8 cli 60-a1-0a-89-12-34)
There will be a vague entry without any corresponding entry in the radacct table, and with no MAC address that can be used as a reference: Login OK: [roberto] (from client 10.252.59.26 port 0 via TLS tunnel)
So if you either read this post or are a very thorough investigator and do not trust your radacct table (you shouldn't), you will see that at around the same time that HACKER logged in, there is also an event showing my real login used to login (but without any other useful information). That should prevent the victim I tried to blame from going to jail for reasonable doubt, but it will not prove that I am the true culprit.
Roberto Franceschetti
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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.
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.
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.
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.
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).
Roberto
> On May 19, 2021, at 5:32 PM, Alan Buxey <alan.buxey@gmail.com> wrote:
>
> 1, if its your system, ensure you are logging in the inner-tunnel and not
> relying on outer tunnel
>
> 2, if you want to, use the outerid == innerid policy
>
> This has been the case since outerids existed
>
> alan
>
> On Wed, 19 May 2021, 03:47 Roberto Franceschetti, <roberto@logsat.com>
> wrote:
>
>> Imagine if the Windows CTRL-ALT-DEL login screen, in addition to the
>> username/password fields, also had a field for you to enter an "ALIAS". You
>> then login Windows with your username, but what gets logged in the Security
>> event logs and/or Domain Controller was NOT your username, but the bogus
>> name you entered for the Alias. Your login would be untraceable, and some
>> security admins would go ballistic.
>>
>> This is exactly what is happening with freeradius. It's a scenario similar
>> to what was reported in
>> http://lists.freeradius.org/pipermail/freeradius-users/2021-March/099613.html,
>> but worse.
>>
>> See this screenshot showing the WiFi settings on an Android phone (
>> https://www.smugmug.com/gallery/n-vQJqzB). If the WiFi network supports
>> PEAP, in addition to their login credentials users can enter an "Anonymous
>> identity". Unbelievably, if someone does that, what gets logged by
>> freeradius is NOT their login username used to authenticate, but the bogus
>> "Anonymous identity" they entered.
>>
>> I can login via WiFi with my credentials, but enter the username of
>> *another* employee in the "Anonymous identity". If I do this, the *other*
>> employee's username will be logged in the radacct table, and in syslog
>> there will be a "login ok" for the *other* user. I can then perform
>> whatever nefarious acts I want, knowing that my FramedIPAddress will be
>> logged in radacct in the record for the *other* user. The *other* user will
>> thus be investigated and possibly be jailed as all logs will point to them,
>> not me.
>>
>> This post is two-fold.
>>
>> 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.
>>
>> 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". 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.
>>
>>
>> Now to the details.
>>
>> Below are these are the relevant entries you'll see with freeradius -X
>> when authenticating with the settings as seen in the screenshot:
>> #MAC address: of the wireless device is: 60-a1-0a-89-12-34
>> #Real Active Directory Username used to authenticate: roberto
>> #Anonymous Identity in PEAP WiFi settings: HACKER
>>
>>
>> rad_recv: Access-Request packet from host 10.252.59.26 port 43972,
>> id=201, length=286
>> User-Name = "HACKER"
>>
>> .....................
>>
>> [peap] EAPTLS_OK
>> [peap] Session established. Decoding tunneled attributes.
>> [peap] Peap state WAITING FOR INNER IDENTITY
>> [peap] Identity - roberto
>> [peap] Got inner identity 'roberto'
>> [peap] Setting default EAP type for tunneled EAP session.
>> [peap] Got tunneled request
>> EAP-Message = 0x0208000c01726f626572746f
>> server lwap-clients {
>> [peap] Setting User-Name to roberto
>> Sending tunneled request
>> EAP-Message = 0x0208000c01726f626572746f
>> FreeRADIUS-Proxied-To = 127.0.0.1
>> User-Name = "roberto"
>>
>> .....................
>>
>> [mschap] Creating challenge hash with username: roberto
>> [mschap] Client is using MS-CHAPv2 for roberto, we need
>> NT-Password
>> [mschap] expand: --username=%{mschap:User-Name:-None} ->
>> --username=roberto
>>
>> .....................
>>
>> Login OK: [roberto] (from client 10.252.59.26 port 0 via TLS
>> tunnel)
>>
>> .....................
>>
>> Sending Access-Challenge of id 210 to 10.252.59.26 port 43972
>> EAP-Message =
>> 0x010b002b19001703010020e885af0d8fcdc4bd84c0f31439ad983a38ae207bf5faa41bd351a7c209434ab7
>>
>> Message-Authenticator =
>> 0x123456000000000000000000000000000
>>
>> .....................
>>
>> rad_recv: Access-Request packet from host 10.252.59.26 port 43972,
>> id=211, length=373
>> User-Name = "HACKER"
>>
>> .....................
>>
>> Login OK: [HACKER] (from client 10.252.59.26 port 8 cli
>> 60-a1-0a-89-12-34)
>>
>> .....................
>>
>> ++update reply {
>> ++} # update reply = noop
>> [sql] expand: %{Stripped-User-Name} ->
>> [sql] ... expanding second conditional
>> [sql] expand: %{User-Name} -> HACKER
>> [sql] expand: %{%{User-Name}:-DEFAULT} -> HACKER
>> [sql] expand: %{%{Stripped-User-Name}:-%{%{User-Name}:-DEFAULT}}
>> -> HACKER
>> [sql] sql_set_user escaped user --> 'HACKER'
>> [sql] expand: INSERT INTO radpostauth (username, message,
>> nasipaddress, reply, authdate, CallingStationid,
>> TLS_Client_Cert_Common_Name, TLS_Client_Cert_Serial,
>> TLS_Client_Cert_Issuer) VALUES ( '%{User-Name}',
>> '%{Module-Failure-Message}', '%{NAS-IP-Address}', '%{reply:Packet-Type}',
>> '%S', '%{Calling-Station-Id}', '%{TLS-Client-Cert-Common-Name}',
>> '%{TLS-Client-Cert-Serial}', '%{TLS-Client-Cert-Issuer}') -> INSERT INTO
>> radpostauth (username, message, nasipaddress, reply, authdate,
>> CallingStationid, TLS_Client_Cert_Common_Name, TLS_Client_Cert_Serial,
>> TLS_Client_Cert_Issuer) VALUES ( 'HACKER', '', '10.252.59.26',
>> 'Access-Accept', '2021-05-14 11:47:45', '60-a1-0a-89-12-34',
>>
>> .....................
>>
>> Sending Access-Accept of id 211 to 10.252.59.26 port 43972
>> MS-MPPE-Recv-Key =
>> 0x233bb553a75bf91234567897259fa357c32c6e3ca4cd1e42166817f0f3ebe
>> MS-MPPE-Send-Key =
>> 0xf19b1d7b899c99c12345678987178c5c09d9b77fb729827550c8667a0d29a50
>> EAP-Message = 0x030b0004
>> Message-Authenticator = 0x12345600000000000000000000000000
>> User-Name = "HACKER"
>> Reply-Message = "Welcome to LWAP Controllers"
>> Finished request 278.
>>
>> ====================================================
>>
>>
>> FYI there is one single item that may be used to see that something is
>> wrong if you're collecting syslogs. In addition to the entry showing the
>> *other" username and the MAC address used to cross-reference and validate
>> the radacct table:
>> Login OK: [HACKER] (from client 10.252.59.26 port 8 cli 60-a1-0a-89-12-34)
>>
>> There will be a vague entry without any corresponding entry in the radacct
>> table, and with no MAC address that can be used as a reference:
>> Login OK: [roberto] (from client 10.252.59.26 port 0 via TLS tunnel)
>>
>> So if you either read this post or are a very thorough investigator and do
>> not trust your radacct table (you shouldn't), you will see that at around
>> the same time that HACKER logged in, there is also an event showing my real
>> login used to login (but without any other useful information). That should
>> prevent the victim I tried to blame from going to jail for reasonable
>> doubt, but it will not prove that I am the true culprit.
>>
>>
>>
>> Roberto Franceschetti
>>
>>
>>
>>
>>
>>
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 20, 2021, at 12:03 PM, Roberto Franceschetti <roberto@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.
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.
Now we're blaming Cisco in addition to blaming me. Great.
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.
You conveniently omitted the 1st two lines of that RFC that say: This Attribute indicates the name of the user to be authenticated. It MUST be sent in Access-Request packets if available. Notice the "MUST". You write RFCs... you know very well that a "SHOULD" is *not* a "MUST". So you can't say: This is not just a "SHOULD" because it is. It's a SHOULD. It's a recommendation, not a requirement. This is not me telling you, it's the RFC. But sure, keep on blaming Cisco and me instead of saying "well, maybe freeradius should log actual username and certificates used to authenticate afterall". ..and also, if you relaxed a bit without getting upset, you would have read that I reported the issue is not just in the accounting table, but also in the radpostauth and in syslog. In any case, for everyone else who, like the ignorant me, never realized that if you use WiFi to authenticate on a 802.1x network, there's an option to specify an anonymous identity which will make you invisible in the radius logs, it seems as if we're stuck having to use "use_tunneled_reply = yes" in the eap.conf. With that option, we can add this to the post-auth in the inner-tunnel: update reply { Inner-Tunnel-User-Name := "%{request:User-Name}" } With that, then in the dialup.conf and in the linelog modules we'll have access to %{reply:Inner-Tunnel-User-Name} value pair which we can use to log the inner username along with the outer one as it should have been done to begin with by freeradius. Roberto
On May 20, 2021, at 2:33 PM, Roberto Franceschetti <roberto@logsat.com> wrote:
Now we're blaming Cisco in addition to blaming me. Great.
Yes. I claim the right to have opinions. Your unstated assumption here is that your opinions matter, and mine don't. You don't think this is a problem. Everyone else does.
This is not just a "SHOULD". It's what all sane NAS equipment does, for precisely the situation you're running into.
You conveniently omitted the 1st two lines of that RFC that say: This Attribute indicates the name of the user to be authenticated. It MUST be sent in Access-Request packets if available.
Notice the "MUST". You write RFCs... you know very well that a "SHOULD" is *not* a "MUST". So you can't say: This is not just a "SHOULD"
because it is. It's a SHOULD. It's a recommendation, not a requirement. This is not me telling you, it's the RFC. But sure, keep on blaming Cisco and me instead of saying "well, maybe freeradius should log actual username and certificates used to authenticate afterall".
There's what the RFCs say, and then what's sane. Since you're aware that I write RFCs, you're also aware that I've written RFCs like RFC 5080, which fixes a number of issues in previous RFCs. The problem here is simple. You're trying to get your opinion across, and you don't really care what anyone else's opinion is. You want to force everyone else to do what you want, and you either don't understand the consequences, or don't care. The only way you get to dictate what goes into a RADIUS server is if you start your own. And then deal with entitled people like yourself who try to order you around.
..and also, if you relaxed a bit without getting upset, you would have read that I reported the issue is not just in the accounting table, but also in the radpostauth and in syslog.
If you stop trying to repeat the same thing over and over, you'd suggest a solution which works everywhere. I explained why this was hard. You've ignored that. Over and over and over again. This is a side effect of believing that your opinion matters, and that no one else's does.
In any case, for everyone else who, like the ignorant me, never realized that if you use WiFi to authenticate on a 802.1x network, there's an option to specify an anonymous identity which will make you invisible in the radius logs,
The server does *exactly* what you wanted to do here: have documentation and examples which explain the issue, and allow you to fix it with minimal fuss. Anyways. Since you're not prepared to understand my reasons, or respect my opinions, I'm declaring this conversation over. Any further discussion on this topic is not appropriate for this list. Alan DeKok.
participants (4)
-
Alan Buxey -
Alan DeKok -
Matthew Newton -
Roberto Franceschetti