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.

[the_rock]

Its good to know its not IPS related.

[vass]

it seems that the radius client on checkpoint does not accept some attributes (in this case 80), wich is strange because if you use EAP its always sent by the client and the server. lets hope it accepts and uses it in a near future.

[Duane_Toler]

I had to do this myself for a customer today, and this worked.  I presume you installed policy to the affected gateways after setting "radius_ignore" to 80?
You can run a VPN debug to see the issue:  vpn debug on TDERROR_ALL_ALL=5

You'll see the exchange in vpnd.elg if you search for "attr_get_from_buf":

Failing:

[Expert@fw1:0]# grep attr_get_from_buf vpnd.elg.1
 attr_get_from_buf: unexpected attr len. probably an unknown RADIUS attr (type=80).
 attr_get_from_buf: unexpected attr len. probably an unknown RADIUS attr (type=80).: Interrupted system call
 attr_get_from_buf: unexpected attr len. probably an unknown RADIUS attr (type=80).: Invalid argument
 attr_get_from_buf: unexpected attr len. probably an unknown RADIUS attr (type=80).: Invalid argument

Succeeding:

[Expert@fw1:0]# grep attr_get_from_buf vpnd.elg.2
[vpnd 28143 4067185088]@usdc1-ravpn-fw1[15 Jul 14:54:04][AU] attr_get_from_buf: got a RADIUS attr buffer (type=80 vendor:type=0:0):
[vpnd 28143 4067185088]@usdc1-ravpn-fw1[15 Jul 14:54:04][AU] attr_get_from_buf: got a RADIUS attr buffer (type=7 vendor:type=0:0):
[vpnd 28143 4067185088]@usdc1-ravpn-fw1[15 Jul 14:54:04][AU] attr_get_from_buf: got a RADIUS attr buffer (type=6 vendor:type=0:0):
[vpnd 28143 4067185088]@usdc1-ravpn-fw1[15 Jul 14:54:04][AU] attr_get_from_buf: got a RADIUS attr buffer (type=25 vendor:type=0:0):
[vpnd 28143 4067185088]@usdc1-ravpn-fw1[15 Jul 14:54:25][AU] attr_get_from_buf: got a RADIUS attr buffer (type=80 vendor:type=0:0):
[vpnd 28143 4067185088]@usdc1-ravpn-fw1[15 Jul 14:54:25][AU] attr_get_from_buf: got a RADIUS attr buffer (type=7 vendor:type=0:0):
[vpnd 28143 4067185088]@usdc1-ravpn-fw1[15 Jul 14:54:25][AU] attr_get_from_buf: got a RADIUS attr buffer (type=6 vendor:type=0:0):
[vpnd 28143 4067185088]@usdc1-ravpn-fw1[15 Jul 14:54:25][AU] attr_get_from_buf: got a RADIUS attr buffer (type=25 vendor:type=0:0):
[vpnd 28143 4067185088]@usdc1-ravpn-fw1[15 Jul 14:54:25][AU] attr_get_from_buf: got a RADIUS attr buffer (type=26 vendor:type=311:14):
[vpnd 28143 4067185088]@usdc1-ravpn-fw1[15 Jul 14:54:25][AU] attr_get_from_buf: got a RADIUS attr buffer (type=26 vendor:type=311:15):
[vpnd 28143 4067185088]@usdc1-ravpn-fw1[15 Jul 14:54:25][AU] attr_get_from_buf: got a RADIUS attr buffer (type=26 vendor:type=311:14):
[vpnd 28143 4067185088]@usdc1-ravpn-fw1[15 Jul 14:54:25][AU] attr_get_from_buf: got a RADIUS attr buffer (type=26 vendor:type=311:15):

[the_rock]

Thats super helpful, thank you!

[Jo_]

Also tried implementing this today after seeing your post.
This worked for us as well

[JP_Rex]

@Duane_Toler It worked we just implemented together with the TAC the ignore Attribute 80 for the VPN Auth.

[PhoneBoy]

There appear to be several TAC cases on this issue already and I've also opened an internal request with the relevant team.
I will follow up after the weekend.

[tjoll]

Just got an update from support. R&D is aware of the issue and is working on a fix. 

Unfortunately, it is not a situation where there is a simple workaround as of yet as R&D is still investigating how to get around this new issue.

There is a setting on Microsoft NPS servers - "Client must always send the Message-Authenticator attribute in the request"

