Hi All, Hopefully a quick one, I am on FreeRADIUS v3.2.1 so have implemented the recommended steps into my server to mitigate BlastRADIUS attacks (however unlikely) by adding the below into my default and inner-tunnel servers: authorize { if (!EAP-Message) { update reply { Message-Authenticator := 0x00 } } ... Since I am using EAPTTLS/PAP, surely I am not susceptible to BlastRADIUS since the PAP traffic is within a TLS tunnel? Or have I misunderstood? The RADIUS also only communicates locally so not over the internet. Furthermore after implementing the aforementioned change, nothing seems to have changed in the debug log. Should I see a difference between the debugs before implementing this change and after? Kind regards, Connor
On Sep 17, 2024, at 6:45 AM, Connor Herring <connorrjherring@gmail.com> wrote:
Hopefully a quick one, I am on FreeRADIUS v3.2.1 so have implemented the recommended steps into my server to mitigate BlastRADIUS attacks (however unlikely) by adding the below into my default and inner-tunnel servers:
You don't need it in the inner-tunnel virtual server
Since I am using EAPTTLS/PAP, surely I am not susceptible to BlastRADIUS since the PAP traffic is within a TLS tunnel?
EAP isn't vulnerable. If you're only doing EAP, you're OK. But it's still good practice to add Message-Authenticator to *all* Access-Accept / Reject / Challenge.
Furthermore after implementing the aforementioned change, nothing seems to have changed in the debug log. Should I see a difference between the debugs before implementing this change and after?
You should be able to see the new policy being run in debug mode. Alan DeKok.
Hi Alan, Thank you for confirming. Apologies I can see the new policy being run, I just can't see anything having changed in the body of the debug. Kind regards, Connor On Tue, Sep 17, 2024 at 1:00 PM Alan DeKok <aland@deployingradius.com> wrote:
On Sep 17, 2024, at 6:45 AM, Connor Herring <connorrjherring@gmail.com> wrote:
Hopefully a quick one, I am on FreeRADIUS v3.2.1 so have implemented the recommended steps into my server to mitigate BlastRADIUS attacks (however unlikely) by adding the below into my default and inner-tunnel servers:
You don't need it in the inner-tunnel virtual server
Since I am using EAPTTLS/PAP, surely I am not susceptible to BlastRADIUS since the PAP traffic is within a TLS tunnel?
EAP isn't vulnerable. If you're only doing EAP, you're OK.
But it's still good practice to add Message-Authenticator to *all* Access-Accept / Reject / Challenge.
Furthermore after implementing the aforementioned change, nothing seems to have changed in the debug log. Should I see a difference between the debugs before implementing this change and after?
You should be able to see the new policy being run in debug mode.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan DeKok <aland@deployingradius.com> writes:
But it's still good practice to add Message-Authenticator to *all* Access-Accept / Reject / Challenge.
Yes. Or that's what I thought as well until yesterday. Unsurprisingly, many router vendors are still trying to implement the BlastRADIUS recommendations in their RADIUS clients. With "interesting" effects as a result. I got a complaint yesterday that vendor A now requires M-A in the Accept-Accept, or the session is rejected. I guess that's good. We were running 3.2.2 on the servers in question. An upgrade was obviously long overdue in any case, so I upgraded to 3.2.6. And everything was fine. For several minutes. Then it turned out that vendor C also must have been working on their BlastRADIUS implementation. Unfortunately, it seems that they only got as far as to make the authentication process crash if the Access-Accept includes M-A. Nice work! How are we supposed to handle real world vendors like that? It would be nice to have some fine grained M-A enable/disable knobs. E.g. by client or account (virtual internal attribute?). By client will not work well for proxied requests, so that's probably not sufficient. Will of course also work with the vendor, but that takes time. And we have a number of routers to upgrade before it's done. Testing is a bit of a hassle when we have to switch FR versions to enable/disable M-A (unless we cheat with a proxy filter). Bjørn
On Sep 19, 2024, at 4:21 AM, Bjørn Mork via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Unsurprisingly, many router vendors are still trying to implement the BlastRADIUS recommendations in their RADIUS clients. With "interesting" effects as a result.
Vendors are "special". There was one I found which would discard packets which contained Message-Authenticator. Why? "It's unexpected". <sigh>
I got a complaint yesterday that vendor A now requires M-A in the Accept-Accept, or the session is rejected. I guess that's good. We were running 3.2.2 on the servers in question. An upgrade was obviously long overdue in any case, so I upgraded to 3.2.6. And everything was fine. For several minutes.
Then it turned out that vendor C also must have been working on their BlastRADIUS implementation. Unfortunately, it seems that they only got as far as to make the authentication process crash if the Access-Accept includes M-A. Nice work!
:(
How are we supposed to handle real world vendors like that? It would be nice to have some fine grained M-A enable/disable knobs. E.g. by client or account (virtual internal attribute?). By client will not work well for proxied requests, so that's probably not sufficient.
Vendors should just fix their products. It's not hard. Message-Authenticator has been defined for 20+ years. It's not rocket surgery.
Will of course also work with the vendor, but that takes time. And we have a number of routers to upgrade before it's done. Testing is a bit of a hassle when we have to switch FR versions to enable/disable M-A (unless we cheat with a proxy filter).
Arg. I _really_ don't want to add more configuration flags to work around broken vendor equipment. That kind of nonsense tends to hang around for decades, because vendors go "well, there's a flag to work around it, so we don't have to fix our products!" I'll see if there's a good solution, but I suspect not. If vendors could ship products which aren't garbage, that would be great... Alan DeKok.
Alan DeKok <aland@deployingradius.com> writes:
On Sep 19, 2024, at 4:21 AM, Bjørn Mork via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Then it turned out that vendor C also must have been working on their BlastRADIUS implementation. Unfortunately, it seems that they only got as far as to make the authentication process crash if the Access-Accept includes M-A. Nice work!
:(
Apologies. I didn't have my facts right. The software running on these routers is older than BlastRADIUS. The bug is actually a couple of years old. It was only recently discovered after RADIUS servers implemented the BlastRADIUS fixes. And we were not the first ones to notice (which would have been a surprise). For those looking, the bug is identified as CSCwk90054 by vendor C, titled "SSH process crashes during log in process using Radius" The description says "This issue has been reported after upgrading Microsoft Server 2022 (acting as Radius Server) to OS Build 20348.2582 - KB5040437. This upgrade was released on July 9, 2024" And with the risk of assuming to much again - I don't think that release date is a coincidence.
Will of course also work with the vendor, but that takes time. And we have a number of routers to upgrade before it's done. Testing is a bit of a hassle when we have to switch FR versions to enable/disable M-A (unless we cheat with a proxy filter).
Arg.
I _really_ don't want to add more configuration flags to work around broken vendor equipment. That kind of nonsense tends to hang around for decades, because vendors go "well, there's a flag to work around it, so we don't have to fix our products!"
I'll see if there's a good solution, but I suspect not. If vendors could ship products which aren't garbage, that would be great...
Yes, thinking more about this I realise that you are right. We are much better off without such knobs. It was a bad idea. Please don't waste any time on it. Bjørn
Hello, It seems that since version 3.2.6, Freeradius always sends the Message-Authenticator AVP, as discussed in the thread below (I did search the conference, but did not find anything more relevant). I have upgraded the freeradius version on the server this weekend, and I have number of customer complaints whose obsolete BRASes fail to process replies containing the M-A AVP. Hence, I would need to selectively remove them from the replies - I tried to do it via the update-reply in the post-auth section of the configuration update reply { Message-Authenticator !* ANY } , but examining the packets via radsniff, the replies still do contain the M-A AVP. Could you please kindly advise on how to best remove the M-A attribute via the server configuration? Thank you very much in advance. -- Regards, Daniel Ryšlink Dne 19-Sep-24 v 13:27 Alan DeKok napsal(a):
On Sep 19, 2024, at 4:21 AM, Bjørn Mork via Freeradius-Users<freeradius-users@lists.freeradius.org> wrote:
Unsurprisingly, many router vendors are still trying to implement the BlastRADIUS recommendations in their RADIUS clients. With "interesting" effects as a result. Vendors are "special". There was one I found which would discard packets which contained Message-Authenticator.
Why? "It's unexpected". <sigh>
I got a complaint yesterday that vendor A now requires M-A in the Accept-Accept, or the session is rejected. I guess that's good. We were running 3.2.2 on the servers in question. An upgrade was obviously long overdue in any case, so I upgraded to 3.2.6. And everything was fine. For several minutes.
Then it turned out that vendor C also must have been working on their BlastRADIUS implementation. Unfortunately, it seems that they only got as far as to make the authentication process crash if the Access-Accept includes M-A. Nice work! :(
How are we supposed to handle real world vendors like that? It would be nice to have some fine grained M-A enable/disable knobs. E.g. by client or account (virtual internal attribute?). By client will not work well for proxied requests, so that's probably not sufficient. Vendors should just fix their products. It's not hard. Message-Authenticator has been defined for 20+ years. It's not rocket surgery.
Will of course also work with the vendor, but that takes time. And we have a number of routers to upgrade before it's done. Testing is a bit of a hassle when we have to switch FR versions to enable/disable M-A (unless we cheat with a proxy filter). Arg.
I _really_ don't want to add more configuration flags to work around broken vendor equipment. That kind of nonsense tends to hang around for decades, because vendors go "well, there's a flag to work around it, so we don't have to fix our products!"
I'll see if there's a good solution, but I suspect not. If vendors could ship products which aren't garbage, that would be great...
Alan DeKok.
- List info/subscribe/unsubscribe? Seehttp://www.freeradius.org/list/users.html
On Oct 20, 2024, at 10:30 AM, ryslink@dialtelecom.cz wrote:
It seems that since version 3.2.6, Freeradius always sends the Message-Authenticator AVP, as discussed in the thread below (I did search the conference, but did not find anything more relevant).
The release notes explain this issue. There's a longer explanation on the web site, under the BlastRADIUS security notification. The default radiusd.conf file also has explanations.
I have upgraded the freeradius version on the server this weekend, and I have number of customer complaints whose obsolete BRASes fail to process replies containing the M-A AVP. Hence, I would need to selectively remove them from the replies - I tried to do it via the update-reply in the post-auth section of the configuration
update reply { Message-Authenticator !* ANY }
, but examining the packets via radsniff, the replies still do contain the M-A AVP.
Message-Authenticator is always added to replies. This isn't configurable, and cannot be changed or disabled. Please also name the vendor, and the model of BRAS which is behaving this way. The Message-Authenticator attribute has been defined for about 25 years. When a BRAS discards packets containing Message-Authenticator, it means that the vendor has gone out of their way to read the RFCs, and then decide to do something stupid. i.e. This behavior is incompetence bordering on maliciousness.
Could you please kindly advise on how to best remove the M-A attribute via the server configuration?
Downgrade to 3.2.5, and add the BlastRADIUS fixes manually. The BlastRADIUS security notification explains how to do this. Or, you have source. You can patch the server to remove the BlastRADIUS fixes. We are not going to make millions of installations of FreeRADIUS vulnerable to a security issue because some vendor is too lazy or stupid to read the RFCs. While this may sound harsh, there really is no other way to describe this behaviour. The vendor has added code to do something useless, stupid, and insecure. Alan DeKok.
participants (4)
-
Alan DeKok -
Bjørn Mork -
Connor Herring -
ryslink＠dialtelecom.cz