Security issue - WiFi authentication logging a fake username
Roberto Franceschetti
roberto at logsat.com
Thu May 20 18:03:08 CEST 2021
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 at 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 at 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
More information about the Freeradius-Users
mailing list