Blast-RADIUS Attack Exploting Critical RADIUS Flaw Could Compromise Your Network

The Blast-RADIUS vulnerability represents a critical flaw in the RADIUS (Remote Authentication Dial-In User Service) protocol, which has been a cornerstone of network security for over three decades. Discovered recently, this vulnerability allows attackers to bypass authentication mechanisms and gain unauthorized access to networks, leading to potential man-in-the-middle (MitM) attacks.

Understanding RADIUS

RADIUS is a networking protocol that provides centralized authentication, authorization, and accounting (AAA) management for users who connect and use a network service. It is widely used in various applications, including internet service providers, corporate networks, and wireless networks.

The Vulnerability: CVE-2024-3596

The vulnerability, identified as CVE-2024-3596, leverages an inherent flaw in the RADIUS protocol’s MD5 Response Authenticator. This design flaw allows attackers to perform an MD5 collision attack, manipulating the integrity checks and forging authentication messages.

How the Blast-RADIUS Attack Works

The Blast-RADIUS attack exploits a critical flaw in the RADIUS (Remote Authentication Dial-In User Service) protocol, which has been widely used for network authentication since 1991. This vulnerability allows attackers to perform a man-in-the-middle (MitM) attack and gain unauthorized access by forging authentication responses. Here’s a detailed look at how this attack works:

Key Components of RADIUS

  1. Network Access Server (NAS): Acts as a client that verifies an end user’s credentials by sending RADIUS requests to a central server.
  2. RADIUS Server: Responds to NAS with Access-Accept or Access-Reject messages based on the verification of user credentials.
  3. Shared Secret: A fixed secret known only to the NAS and the RADIUS server.
  4. Request Authenticator: A 16-byte random value included in request packets.
  5. Response Authenticator: An MD5 hash value used to integrity-protect server responses.

Attack Mechanics

  1. Adversary Interception: The attacker positions themselves between the RADIUS client (NAS) and the RADIUS server. They can intercept and modify the communication.
  2. Crafting Malicious Proxy-State Attribute: The attacker injects a malicious Proxy-State attribute into a legitimate client’s Access-Request packet. This attribute is designed to be echoed back by the server in its response.
  3. MD5 Collision Attack: The attack exploits the MD5 hashing algorithm’s vulnerability to chosen-prefix collisions. Here’s a step-by-step breakdown:
    • Chosen-Prefix Collision: Given two distinct prefixes P1P1P1 and P2P2P2, the attacker computes gibberish blocks G1G1G1 and G2G2G2 such that:MD5(P1∣∣G1)=MD5(P2∣∣G2)MD5(P1||G1) = MD5(P2||G2)MD5(P1∣∣G1)=MD5(P2∣∣G2)This means that the attacker can create two different messages that result in the same MD5 hash.
    • Access-Reject and Access-Accept Collision: The attacker predicts the format of the server’s Access-Reject response and creates a fake Access-Accept response. Using the MD5 collision technique, the attacker ensures that both responses have the same MD5 hash value.
  4. Response Authenticator Forgery: The server computes the Response Authenticator using the formula:MD5(Code∣∣ID∣∣Length∣∣RequestAuthenticator∣∣PacketAttributes∣∣SharedSecret)MD5(Code || ID || Length || Request Authenticator || Packet Attributes || Shared Secret)MD5(Code∣∣ID∣∣Length∣∣RequestAuthenticator∣∣PacketAttributes∣∣SharedSecret)By including the malicious Proxy-State attribute, the attacker ensures the Response Authenticator for the fake Access-Accept matches the legitimate Access-Reject response.
  5. Packet Replacement: The attacker intercepts the server’s Access-Reject response and replaces it with the forged Access-Accept response, keeping the Response Authenticator intact.
  6. Unauthorized Access: The NAS receives the forged Access-Accept response and grants the attacker access to network resources, believing the server has authenticated them.

Detailed Attack Steps

  1. Initial Access-Request: The attacker sends an Access-Request with an arbitrary incorrect password. The request includes a random Request Authenticator value.
  2. Prediction of Access-Reject: The attacker predicts the server will respond with an Access-Reject message.
  3. MD5 Collision Computation: The attacker computes a chosen-prefix collision between the predicted Access-Reject and a forged Access-Accept response, resulting in RejectGibberish and AcceptGibberish strings.
  4. Modified Access-Request: The attacker includes RejectGibberish in the Access-Request as a Proxy-State attribute.
  5. Server Response: The server processes the request, decides to reject it, and sends an Access-Reject response with RejectGibberish and a computed Response Authenticator.
  6. Interception and Replacement: The attacker intercepts the Access-Reject, replaces it with the forged Access-Accept, and sends it to the NAS.
  7. Access Granted: The NAS verifies the Response Authenticator, which matches the forged Access-Accept, and grants network access to the attacker.

Blast-RADIUS Attack: Simple Explanation

Imagine you’re playing a game where your friend is the game master, and they have a special secret code to allow or deny people to play. This secret code is like a password that both you and your friend know, but no one else does. Now, let’s say a sneaky person wants to play the game without knowing the password. They can use a trick called the Blast-RADIUS attack to fool your friend into thinking they are allowed to play.

How the Attack Works

  1. Interception: The sneaky person (attacker) sits between you (the player) and your friend (the game master). They can see and change messages sent between you two.
  2. Fake Messages: You send a message to your friend with your name and password. The attacker catches this message and changes it a little bit by adding some special, meaningless words.
  3. Predicting Responses: The attacker knows that if the password is wrong, your friend will send a message saying “no, you can’t play.” They predict what this “no” message looks like.
  4. MD5 Collision: The attacker uses a special trick called an MD5 collision. Think of it like finding two different jigsaw puzzle pieces that fit perfectly in the same spot. They make a fake “yes, you can play” message that looks the same as the “no” message to your friend.
  5. Switching Messages: When your friend sends the “no” message back to you, the attacker catches it again and replaces it with the fake “yes” message. Since the fake message fits perfectly, your friend doesn’t realize it was changed.
  6. Gaining Access: You receive the fake “yes” message, thinking your friend has allowed you to play, even though your password was wrong.

Why It Matters

This attack is dangerous because it tricks the system into giving access to someone who shouldn’t have it. It’s like letting a stranger into your secret clubhouse because they made a fake membership card that looks real.

FreeRADIUS allows hackers to log in without credentials

Is the Blast-RADIUS Attack Practical?

The practicality of the Blast-RADIUS attack is a nuanced issue. Here’s a detailed breakdown:

Proof-of-Concept Feasibility

  • Running Time: In proof-of-concept attacks, it took between 3 to 6 minutes to compute the MD5 chosen-prefix hash collision required for the attack. This duration is longer than the typical 30- to 60-second timeouts used in practice for RADIUS authentication.
  • Parallelization: The collision algorithm used in the attack can be parallelized, meaning that with the right resources, the attack time can be significantly reduced. Hardware optimization and modern GPUs or specialized hardware like FPGAs (Field Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits) can speed up the process.
  • Resource Availability: The reported running times were based on optimizations to a 15-year-old codebase running on CPUs dating from seven to ten years ago. A well-resourced attacker could achieve much faster times by using more advanced and powerful computing resources.

Computational Cost

  • Cloud Resources: Implementing the attack on cloud resources like Amazon EC2 could drastically reduce the computation time. For instance, utilizing a c7a.48xlarge instance with 192 vCPUs or a g6.48xlarge instance with 192 vCPUs and 8 NVIDIA L4 GPUs could increase the speed of the attack, with an estimated cost of around $50 per hour to exceed the computing capacity used in the proof-of-concept.

Practical Constraints

  • Timeouts: The typical 30- to 60-second timeouts for RADIUS responses present a challenge, as the proof-of-concept times exceeded these limits. However, with optimized resources, this barrier can potentially be overcome.
  • Network Access: The attacker needs to be in a position to act as a man-in-the-middle on the network between the RADIUS client and server. This requires significant network access, which may not always be practical or achievable without compromising other parts of the network first.

Who is Affected by These Vulnerabilities?

The Blast-RADIUS vulnerability affects nearly all RADIUS (Remote Authentication Dial-In User Service) implementations using non-EAP (Extensible Authentication Protocol) authentication methods over UDP (User Datagram Protocol). This includes:

  • Enterprise Networks: RADIUS is commonly used to authenticate access to switches and other network infrastructure.
  • VPN Access: Virtual Private Networks often use RADIUS for authentication.
  • Internet Service Providers (ISPs): For DSL (Digital Subscriber Line) and FTTH (Fiber to the Home) services.
  • Wi-Fi Authentication: Used in 802.1X and various wireless authentication scenarios.
  • Cellular Networks: 2G, 3G cellular roaming, 5G DNN (Data Network Name) authentication.
  • Mobile Wi-Fi Offload: Authentication using SIM cards.
  • Critical Infrastructure Access: Including industrial control systems.
  • Eduroam and OpenRoaming: Wi-Fi consortia for educational and public networks.

End users cannot protect themselves directly against this vulnerability; the responsibility lies with system administrators and network operators.

Can I Detect Whether This Attack Was Run on My Network?

Yes, it is possible to detect this attack, but it requires specific log files and analysis:

  1. Log Files: You need detailed log files of Access-Rejects on the RADIUS server and Access-Accepts on the RADIUS client.
  2. Suspicious Proxy-State Attributes: Look for Access-Accept packets with Proxy-State attributes containing random bytes in the client logs. This could indicate an attack, as end clients should not receive packets with Proxy-State attributes.
  3. Comparing Logs: Find the corresponding Access-Reject response packet in the RADIUS server logs. Verify that the server’s response differs from the response received by the client, and that both contain valid Response Authenticator values for the request ID and Request Authenticator.
  4. MD5 Hash Check: If both packets produce the same MD5 hash in the Response Authenticator, it indicates that the vulnerability was exploited.

How Can We Mitigate This Attack in Our System?

To mitigate the Blast-RADIUS attack, follow these recommended countermeasures:

Short-Term Mitigation

  • Message-Authenticator Attributes: Ensure that clients and servers always send and require Message-Authenticator attributes for all requests and responses. For Access-Accept or Access-Reject responses, include the Message-Authenticator as the first attribute.

Long-Term Mitigation

  • Encrypted Channels: Use RADIUS inside an encrypted and authenticated channel that offers modern cryptographic security guarantees. The IETF (Internet Engineering Task Force) is working on standardizing RADIUS over (D)TLS (Datagram Transport Layer Security).

Additional Steps

  • Apply Patches: Check with RADIUS vendors for patches implementing these mitigations and apply them.
  • Configuration Changes: Configure both clients and servers to require Message-Authenticator attributes in all communications.
  • Transition to Modern Protocols: Plan to migrate to using RADIUS over (D)TLS or similar secure transport mechanisms as they become standardized and supported.

For more detailed guidance, consult the white paper authored by Alan DeKok of FreeRADIUS and the mitigation section on Blast-RADIUS.