BlastRADIUS Attack Exposes Critical Flaw In 30-Year-Old RADIUS Protocol (securityweek.com) 26
wiredmikey shares a report from SecurityWeek: Security vendor InkBridge Networks on Tuesday called urgent attention to the discovery of a thirty-year-old design flaw in the RADIUS protocol and warned that advanced attackers can launch exploits to authenticate anyone to a local network, bypassing any multi-factor-authentication (MFA) protections. The company published a technical description of what is being called the BlastRADIUS attack and warned that corporate networks such as internal enterprise networks, ISPs, and telcos are exposed to major risk. The vulnerability is being tracked as CVE-2024-3596 and VU#456537. "The root cause of the attack is that in the RADIUS protocol, some Access-Request packets are not authenticated and lack integrity checks. An attacker can modify these packets in a way which allows them to control who gets onto the network," the research team explained (PDF).
The RADIUS protocol, first standardized in the late 1990s, is used to control network access via authentication, authorization, and accounting and is still used widely today in switches, routers, access points and VPN products. "All of those devices are likely vulnerable to this attack," the researchers warned. "The key to the attack is that in many cases, Access-Request packets have no authentication or integrity checks. An attacker can then perform a chosen prefix attack, which allows modifying the Access-Request in order to replace a valid response with one chosen by the attacker. Even though the response is authenticated and integrity checked, the chosen prefix vulnerability allows the attacker to modify the response packet, almost at will," according to the InkBridge Networks documentation. The researchers say that every single RADIUS server must be upgraded in order to protect against this vulnerability. "It is not sufficient to upgrade only RADIUS clients, as doing so will allow the network to remain vulnerable."
The RADIUS protocol, first standardized in the late 1990s, is used to control network access via authentication, authorization, and accounting and is still used widely today in switches, routers, access points and VPN products. "All of those devices are likely vulnerable to this attack," the researchers warned. "The key to the attack is that in many cases, Access-Request packets have no authentication or integrity checks. An attacker can then perform a chosen prefix attack, which allows modifying the Access-Request in order to replace a valid response with one chosen by the attacker. Even though the response is authenticated and integrity checked, the chosen prefix vulnerability allows the attacker to modify the response packet, almost at will," according to the InkBridge Networks documentation. The researchers say that every single RADIUS server must be upgraded in order to protect against this vulnerability. "It is not sufficient to upgrade only RADIUS clients, as doing so will allow the network to remain vulnerable."
RADIUS is a management protocol (Score:4, Informative)
You generally shouldn't run any management protocol across untrusted networks. Even without this attack, RADIUS packets have a lot of information that I wouldn't want random snoopers to see (especially the accounting packets).
Re: (Score:2)
Social engineer or compromise your way into ONE bastion host (because outside of the most hardened air-gapped installations, there will be a bastion host that has access to the trusted network which you can remotely attack), and then BlastRADIUS allows low-level infestation of the routers and switching infrastructure. And oh, everything else using RADIUS... like say, an entire datacenter full of remotel
Re:RADIUS is a management protocol (Score:4, Insightful)
Meeting rooms, interview rooms and building lobbies generally have guest wireless available, which frequently run on the same WAP as the corporate network. They're generally a separate subnet, but they're frequently incorrectly configured and can reach the main network. I've used that access in the past to get to security equipment that my company installed, an attacker could have done the same thing to reach the routers.
Re: (Score:3)
I meant to add that I once saw a WAP that had been plugged into the network and duct taped to the bottom of a table in a meeting room. A supposed salescritter had done a presentation there and had been left unattended for a minute or so, he then proceeded to hack the company's database from the parking lot. We have friends who do janitorial work from several corporate office parks, they've been offered up to $1000 to plug some unidentified device into a corporate network in an unoccupied cubicle (they tur
Re: (Score:2)
This sounds more like a huge enabler of horizontal movement that will be exploited to the hilt by APTs.
One of the very many because most security-critical software sucks these days.
Re: (Score:2)
Came here to say the same thing. Yes, this vulnerability is probably real. No, if you can do this attack, in many scenarios you can already do worse. Still has to be patched.
Re: (Score:3)
However, a lot of RADIUS traffic where it matters is just RADIUS being used as a tunnel for EAP. Which is used as a tunnel for EAP-TLS/TTLS/PEAP/LEAP/FAST/whatever. Which is used to tunnel TLS. Which is used to tunnel another layer of EAP or DIAMETER or whatever depending on the protocol. Which then tunnels PAP or MSCHAPv2 or similar, which is where the auth exchange actually happens.
The protocol should really be called Matryoshka. In any case a lot of the time the stuff that matters like credentials i
Could /. post relevant info? Kthx. (Score:5, Informative)
2) This attack requires a MITM between the RADIUS client (The Network Access Server) and the RADIUS server. (I.e. You need access to the victim's network and be in a privileged enough position to intercept traffic between something like a Wifi AP, VPN gateway, etc. and the RADIUS server.)
3) This attack depends on the RADIUS client being unable to receive the Access-Reject packets from the RADIUS server. (I.e. The MITM needs to blackhole attempts by the RADIUS server to tell the client to deny access to the user.)
4) This attack also requires that the RADIUS client provide no throttling / user banning of it's own for repeated failed authentication attempts. (It's a collision attack against MD5, so some processing power and repeated attempts are required to break it.)
5) EAP methods mitigate this threat to some extent.
All in all, if your attacker is in such a position to have MITM ability between your NAS and RADIUS server, you have far bigger problems than MD5 collisions. Yes, some ISPs may be affected by this but that's a network design flaw if I've ever seen one. (Why would an ISP allow cleartext authentication over it's unmonitored miles of lines? That's just asking someone to pirate their internet service.....)
Re: (Score:2)
Really? When I studied the RADIUS protocol a hundred years ago your step 3 occurred to me. It seemed obvious (like the print service in NT3.51 and everything after continually running in kernel mode) to me, I assumed that I was just missing something. Now I'm starting to wonder if I missed a career calling as either a cracker or security researcher.
Re: Could /. post relevant info? Kthx. (Score:3)
Re: (Score:2)
What I meant was that RADIUS didn't **require** a reply from the authentication server, it just gives up and allows the connection. On a failure it should deny.
Re: (Score:2)
No NAS will allow a session to proceed if it doesn't receive an Access-Accept.
The reason #3 is required, is because you have to prevent the NAS from receiving the rejection while you sit there and continue to try to generate collisions for your faked Access-Accepts.
RADIUS has known to be grossly insecure for ages.
All NAS-RADIUS server comms are on private unrouted networks these days.
This is a nothingburger.
Re: (Score:2)
That's just asking someone to pirate their internet service.....
There were some DSL internet providers who tried to charge by the minute and had a monthly data cap. RADIUS was used to authenticate, but it is not good for accounting the connection time and data caps.
Re: (Score:2)
But you, as the client, have no ability to send or receive those packets.
Re: Could /. post relevant info? Kthx. (Score:2)
Typical. Security researchers always make a 10.0-point drama out of any issues found.
Re: (Score:2)
Thank you, sir.
Kind of obvious (Score:4, Informative)
I don't quite know what to make of this. Message-Authenticator has been around for well over two decades and the clients I know of always use it by default. You actually need it because there is otherwise nothing to prevent any non-PAP authentication requests from being processed as valid requests by the server. Anyone who could spoof the IP of a client would be able to trivially spam the server and its backends without it.
Authors of the paper are also somewhat confused about how the protocol works. The proxy state is for intermediate proxies not clients and servers. If a client ever sees a proxy state attribute in a request or a response something is broken. Systems for the most part simply ignore attributes they don't understand which is what actually enables arbitrary data to be transported for the MD5 collisions to work.
Personally I don't see anything new here. People have been warned about using RADIUS over untrusted networks for decades and for the most part everything is sent in the clear. All of the normal non-EAP authentication protocols are hopeless broken. It is hard to dream up a scenario where any of this matters or enabled something meaningful you couldn't do before by other means. I still can't get past the absent Message-Authenticator claims in the paper however there are a shitload of implementations especially clients so everyone's mileage may vary depending on what they are doing.
Re: (Score:2)
DIAMETER and SHA-2 (Score:3)
Last time I checked (right when going from 2G to 3G circa 2005), everyone who knew a little bit about security was using DIAMETER (https://en.wikipedia.org/wiki/Diameter_(protocol)), and no one was using MD5 checksums anymore, all moved to SHA-256 (part of the SHA-2 family)...
Is sad to see people not running with the times.
Re: (Score:2)
Last time I checked (right when going from 2G to 3G circa 2005), everyone who knew a little bit about security was using DIAMETER (https://en.wikipedia.org/wiki/Diameter_(protocol)), and no one was using MD5 checksums anymore, all moved to SHA-256 (part of the SHA-2 family)...
DIAMETER was only really ever used in mobile networks and punts to a secure transport (TLS, IPSEC..etc). Punting is also exactly the solution to secure RADIUS rendering it no more or less secure. Was also depressingly common for operators to not bother with secure transports and just run DIAMETER in the clear.
Re: (Score:2)
Cisco IOS routers still Don't support DIAMETER protocol. Your options are TACACS+ and RADIUS.
Also, they are lacking in supporting any method of using authentication methods for SSH other than password-based.
This is a long-standing issue in that Network equipment vendors have long neglected auth protocol development and support for more secure standards.
Heck.. A lot of network devices Don't support the message Authenticator and setting Require-Message-Authenticator=Yes on your RADIUS server simply cau
Re: (Score:2)
Cisco IOS routers still Don't support DIAMETER protocol. Your options are TACACS+ and RADIUS.
If you are authenticating your routers over a link that can be MITM'd, you deserve what's coming your way.
We use local TACACS servers at every PoP, with actually safe methods of synchronizing their authentication information.
Auth protocols suck. The solution is to not allow anything other than the clients to talk to them.
In my 20 years of experience, I have never seen someone throwing RADIUS auth requests over open wires they didn't own.
Cutting edge (Score:2)
When I was working with RADIUS in the late 90s, I had no idea I was working on cutting edge software. I just assumed it was some old UNIX thing.
Oh, I worked on RADIUS... (Score:2)
...I was kinda sorta in large part responsible for the Proxy State Attribute (I worked at the biggest dial up ISP at the time, and we needed it to resell our dialup network to AOL, and Microsoft (and others) all at the same time). I hope it isn't involved in this, and:
(from the Deprecating RADIUS RFC obviously written in response to this attack)
Re: (Score:2)
Also, "why Proxy-State is defined this way", why it is defined what way? I mean it was decades ago, so I'm not sure I'll remember, but still...what way?
If I had to guess, they are probably asking why the RADIUS client is sending that attribute at all. Given that the server doesn't use it. I.e. They are questioning the validity of including such a field as a feature of the protocol.
Re: (Score:2)
Could be, in which case I know exactly why.
I had a 25Mhz SPARC, three of them actually, and needed to handle the entire load of a very large for the time dialup network on them, and believe it or not that was very costly just doing MD5 on a few UDP packets. Er, a few hundred every second. If I had to write anything to disk as well I was sunk. So I bundled up whatever I needed to know to return my reply to the originator and sent the auth request on to whatever server my regents engine said this account