Security issue - WiFi authentication logging a fake username
Alan Buxey
alan.buxey at gmail.com
Wed May 19 23:32:46 CEST 2021
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
More information about the Freeradius-Users
mailing list