A Blast Ray Attack Exploiting a Critical Ray Flaw Could Compromise Your Network

2024-07-11 23:39:56

The Blast-RADIUS vulnerability represents a critical flaw in the Authenticated Users Dial-In Service (RADIUS) protocol, which has been a critical component of network security for over three decades. Recently discovered, this vulnerability allows attackers to bypass authentication mechanisms and gain unauthorized access to networks, potentially leading to man-in-the-middle (MitM) attacks.

What is RADIUS?

RADIUS is a network protocol that provides authentication, authorization, and centralized accounting management (AAA) for users connecting to and using a network service. It is widely used in various applications, including Internet service providers, corporate networks, and wireless networks.

The Vulnerability: CVE-2024-3596

Identified as CVE-2024-3596, this vulnerability exploits a fundamental flaw in the RADIUS protocol’s MD5 Response Authenticator. This design flaw allows attackers to perform an MD5 collision attack, manipulate integrity checks and forge authentication messages.

How the BLAST-RADIUS initiative works

The Blast-RADIUS attack exploits a critical flaw in the RADIUS 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 through authentication forge Here is a detailed explanation of how this attack works:

Key Components of RADIUS

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

Attack Mechanics

1. Adversary interception: The attacker positions himself between the RADIUS client (NAS) and the RADIUS server, intercepting and modifying the communication.
2. Creating a Malicious Proxy Attribute: The attacker injects a malicious Proxy-State attribute into a legitimate client access request, designed to be reflected by the server in its response.
3. MD5 Collision Attack: The attack exploits the vulnerability of the MD5 hash algorithm for selected prefix collisions. Here’s a step-by-step breakdown:
   • Chosen Prefix Collision: Given two distinct prefixes P1 and P2, the attacker computes gibberish blocks G1 and G2 as follows: 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-Denied and Access-Accepted Collision: The attacker predicts the format of the server’s access denial response and creates a fake access acceptance response. Using an MD5 collision technique, the attacker ensures that both responses have the same MD5 hash value.
4. Answer Authenticator Forgery: The server calculates the Response Authenticator using the formula:MD5(Code∣ID∣∣Length∣∣RequestAuthenticator∣∣PacketAttributes∣SharedSecret)MD5(Code || ID || Length || RequestAuthenticator || PacketAttributes || ||.Secret)MD5(Code∣ID∣∣Length∣∣RequestAuthenticator∣PacketAttributes∣∣SharedSecret)By including the malicious Proxy-State attribute, the attacker ensures that the Response Authenticator is false in response to legitimate access denied.
5. Pack Replacement: The attacker intercepts the server’s access denial response and replaces it with the fake access acceptance response, keeping the Response Authenticator intact.
6. Unauthorized access: The NAS receives the fake access acceptance response and grants the attacker access to network resources, believing that the server has authenticated them.

The Blast-RADIUS vulnerability has serious implications for network security because it allows attackers to gain unauthorized access to a wide variety of network devices and services. This could lead to interception of communications, injection of false data, and further penetration into network infrastructure.

Is the Blast-RADIUS Attack Practical?

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

Concept Testing Feasibility

• Execution time: In proof-of-concept attacks, it took between 3 and 6 minutes to calculate the selected prefix MD5 hash collision needed for the attack. This duration is longer than the typical 30 to 60 second intervals used in practice for RADIUS authentication.
• Parallelization: The collision algorithm used in the attack can be parallelized, which means that with the right resources, the attack time can be significantly reduced. Hardware optimization and the use of modern GPUs or specialized hardware such as FPGAs (Field Programmable Gate Arrays) or ASICs (Application Specific Integrated Circuits) can speed up the process.
• Availability of Resources: Reported runtimes were based on optimizing 15-year-old source code running on CPUs that are seven to ten years old. An attacker with enough resources could achieve much faster times using more advanced and powerful computing resources.

Cost of Computing

• Cloud Resources: Attacking cloud resources such as Amazon EC2 could significantly reduce computation time. For example, the attack speed could be increased by using a c7a.48xlarge instance with 192 vCPU or a g6.48xlarge instance with 192 vCPU and 8 NVIDIA L4 GPUs, with an estimated cost of about $50 per hour to exceed the computing capacity used in the proof of concept.

Practical Constraints

• Time Limits: Typical wait times of 30 to 60 seconds for RADIUS responses are a challenge, as proof-of-concept times exceeded these limits. However, with optimized resources, this obstacle could be overcome.
• Network Access: The attacker must be in a position that allows him to act as a man in the middle between the RADIUS client and the server. This requires significant access to the network, which may not always be practical or possible without disrupting other parts of the network first.

Who is affected by these vulnerabilities?

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

• Business 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 (ISP): 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 and 3G cellular roaming, DNN (Data Network Name) authentication in 5G.
• Wifi mobile download: Authentication using SIM cards.
• Access to Critical Infrastructure: Including industrial control systems.
• Eduroam and OpenRoaming: Wi-Fi consortia for educational and public networks.

End users cannot directly protect against this vulnerability; It is the responsibility of system administrators and network operators.

Can I detect if this attack was carried out on my network?

Yes, this attack can be detected, but requires specific logging and analysis:

1. Log Records: You need detailed log files for Access-Rejects on the RADIUS server and Access-Accepts on the RADIUS client.
2. Suspicious Proxy-State Traits: Looks for Access-Accept packets with Proxy-State attributes containing random bits in the client logs. This may indicate an attack, as end clients should not receive packets with Proxy-State attributes.
3. Log Comparison: Find the corresponding Access-Refused response packet in the RADIUS server logs. It verifies that the server response differs from the response received by the client and that there are valid Response Authenticator values ​​for both the request ID and Request Authenticator.
4. MD5 Hash Verification: If both packets produce the same MD5 hash in the Response Authenticator, it indicates that the vulnerability has been exploited.

How can we mitigate this attack on our system?

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

Short Term Relief

• Atributos Message-Authenticator: 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 within an encryption and authentication channel that offers modern cryptographic security guarantees. The IETF (Internet Engineering Task Force) is working on the standardization of RADIUS over (D)TLS (Datagram Transport Layer Security).

Additional Steps

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

For a more detailed guide, see the white paper written by Alan DeKok of FreeRADIUS and the mitigation section in Blast-RADIUS.

He is a recognized expert in mobile security and malware analysis. He studied Computer Science at NYU and started working as a cybersecurity analyst in 2003. He works actively as an anti-malware expert. He also worked for security companies like Kaspersky Lab. He also has a deep level of knowledge of mobile security and mobile vulnerabilities.

Send news tips to [email protected] or www.instagram.com/iicsorg/

You can also find us on Telegram www.t.me/noticiasciberseguro