Blast-RADIUS - CVE-2024-3596

[Alex-]

https://www.blastradius.fail/

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.

[Lesley]

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:

  • RFC 2138

  • RFC 2865

• 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) 

[vass]

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

[the_rock]

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

[the_rock]

Thanks for that @Alex- 

[PhoneBoy]

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.

[the_rock]

Thats true, but I think an official sk or IPS protection update would probably make lots of customers feel more comfortable.

Andy

[PhoneBoy]

I assume once our investigation is completed, such things will be provided. 🙂

[the_rock]

I have no doubt about it 🙂

[vass]

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 

[PhoneBoy]

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... 

[Bob_Zimmerman]

RADIUS over DTLS also mitigates this issue. Not a lot of servers support that, but this will hopefully drive server vendors to improve.

[JozkoMrkvicka]

RADIUS over TLS or DTLS is the best solution and vendors should push for this implementation.

[the_rock]

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

[the_rock]

I was hoping there would be an sk about this, but I suppose since its not CP issue, maybe thats where there isnt one...

[JozkoMrkvicka]

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.

[the_rock]

I see what you mean, makes sense.

[JP_Rex]

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

[vass]

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.

[the_rock]

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 🙂

[the_rock]

Since @JozkoMrkvicka likes memes, I got one for ignoring things...:)

Andy

 

[JP_Rex]

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

[vass]

If they mandate the Message Authenticator it will break it, Checkpoint at least for VPN auth does no send it on the Access-request

[JP_Rex]

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

[tjoll]

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

[JP_Rex]

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

[tjoll]

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.

[tjoll]

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.

[JP_Rex]

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

[tjoll]

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...