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.

[Matt_Taber]

I found a guide for setting up DUO for Infinity Portal administration, but struggling to find a doc for SmartConsole access.  Assumption would be to create a new IDP (which is a new option that I don't recall seeing before in SmartConsole.)

I'll do some digging, thank you for this suggestion.

[Duane_Toler]

You'll setup a new Identity Provider object in SmartConsole, and choose the radio button "Managing administrator access".  Setup the matching SAML application in Azure/Entra AD, enter those Entity ID and Reply URLs, download the metadata file from Azure, upload to the IdP object.

Edit, or create, a management user, change authentication type to Identity Provider, select the IdP for management access, publish, then test it.

Open SmartConsole, and change the login type to Identity Provider.

[the_rock]

You got it:)

Andy

 

[PhoneBoy · Accepted solution]

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.

[Duane_Toler]

Ahhh! That's right, SmartConsole now has option for SAML/IdP!  That's so recent that it slipped my mind.

[PhoneBoy]

Yes as of R81.20 🙂

[tavi0906]

In the SK its mentioned, Check Point plans to provide a fix in the upcoming Jumbo Hotfix Accumulator package for all supported versions.

My question is >

if we were to take the approach of changing the authentication method for the versions that are not supported, do we still require to install the hotfix?

if we are to install the mentioned hotfix, would it still be required to change the Authentication method? 

[the_rock]

Very good questions indeed @tavi0906 

[PhoneBoy]

Changing authentication methods away from RADIUS definitely mitigates the vulnerability, which is specific to usage of RADIUS.
Jumbo Hotfixes include many bugfixes and your decision to install a given one will depend on a number of factors.

[tavi0906]

Do you mean for the CVE-2024-3596, there is no further action required (install JHF) if any of the following conditions is met:

• RADIUS is not configured
• RADIUS is configured but with the RADIUS server in an isolated internal network with Anti-Spoofing enabled

And also to check, so installing only the upcoming JHF with none of the points indicated above, might not be able to mitigate the CVE-2024-3596?

[PhoneBoy · Accepted solution]

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.

[the_rock]

Hope it will be included in next jumbo hotfix?

[PhoneBoy]

ETA on this is unknown at this time.

[lraaicfdb]

@PhoneBoy 
Is the fix also applicable for security management? Logging into the Smart Console via Active Directory does not work since the latest Microsoft update.

[PhoneBoy]

I assume it is relevant for Management as well in this specific context.
Your best bet is to confirm with TAC, however.

[JP_Rex]

I will let you know.
One of my Customers installs the Fix today on his MGMT for SmartConsole Authentication.

Regards
Peter

[JP_Rex]

The fix was installed on a R81.20 HFA Take 65 SMS since then the Login with Radius credentials works.

🍾
Case Closed

Regards
Peter 

[cdooer]

Does the fix need to be requested, or can it be downloaded and applied? I've got an open TAC case, haven't heard back yet. Was hoping that maybe I could just download and apply it. 

[PhoneBoy]

As the fix is only available for specific JHF levels, it needs to be requested.

[BeardedKeyboard]

I tried requesting a backport to R81.10 (any take) from TAC via our Vendor but TAC were not forthcoming. Their response was "Check Point plans to provide a fix in one of the upcoming Jumbo Hotfix Accumulator packages, maybe greater than T-158" and "Unfortunately we do not have any time frame currently".

So no backports then and no timeline, and in the meantime my security team are requesting weekly updates as to why our NPS servers still aren't patched.

[gg_fga]

Same thing, we asked TAC for patches for quantum R81.10 and for Gaia embedded R81.10, the first answer was:

"We don't have a specific time for the release of the PRHF-10523 and PRHF-35233 in a Jumbo Hotfix and we can't provide a specific time."

Insisting on having an idea of the release date anyway, the answer:

"The fix is scheduled to be implemented within approximately 2.5 months. Unfortunately, we are unable to provide a more specific timeline."

The CVE was revealed at the beginning of July, and from Check Point's point of view, we'll have to wait until the end of the year, or even the beginning of next year, for a jumbo update qualified as recommended.

Incredibly, we'll have to keep our Radius servers unpatched in the meantime.

[BeardedKeyboard]

Indeed - tell me you want to force obsolescence without saying you want to force obsolescence.

[cjrnz]

Still no fix for R81.10 as far as I can see. We've been using local admin accounts to get work done for near two months now because the windows administrators couldn't leave the RADIUS servers unpatched any longer.

[User88083582]

R81.10.15 is out.

https://support.checkpoint.com/results/sk/sk182438

this version already contains: "VPN Remote Access - RADIUS attribute to be ignored." and is set to ignore attribute 80

tested and works with fully updated NPS server.

[cjrnz]

Thanks, R81.10.15 would be a Gaia embedded version, not to be confused with regular Gaia.  Our SMS in this case. (Thankfully it only affects SmartConsole login, not something more important like VPN, so we can work around it.)

[tavi0906]

Do you mean for the CVE-2024-3596, there is no further action required (install JHF) if any of the following conditions is met:

• RADIUS is not configured
• RADIUS is configured but with the RADIUS server in an isolated internal network with Anti-Spoofing enabled

And also to check, so installing only the upcoming JHF with none of the points indicated above, might not be able to mitigate the CVE-2024-3596?

[PhoneBoy]

If you are not using RADIUS with a Check Point gateway/management, then no additional action is required with respect to this CVE.
If you use RADIUS with a Check Point gateway/management, apply the JHF when available.

The mitigation for CVE-2024-3596 includes requiring Message Authenticator attributes in RADIUS.
RADIUS authentication will fail if the RADIUS server used requires Message Authenticator attributes and you have not applied the relevant patches (JHF or otherwise) on Check Point devices.

I hope that's clear.

[BeardedKeyboard]

Do we have an update as to when the JHF will be available? We're currently using R81.10 on Take 150, so would need to request the fix from Check Point if the date isn't soon; in the meantime, we're having to hold off patching two NPS servers due to this issue.

[tjoll]

Yesterday, I've got an update from TAC that they have an custom hotfix for R81.20 take 65 and are planning to integrate it in the JHF. Unfortunately, I do not have any ETA when it will be added in the JHF or when other versions receive the custom hotfix.

[BeardedKeyboard]

Any updates on an ETA?