Security issue - WiFi authentication logging a fake username

[Roberto Franceschetti]

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