- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: Blast-RADIUS - CVE-2024-3596
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Blast-RADIUS - CVE-2024-3596
Blast-RADIUS is a vulnerability that affects the RADIUS protocol. RADIUS is a very common protocol used for authentication, authorization, and accounting (AAA) for networked devices on enterprise and telecommunication networks.
What can the attacker do?
The Blast-RADIUS attack allows a man-in-the-middle attacker between the RADIUS client and server to forge a valid protocol accept message in response to a failed authentication request. This forgery could give the attacker access to network devices and services without the attacker guessing or brute forcing passwords or shared secrets. The attacker does not learn user credentials.
Who is affected?
Blast-RADIUS is a protocol vulnerability, and thus affects all RADIUS implementations using non-EAP authentication methods over UDP.
System administrators of networks using RADIUS should check with vendors for a patch against this vulnerability, and follow best practices for RADIUS configuration as discussed below. There is nothing that end users can do on their own to protect against this attack.
RADIUS is used in a wide variety of applications, including in enterprise networks to authenticate access to switches and other routing infrastructure, for VPN access, by ISPs for DSL and FTTH (Fiber to the Home), in 802.1X and Wi-Fi authentication, 2G and 3G cellular roaming and 5G DNN (Data Network Name) authentication, mobile Wi-Fi offload with SIM card-based authentication, private APN authentication, to authenticate access to critical infrastructure, and in the Eduroam and OpenRoaming wifi consortia.
What is the vulnerability?
The RADIUS protocol predates modern cryptographic guarantees and is typically unencrypted and unauthenticated. However, the protocol does attempt to authenticate server responses using an ad hoc construction based on the MD5 hash function and a fixed shared secret between a client and server.
Our attack combines a novel protocol vulnerability with an MD5 chosen-prefix collision attack and several new speed and space improvements. The attacker injects a malicious attribute into a request that causes a collision between the authentication information in the valid server response and the attacker’s desired forgery. This allows the attacker to turn a reject into an accept, and add arbitrary protocol attributes.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There's now an official SK on this: https://support.checkpoint.com/results/sk/sk182516
Basically:
- Exploiting this CVE requires MITM between the gateway and the RADIUS Server.
- If you have to use RADIUS instead of changing to a different authentication method, ensure your RADIUS server is deployed on an isolated network with anti-spoofing enabled.
- We plan fixes for the CVE in upcoming Jumbo Hotfixes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is now a hotfix available to support RADIUS Message-Authentication for the RADIUS client on the gateway for purposes OTHER than authenticating to Gaia OS itself (e.g. for clish/WebUI).
It is currently available as a hotfix on top of R81.20 JHF 65 via TAC and can be ported to other releases.
The relevant Bug ID is PRHF-35233.
We are planning a separate fix for Gaia OS itself.
Both fixes (and possibly others) are expected to be included in a future JHF.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Was following it also. No SK from Check Point, still very fresh and released today I think. (Some headsup yesterday).
If I try to keep it simple the Radius server you can configure in SmartDashboard supports -> Radius V1 en V2. Protocol PAP or MS_Chap2
-----------------------------------------------------------------------------------------------------------------------
RADIUS (Remote Authentication Dial-In User Service) server is used for authentication of users. Check Point uses the RADIUS servers in these scenarios:
Administrators logging in to SmartConsole
SecuRemote Users (via IKE Hybrid Mode)
RADIUS Configuration Fields
-
Host is where the RADIUS server is deployed.
-
Service is the port to which the RADIUS server listens. Choose one of two predefined services.
-
RADIUS is port number historically used by most installations.
-
NEW-RADIUS is the officially registered port number.
-
-
Shared secret is the secret between the RADIUS server and the Security Gateway.
-
Version can be either RADIUS Version 1.0, which is RFC 2138 compliant, and RADIUS Version 2.0 which is RFC 2865 compliant. For more, see:
-
Protocol is the type of authentication protocol that will be used when authenticating the user to the RADIUS server. This type should be supported and enabled by the server. The MS-CHAP v2 protocol is supported by some servers, including Microsoft IAS and Cisco ACS. This protocol provides higher security and the ability to perform a password change, as an additional challenge in the authentication session, when the user is configured as "User must change password at next logon" on the server.
----------------------------------------------------------------------------------------------
Second is that you also can use Radius to authenticate to the Gaia OS(and API). But for now it is to late for me to check 😁
(https://support.checkpoint.com/results/sk/sk72940)
If you like this post please give a thumbs up(kudo)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the info.
I captured some traffic for Radius VPN Auth with user/Pwd and Checkpoint does not send the Message-Authenticator attribute (has expected bcs it was not mandatory in RFC).
But we do know now that we will need in the future to send it and also check if the reply from the server has it (and if its ok and not tempered).
Does checkpoint already have some info if this will be implemented? (dunno what its used has client in Checkpoint side but if free radius there are updated clients).
Regards,
Vlad
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I hope there will be an official sk about it soon, as one is not present in the support site as of yet, unless its internal...no idea.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for that @Alex-
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If an attacker has gained the persistent MITM capabilities needed to exploit this, you're got far bigger issues to worry about.
In any case, it is under investigation.
Recommend opening a TAC case for tracking purposes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thats true, but I think an official sk or IPS protection update would probably make lots of customers feel more comfortable.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I assume once our investigation is completed, such things will be provided. 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have no doubt about it 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sure, but there are some scenarios were it "could" happen probably (non encrypted mpls or maybe even an transparent bridge doing an "l2" Mitm somewere) and we have always the state sponsored scenario wich has we know can pretty much do anything :).
Regardless i think clients and servers will have in a near future to update software to always send and require Message-Authenticator attributes for all requests and responses
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Requiring/using Message Authenticator attributes in RADIUS requests/responses seems like the best short-term mitigation for this issue.
Was mentioned in an Ars Technica article I was reading, which goes into some detail about Blast RADIUS: https://arstechnica.com/security/2024/07/new-blast-radius-attack-breaks-30-year-old-protocol-used-in...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
RADIUS over DTLS also mitigates this issue. Not a lot of servers support that, but this will hopefully drive server vendors to improve.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
RADIUS over TLS or DTLS is the best solution and vendors should push for this implementation.
Jozko Mrkvicka
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Agree 100%. Had customer call me last night, we did late remote session and I referred to this post. We ended up uninstalling latest windows update on radius server, rebooted, bam, all good. See, the issue with that is that most bigger companies, like one I worked with, is that they have process where if important patch comes out, they only have so many hours to install it, so at the end of the day, its sort of catch 22 situation...security or productivity.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was hoping there would be an sk about this, but I suppose since its not CP issue, maybe thats where there isnt one...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, it is CP issue. CP is not using Message-Authenticator attribute in Access-Request packets which in fact is not mandatory as per RFC 5080. On the other site, there is a note if Message-Authenticator attribute is not implemented:
However, Access-Request packets not containing a Message- Authenticator attribute always affect the cache, even though they may be trivially forged. To avoid this issue, server implementations may be configured to require the presence of a Message-Authenticator attribute in Access-Request packets. Requests not containing a Message-Authenticator attribute MAY then be silently discarded. Client implementations SHOULD include a Message-Authenticator attribute in every Access-Request to further help mitigate this issue.
That said, the patch which Microsoft released is exactly what the RADIUS server is supposed to do - if there is no Message-Authenticator attribute, drop the packet. There can be option to disable this strict checking, but it is up to RADIUS vendor how they handle this problem.
RADIUS clients must have Message-Authenticator attribute in Access-Request packets, or implemenent RADIUS over TLS/DTLS to be safe.
Jozko Mrkvicka
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I see what you mean, makes sense.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is an RFC for words like SHOULD and MUST.
And the word SHOULD is taken by developers as "do as you like" And for the last 20 or so years everybody ignored that attribute. On the expense of being vulnerable for the kind of attack used in "blast-radius".
Nobody cared because the main usage is to supply "intelligence" to dumb Network equipment in a secured network environment.
And I am not overly concerned by this attack, because if you can run the attack you are already in a place were you don't need what you might gain. In these kind of networks people still use tftp and telnet to administer there stuff.
it doesn't make sense to use a 15000 byte TLS Handshake to secure less then 100 byte of message. The reason RADIUS is used is because it is light weight you can do that on a micro controller.
Regards
Peter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Radsec is more then that , radius passes alot of info in plain text , when it was created it was not a problem but nowadays its for sure a problem, even on very secured networks (also why Tacacs+ is still better in a pure security view).
Also the attack is hard now (prob only state sponsored groups can use it) , but lets see in a few months, i also think that if someone has a foothold on your network this is not the main problem, but it helps getting around, imagine an router with an hacked OS, other encrypted traffic (ssh, https) would still be **bleep** hard to break, but it doing this you "could" in theory just bypass auth(MFA) and move lateraly to some more interisting stuff.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thats very true, its sort of like how http sites were not an issue 20 years ago and now there is probably less than 0.5% left 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Microsoft Patch breaks CP authentication.
KB5040268: How to manage the Access-Request packets attack vulnerability associated with CVE-2024-35...
The changes MS did broke the Authentication from CP.
I will open a Case for this.
Regards
Peter
PS I will report back
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If they mandate the Message Authenticator it will break it, Checkpoint at least for VPN auth does no send it on the Access-request
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
there seems to be a way around this
###########
To add an exception to exclude a server from requireauthmsg validation, run the following command:
netsh nps set requiremsgauth remoteservergroup = <remote server group name> address = <server address> exception = "yes"
########
regards
Peter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm also experiencing more RADIUS issues at a customer since the Microsoft patch. We're getting the error "RADIUS server is not responding" although it is. I've asked them to check the provided workaround to see if it will solve their issue. I'll keep you updated with the results.
Thanks.
Best regards,
Mitchel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We did not run the workaround. We fond the documentation after we rolled the Juli patch back on the primary radius DC.
Let me know if it solved the issue.
Regards
Peter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You're correct. I just got the confirmation that removing the update on the windows server does restore the radius authentication.
I'll also create a CP case to make them aware of this issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Support just gave me the following fix: https://support.checkpoint.com/results/sk/sk42184
We need to follow the steps described under the section "To ignore RADIUS attribute 80 if the problem is with VPN Client authentication"
Effectively, changing the radius_ignore setting in the global properties to the value 80. I'll let you know if this will fix the issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't think so.
ignoring a required Attribute can't be the solution.
@PhoneBoy any thoughts when R&D will have a look? Sunday?
Regards
Peter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Although the Microsoft KB article describes the changes in the Message-Authenticator attribute, which is number 80, the workaround support provided does indeed not work.
To be continued...