When this setting is enabled, it requires that the NPS server receives Attribute 80 from the client (in this case, the client is our gateways). We cannot work around this at this time from our side. sk42184 only works when we receive attribute 80 from the server for RA/MA login. 

There is currently no ETA for this. I have already involved my team leaders and group managers in this issue to try and push for an official statement (at the very least) from Check Point on this. I know this is not the answer we were hoping for, and trust me, I wish we had a solution because it would make things a lot easier on my end as well as I can assure you that you are not the only one experiencing this issue and it is never easy from my end to not have a definite answer.

Hopefully, R&D will release an fix soon. 😃

[Matt_Taber]

This is hitting us in an odd way.  RADIUS + DUO MFA works on our Management server for SSH & WebUI, but does not work for SmartConsole or SmartView via WebUI.

Login to SmartConsole via RADIUS, see the Access-Request, get the MFA prompt, Accept it, see Access-Accept from RADIUS back to management server - but just dies on the vine.  Keep getting DUO MFA prompts, until it gives up.

These logs show up each time I hit approve w/in the DUO app:

attr_get_from_buf: unexpected attr len. probably an unknown RADIUS attr (type=80).: No such file or directory
attr_get_from_buf: unexpected attr len. probably an unknown RADIUS attr (type=80).: No such file or directory
attr_get_from_buf: unexpected attr len. probably an unknown RADIUS attr (type=80).: No such file or directory
attr_get_from_buf: unexpected attr len. probably an unknown RADIUS attr (type=80).: No such file or directory
RADIUS Servers Cannot Be Reached. Dropping Request

We did not enable any of the new settings w/in NPS, nor does it look like they got enabled after patching.

PS C:\WINDOWS\system32> netsh nps show limitproxystate

Limit Proxy State = disable
Ok.

PS C:\WINDOWS\system32> netsh nps show requiremsgauth

Require Message Auth = disable
Ok.

[JP_Rex]

Have you tried installing the Database and rebooting the Management?

I am not sure what you have to do get this working on the MGMT.
At one Customer it just started working after a week. I have no idea why.

Regards

Peter

[Matt_Taber]

Installed database, rebooted management servers.  No dice.   NPS is still sending the Access-Accept packet w/ attribute 80.  I ruled out the DUO proxy software from adding the attribute by forcing my AD user to auth directly to NPS.  DUO listening on 1812, NPS listening on 1645.  Not sure why there's different radius clients w/in the CP software.    web/ssh is fine, console is not.

[Duane_Toler]

Are you able to edit the RADIUS client entry on the NPS server for the SmartCenter/MDS?  If so, can you disable the checkbox to "Require Message-Authenticator attribute" (in the "Additional Options" tab on the client properties).

Port 1645 is the original, and since-disclosed erroneous, port for RADIUS.

Port 1812 is the re-assigned port number (aka "NEW-RADIUS")

https://www.rfc-editor.org/rfc/rfc2138

   This memo documents the RADIUS protocol.  There has been some
   confusion in the assignment of port numbers for this protocol.  The
   early deployment of RADIUS was done using the erroneously chosen port
   number 1645, which conflicts with the "datametrics" service.  The
   officially assigned port number for RADIUS is 1812.

 When possible, port 1812 (authentication) and 1813 (accounting) should be used instead of 1645/1646 (respectively).

[the_rock]

Hey Duane,

Just wondering, this is STRICTLY done on Tadius server side, right? No need to modify anything on management server?

Andy

[Duane_Toler]

Yeah, that checkbox is on the NPS server's list of RADIUS clients.

