Discussion:
Sometimes passwords are coming in with junk
Sam T
2018-11-07 21:47:49 UTC
Permalink
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
-
List info/subscribe/unsubscribe? See http://www.freerad
Arran Cudbard-Bell
2018-11-09 17:58:52 UTC
Permalink
Post by Sam T
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.ht
Arran Cudbard-Bell
2018-11-09 18:04:03 UTC
Permalink
Post by Arran Cudbard-Bell
Post by Sam T
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/u
Sam T
2018-11-10 00:09:20 UTC
Permalink
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 <
Post by Sam T
On Nov 9, 2018, at 12:58 PM, Arran Cudbard-Bell <
Post by Sam T
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
Post by Sam T
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
-
List info/subscribe/unsubscribe? See

Alan DeKok
2018-11-09 18:00:19 UTC
Permalink
Post by Sam T
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.
Post by Sam T
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.
Post by Sam T
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.

-
List info/subscribe/unsubscribe? See http://www.freeradius
Continue reading on narkive:
Loading...