Sometimes passwords are coming in with junk
Hi! We are getting close to a workable solution with freeradius! When running freeradius in debug mode we can see that sometimes it comes in correctly, and other times in some kind of junky value. We need some help to see if this is an encrypt/decrypt issue, and where we may be able to align things to have 100% success rate with password traversing. some interesting things. When we login and get a =failed, we can generally get a success the 2nd time when trying again right away. here is some of the data pulled from debug. both times password was 000000 rad_recv: Access-Request packet from host 67.168.xxx.6 port 44529, id=58, length=173 User-Name = "freetest01" Acct-Session-Id = "1848a37b" NAS-Identifier = "712-xxxxxx" Framed-IP-Address = 10.255.10.51 NAS-Port-Id = "ssid1_1848a37b" Calling-Station-Id = "2C-6E-85-95-C1-C6" Called-Station-Id = "AC-86-74-7A-35-10" Class = 0x47726f75703d33362c5376633d3531 Event-Timestamp = "Nov 1 2018 08:37:03 UTC" Service-Type = Login-User User-Password = "`\033\244\361\310\337H" NAS-Port = 35 NAS-IP-Address = 192.168.1.128 # Executing section authorize from file /etc/freeradius/sites-enabled/xxxxxx.rad then rad_recv: Access-Request packet from host 67.168.xxx.6 port 57254, id=178, length=173 User-Name = "freetest01" Acct-Session-Id = "3b6dcf1b" NAS-Identifier = "712-xxxxxx" Framed-IP-Address = 10.255.10.51 NAS-Port-Id = "ssid1_3b6dcf1b" Calling-Station-Id = "2C-6E-85-95-C1-C6" Called-Station-Id = "AC-86-74-7A-35-10" Class = 0x47726f75703d33362c5376633d3531 Event-Timestamp = "Nov 1 2018 08:32:55 UTC" Service-Type = Login-User User-Password = "000000" NAS-Port = 35 NAS-IP-Address = 192.168.1.128
On Nov 7, 2018, at 4:47 PM, Sam T <givemesam@gmail.com> wrote:
Hi!
We are getting close to a workable solution with freeradius!
When running freeradius in debug mode we can see that sometimes it comes in correctly, and other times in some kind of junky value.
The shared secret is wrong. If your NAS supports Message-Authenticator, enable it and FreeRADIUS will tell you that the shared secret is wrong. -Arran
On Nov 9, 2018, at 12:58 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Nov 7, 2018, at 4:47 PM, Sam T <givemesam@gmail.com> wrote:
Hi!
We are getting close to a workable solution with freeradius!
When running freeradius in debug mode we can see that sometimes it comes in correctly, and other times in some kind of junky value.
The shared secret is wrong. If your NAS supports Message-Authenticator, enable it and FreeRADIUS will tell you that the shared secret is wrong.
The other things it could be are an intermediary proxy, not decrypting/re-encrypting the password value correctly. Bytes being overwritten in the message authenticator. Bytes being overwritten in the User-Password attributes. Packets coming from different source IPs (with different shared secrets). Uninitialised memory in the RADIUS client screwing up the encryption, etc.. Use radsniff with captured packets and pass -s to verify it's not a client lookup issue. Send packets directly if you're using a proxy. Verify PCAPs on the NAS and RADIUS server have the same content. -Arran
Thanks so much for the commentary on this! We found it! It looked a lot like changing shared secrets, but we found that there was some kind of timer on the NAS that would change the decryption every X min to prevent brute force, making the browser or intermediary breaking the decrypt/encrypt sync if you dont log in fast enough, it was very low. (1 min), after a fail, it would then refresh it, and it would accept. We moved that time up to 100 min and you are right, Free radius does it right, every time! For the WWW, 'failed authentication block' is what it was called, and set it to something above 10 min so users can get logged in before their decryption changes. the documentation we had did not say that was the way it handled brute force prevention, and im not sure it is even a good way of doing brute force prevention as it is still sending the junked password up to radius. We did some pcap'ing yesterday, and also looked at what the NAS was sending up and out the bad info vs blocking it as to what that setting leads us to beleive, and saw the scramble was originating locally. THANK YOU! On Fri, Nov 9, 2018 at 10:05 AM Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
On Nov 9, 2018, at 12:58 PM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
On Nov 7, 2018, at 4:47 PM, Sam T <givemesam@gmail.com> wrote:
Hi!
We are getting close to a workable solution with freeradius!
When running freeradius in debug mode we can see that sometimes it comes in correctly, and other times in some kind of junky value.
The shared secret is wrong. If your NAS supports Message-Authenticator, enable it and FreeRADIUS will tell you that the shared secret is wrong.
The other things it could be are an intermediary proxy, not decrypting/re-encrypting the password value correctly.
Bytes being overwritten in the message authenticator. Bytes being overwritten in the User-Password attributes.
Packets coming from different source IPs (with different shared secrets).
Uninitialised memory in the RADIUS client screwing up the encryption, etc..
Use radsniff with captured packets and pass -s to verify it's not a client lookup issue.
Send packets directly if you're using a proxy.
Verify PCAPs on the NAS and RADIUS server have the same content.
-Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Nov 7, 2018, at 4:47 PM, Sam T <givemesam@gmail.com> wrote:
When running freeradius in debug mode we can see that sometimes it comes in correctly, and other times in some kind of junky value.
Blame the NAS.
We need some help to see if this is an encrypt/decrypt issue, and where we may be able to align things to have 100% success rate with password traversing.
FreeRADIUS decodes the passwords correctly 100% of the time.
some interesting things. When we login and get a =failed, we can generally get a success the 2nd time when trying again right away.
Then the NAS is broken. Throw it in the garbage and buy one that works. The NAS *must* correctly encode the password 100% of the time. Alan DeKok.
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Sam T