RADIUS Vulnerability

New attack against the RADIUS authentication protocol:

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.

This is one of those vulnerabilities that comes with a cool name, its own website, and a logo.

News article. Research paper.

Tags: academic papers, authentication, man-in-the-middle attacks, protocols, vulnerabilities

Posted on July 10, 2024 at 10:42 AM • 6 Comments

Comments

ngô ############ long • July 10, 2024 10:10 PM

on a scale from 1-10, how screwed up are we? i mean RADIUS is an incredibly common protocol used for securing info

Marcel • July 11, 2024 2:00 AM

It is a shame that in 2024, people are still using MD5 in security applications. That should already warrant an 11 out of 10 for ignorance.

The actual problem IMHO is that we are still sending personal information (usernames, activity patterns, …) around in plaintext in 2024. Encapsulating this kind of traffic in (D)TLS should be best practice, at least.

So, I would give a 10 out of 10 for neglicence, but only a 3 out of 10 for impact of this new vulnerability.

But everybody, please, please, start encapsulating/tunneling this traffic NOW. (And then switch from MD5 to SHA-2/3. I know, this will take years, so embed this in TLS, then we have time to fix the rest.)

ResearcherZero • July 11, 2024 2:26 AM

Collisions online in less than five minutes depending on hardware.

RADIUS has not been updated to remove MD5…

“Unfortunately, although the proposals for RADIUS over TLS have existed for a decade, many systems continue to use RADIUS/UDP. Deploying TLS and maintaining a public-key infrastructure continues to be a much more involved process for system administrators than simply using UDP; many of the challenges are documented in the (D)TLS Internet Draft.”

‘https://www.blastradius.fail/pdf/radius.pdf

To mitigate this attack, we recommend servers always include a Message-Authenticator as the first attribute in any response. This appears to prevent the above attack even if
a client does not validate the HMAC-MD5.

https://support.microsoft.com/en-us/topic/kb5040268-how-to-manage-the-access-request-packets-attack-vulnerability-associated-with-cve-2024-3596-a0e2f0b1-f200-4a7b-844f-48d1d5ab9e66

ResearcherZero • July 11, 2024 2:30 AM

“If the MitM could get away with stripping out the EAP attribute, it could also get away with stripping out the Message-Authenticator (which is optional for non-EAP modes of RADIUS/UDP), and a variant of the Blast-RADIUS attack might work.”

There is further info here:

‘https://blog.cloudflare.com/radius-udp-vulnerable-md5-attack

Clive Robinson • July 11, 2024 4:00 AM

A look at the “In Depth” description on the website gives this,

“Due to the MD5 collision, the Access-Accept sent by the adversary verifies with the Response Authenticator, without the adversary knowing the shared secret. Hence, the RADIUS client believes the server approved this login request and grants the adversary access.”

The “MD5 collision” is actually the key to the attack working.

There are a couple of variants of the MD5 collision, the one being used here is the more interesting “Chosen-Prefix” one. Why “more interesting”, well Over a decade ago back in 2012 it was used by the “Flame Malware”,

“The Flame malware successfully used a new variation of a chosen-prefix collision attack to spoof code signing of its components by a Microsoft root certificate that still used the compromised MD5 algorithm.”

Highlighting again that the ICT Industry does not learn from lessons in it’s “living history”…

But related to a thread of a few days back on this blog,

The Flame Malware was “discovered” and classified as “Advanced Persistent Threat”(APT) from a Level III attacker by Kaspersky. They gave a probable attributed to the “Equation Group”.

Kaspersky found it by the automated responses sent back to their repository, something that was fairly standard of AV software at the time. Interestingly no other AV software organisation apparently “detected” Flame.

For those that may have forgotten, the Equation Group was believed to be part of the “Tailored Access Operations”(TAO) unit of the US NSA SigInt agency. Flame was mainly targeted against Middle East targets that had relations with Iran.

Flame “self destructed” leaving little or no trace very very shortly after the Kaspersky announcement, indicating Kaspersky were probably right in their assessment.

Some argue it was this that got Kaspersky vilified and eventually banded by the US Government.

Wannabe Techguy • July 11, 2024 9:21 AM

“Some argue it was this that got Kaspersky vilified and eventually banded by the US Government.”

Ah yes Kaspersky caught them “red handed”.
Now it makes sense.

RADIUS Vulnerability

Comments

Leave a comment Cancel reply