(This is  a screengrab from someone else's demo, not mine; but this is it).

I haven't had a customer call me yet complaining about SmartConsole failures, but this would be my suggestion to them if so.  I haven't been able to 100% confirm this is the workaround, but it's my best intuitive guess at the moment.

[the_rock]

Thanks!

[lraaicfdb]

We also have problems logging into the Smartconsole. The checkbox was disabled by default on our NPS. I don't think that's the solution. But please keep us updated.

[Duane_Toler]

The option "limitproxystate" is going to be used when the local NPS server is a central server and receives a RADIUS request from downstream RADIUS server when the downstream server is a RADIUS proxy.  In this case, the downstream RADIUS proxy/relay is sending the request to the central NPS server for handling, and the central server requires the downstream proxy to send a message with attribute 80.

The option "requiremsgauth" is similar, but in reverse.  This will be used on the local NPS server if it is the RADIUS proxy, and has sent a request to the upstream central server, and now needs to process the response from that central server.  "requiremsgauth" will be used to verify the upstream central server has sent a reply with attribute 80 in response to the proxy request sent by this local server.

Attached is a screenshot showing an example remote RADIUS server configuration for RADIUS proxy.  The screenshot is showing the local server configuration (the local RADIUS proxy) for the upstream RADIUS server (the server to where the  local proxy sends its request).  This specific example is for a customer using the RADIUS Accounting to a gateway for Identity Awareness to learn identities via RADIUS Accounting messages (asynchronously, of course).

If you don't have central and proxy RADIUS servers, then these won't apply.  Also, curious, is that the KB article appears to have a typo in the "requiremsgauth" section, item 2. 😊

According to sk42184, however, management logins via RADIUS are already ignoring, or otherwise handling, attribute 80.  This was addressed in task PRHF-10523 and resolved back in R80.x Jumbo HFAs.  Obviously, you're still having some sort of issue, tho.  Is Microsoft NPS used in the path for your SmartConsole logins?  In the meantime, you could add yourself a local administrator with the management API that uses a local username/password:

mgmt_cli -r true -f json add-administrator name cpadmin password cppass.123 must-change-password true permissions-profile "read write all"

You'll be prompted to change the password on first login.

[StackCap43382]

Attribute 80 from sk42184 has fixed this issue for all customers hitting this issue after patch Tuesday. 

[the_rock]

You are talking about patch that came out 2 days ago (this Tuesday)? Cause we changed this setting last Friday, did absolutely nothing.

Andy

[lraaicfdb]

The workaround will not achieve much, because the configuration for "requiremsgauth" is disabled on our site. I think it is disabled by default and needs to be enabled manually. So no exception needs to be added.

@JP_Rex I'm curious to see what Checkpoint's response to your ticket is.

[Adam276]

Very interesting information about it not being enabled and still not working with Checkpoint VPN client auth.  Considering that update by Microsoft completely breaks VPN client authentication with radius with Checkpoint,  I am surprised there are not more posts about this.  You can only not apply cumulative Microsoft security patches on servers for so long before it becomes risky.  It will be interesting to see if this is a Microsoft bug that they need to fix quickly or just something needs to be fixed or implemented by Checkpoint.

[the_rock]

Yes, please keep us posted.

[JP_Rex]

Current Status 2024/July/18
I have seen three different places were to use Radius in a Check Point environment.

1. Gaia never had a problem. (uses the Linux Implementation?)

2. On the GW (Client auth, VPN) This can be fixed by the settings in the policy (RADIUS authentication fails (checkpoint.com))

3. On the MGMT (Smart Console) As far as I know no workaround has been found. 

The last communication with the TAC suggests that a patch is in Q&A.

Regads

Peter

[Matt_Taber]

These are the scenarios, as I see them. 

Something changed in MS NPS since their KB5040268 patch was applied that appears unrelated to the 4 new settings that were implemented to help remediate CVE-2024-3596.

As a hail mary, I attempted the fix in SK42184 by globally ignoring attribute 80 - which I assumed would not work, and didn't as the SK notes a fix had been included for this particular issue since R80.40 JHF53.

Looking forward to a timeline for a fix from R&D.

Thank you for everyone's input thus far!

[the_rock]

I heard many customers say it would be nice if there was an official SK about all this from CP side, but so far, nothing...

Andy

[JP_Rex]

It normally takes 2-3 Month until a SK is approved for "public" viewing.

Sometimes it is faster. But for that it is not critical enough.

Regards

Peter

[the_rock]

Well, that might be the case, BUT...as few customers told me, they wish there was a better workaround for this than removing the MS patch.

I guess not for now...

Andy

[Matt_Taber]

Removing the MS patch is not a valid workaround.  For now, we have created a shared RO SmartConsole account for those users that previously had RO RADIUs access.  We have a non-radius based admin account that we're using in the interim to make changes.   Which defeats the entire reason we implemented RADIUS (to use DUO MFA) for cybersecurity insurance purposes.

[the_rock]

I agree, its not THE workaround, but it is A workaround lol

Im sure you will get what Im saying, because at the end of the day, most people dont have time to troubleshoot this for hours, they need quick fix, specially companies that have 100s of employees where MFA 100% HAS TO work 🙂

Andy

[Duane_Toler]

If you're using Duo, why do you need NPS server?  Duo can be your authenticator directly and do LDAP lookup for user names/password validation.  You don't need to relay to NPS along the way.