- Products
- Learn
- Local User Groups
- Partners
- More
What's New in R82.10?
10 December @ 5pm CET / 11am ET
Improve Your Security Posture with
Threat Prevention and Policy Insights
Overlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
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.
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.
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.
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.
No update because our ticket is closed. We've upgraded the environment to take 65 and installed the custom hotfix. I would suggest to open a case yourself and ask for a portfix. I'm also missing the fix in the upcoming JHF release.
Can Spark appliance users also get the same support as others?
Is a fix also planned for version R81.10.10?
I assume we will also roll out fixes for Quantum Spark as well.
Any news for R81.10?
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.
I am uncertain whether R81.20 Take 89 fixes this issue for VPN connections, without ignoring attribute 80. The release notes state "Resolved CVE-2024-3596 - Blast-RADIUS attacks for Gaia Portal and Gaia Clish", but nothing in regards to VPN.
The official SK (Check Point response to CVE-2024-3596 - Blast-RADIUS attack) is also lagging on updates.
nope, upgraded my gateways to JHF 89, tried to revert the attribute 80 to the default 0 value, vpn login with radius DID NOT work for me! (but i did not have my managment on JHF 89, when doing the test, must try again when all is on JHF 89)
There's a few places where the effects of Blast RADIUS need to be fixed.
One of them is in Gaia OS itself (specifically for access to Gaia Portal and clish).
Why Remote Access VPN is not explicitly listed in this SK, I cannot say, but I believe it would correspond to Identity Awareness.
In any case, I'll see if we can get this explicitly mentioned in the SK.
R81.20 JHF 90 now supports Message Authenticator attributes in communication with RADIUS servers for all use cases (Gaia OS, Identity Awareness Portal, SmartConsole, Mobile Access Portal, Remote Access).
I assume similar fixes are also coming for other releases (R81, R81.10, and R82).
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 37 | |
| 19 | |
| 9 | |
| 7 | |
| 7 | |
| 5 | |
| 5 | |
| 4 | |
| 3 | |
| 3 |
Wed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchWed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY