Source Code Modification Help - No Clear Text User-Password logging
I am send this to the freeradius-devel list as I am asking for help on source code modification and felt this was more appropriate than freeradius-users list. If it is felt by many that I should re-submit under the users list I will be happy to do so. I do not have any C programming experience but have made small modifications and compiled tens of open source software programs. I am using freeradius for my company as 802.1x wireless authentication backend for our internal wifi network. We extensively use Kerberos (MIT) as an authentication mechanism and have configured TTLS/PAP on the client and rlm_krb5 to allow users to authenticate using their Kerberos principals and passwords. As a general practice we never ask what other users passwords are, never transmit passwords over the wire in clear text, and never log passwords on disk. I have found there are 2 ways to get the freeradius server to log clear text passwords and would like to ask for source code modification examples or at least pointers the right place to make them such that I can compile a custom version of the software that does not do this. We do want to be able ever to see our users passwords (1) log_auth_badpass|log_auth_goodpass I see there are 4 source files (radiusd.h auth.c mainconfig.c radiusd.c) that include references to log_auth_badpass and log_auth_goodpass. I figure that I can read the code and make any minor modifications that make sure these options can not be turned on. (2) radiusd -X When running in debug mode I can often see on the screen output like the below: [ttls] Got tunneled request User-Name = "gonzo" User-Password = "a_password" FreeRADIUS-Proxied-To = 127.0.0.1 [ttls] Sending tunneled request User-Name = "gonzo" User-Password = "a_password" FreeRADIUS-Proxied-To = 127.0.0.1 NAS-IP-Address = 10.0.1.218 NAS-Identifier = "AP-7eff00" NAS-Port = 0 Called-Station-Id = "AA-1E-72-7A-AA-00:radius" Calling-Station-Id = "A4-5A-AE-54-04-48" Framed-MTU = 1500 NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" I can not seem to figure out in the code how to make sure that the User-Password is never printed in the clear like it is above. Any pointers to where in the code I can turn this off would be greatly appreciated. Thanks!
On Mon, Jul 30, 2012 at 11:47 AM, Mark Selby <mselby@knewton.com> wrote:
We do want to be able ever to see our users passwords
(1) log_auth_badpass|log_auth_goodpass
(2) radiusd -X
Are you sure that would be effective? Anyone who can edit radiusd.conf or run "radiusd -X" usually have root password. It means, if they want to, they can: (1) replace your binary with another one (e.g. the one compiled from vanilla source code) (2) then can run tcpdump on the interface, which can show the attribute user-password as clear text if the user uses PAP (although this might be irrelevant to you since your debug log shows only ttls) (3) if you need to have user-password attribute in the first place, usually it's because whatever backend you use (e.g. db, LDAP) can only handle clear text password (e.g. because they store only encrypted passwords). Depending on what backend you use, It's possible that the admin can capture the traffic between FR and the backend to look at the clear-text user password. (4) Then can modify radiusd.conf (or whatever virtual server is active) to activate additional logging (to file, db, whatever) that could store the value of whatever attribute they choose (including User-Password). -- Fajar
Mark Selby wrote:
I do not have any C programming experience but have made small modifications and compiled tens of open source software programs.
That will make it more difficult.
As a general practice we never ask what other users passwords are, never transmit passwords over the wire in clear text, and never log passwords on disk.
That's nice. But it's often more useful to have them.
I have found there are 2 ways to get the freeradius server to log clear text passwords and would like to ask for source code modification examples or at least pointers the right place to make them such that I can compile a custom version of the software that does not do this. We do want to be able ever to see our users passwords
This is a hopeless goal. If you have the shared secrets, you have the users passwords. Modifying the source code makes that less obviously true, but it's still true.
(1) log_auth_badpass|log_auth_goodpass
I see there are 4 source files (radiusd.h auth.c mainconfig.c radiusd.c) that include references to log_auth_badpass and log_auth_goodpass. I figure that I can read the code and make any minor modifications that make sure these options can not be turned on.
Or just never enable them. Why modify the source?
(2) radiusd -X
When running in debug mode I can often see on the screen output like the below:
Yes. It prints out the attributes it receives.
I can not seem to figure out in the code how to make sure that the User-Password is never printed in the clear like it is above. Any pointers to where in the code I can turn this off would be greatly appreciated.
See src/lib/radius.c. It prints out ALL of the attributes it receives. There is NOTHING magic about User-Password. Alan DeKok.
Hi, the server does what it does because you have asked it to - ie it will log the password because you have asked it to - that is why there is a 'suppress' feature in the detail module, for example, so it is NOT logged. the server will print out everything it knows in full debug mode - because it is full debug mode. if the packet is PAP (as your logs show) then the password is passed in the clear within that tunnel...and so is shown. why? for debugging..... many many times the users list if filled with 'it doesnt work' and the password isnt what they are trying to use in the client (they are usually editing the wrong file) or its mangled - incorrect shared secret. if you want to make a local modification so that your server doesnt print this out, then simply look for the sections where this code is printed and print XXXXXXX instead.... but then expect many headaches when trying to diagnose issues - and as others have said, wtrong place to be paranoid...if someone has that level of access in the server then they can do anything - and be very aware of the day when someone helpfully updates your source code and blows away that local change. better to ensure the CONFIG is correct to stop the logging of passwords etc...and worry about server access security instead. alan
participants (4)
-
alan buxey -
Alan DeKok -
Fajar A. Nugraha -
Mark Selby