www.blastradius.fail Open in urlscan Pro
185.199.109.153  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Toggle navigation
 * overview
 * Paper
 * Mitigation
 * FAQ
 * Research Team
 * Attack Details
 * Coverage

--------------------------------------------------------------------------------

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.

in-depth attack description


PAPER

--------------------------------------------------------------------------------

RADIUS/UDP considered harmful
Sharon Goldberg, Miro Haller, Nadia Heninger, Mike Milano, Dan Shumow, Marc
Stevens, and Adam Suhl.
To appear at USENIX Security 2024.


MITIGATION

--------------------------------------------------------------------------------

Network administrators and vendors should follow the guidance given in this
white paper authored by Alan DeKok of FreeRADIUS.

Our recommended short-term mitigation for implementers and vendors is to mandate
that clients and servers always send and require Message-Authenticator
attributes for all requests and responses. For Access-Accept or Access-Reject
responses, the Message-Authenticator should be included as the first attribute.
Patches implementing this mitigation have been implemented by all RADIUS
implementations that we are aware of. This guidance is being put into an
upcoming RADIUS RFC.

The long-term mitigation is to use RADIUS inside of an encrypted and
authenticated channel that offers modern cryptographic security guarantees. The
IETF has begun work to standardize RADIUS over (D)TLS.


Q & A

--------------------------------------------------------------------------------

WHAT SHOULD I DO ABOUT THIS ISSUE?

If you are an end user, there is nothing that you can or should do.

If you are a system administrator, then consider the following questions:

 1. Is all RADIUS traffic accounting, and only accounting? Our attack does not
    seem to be practical in that setting. You should still upgrade everything,
    but you can take your time.

 2. Are all Access-Request packets sent over RADIUS/TLS (RadSec)? The TLS should
    protect against our attack. You should still upgrade everything, but you can
    take your time.

 3. Are your RADIUS servers only doing EAP authentication, and no other kinds of
    authentication? Our attack does not seem to be practical in that setting.
    You should still upgrade everything, but you can take your time.

 4. Are the RADIUS servers only handling local requests? That is, no RADIUS
    servers in your network are doing proxying? Upgrade your RADIUS servers
    first. All server vendors have deployed a mitigation that includes a
    Message-Authenticator attribute as the first attribute of every response,
    which we believe mitigates our attack. You should still upgrade your NAS
    equipment/RADIUS clients, but this is less critical than updating servers
    immediately.

 5. For everyone else, you should upgrade your RADIUS servers immediately, then
    upgrade clients/NAS equipment where possible, and set the configuration
    flags on both sides to require Message-Authenticator attributes. The
    specific configuration is vendor-specific and you will need to consult your
    RADIUS vendor.

You can find other FAQs on the upgrade process here.

WHAT IS THE CVE NUMBER?

CERT/CC coordinated our disclosure and has assigned CVE-2024-3596 and VU#456537
to this vulnerability.

IS ATTACK CODE AVAILABLE?

We are not publishing end-to-end attack code. Our improvements to the MD5
chosen-prefix collision attack are available in the hashclash GitHub repository.

If you are a vendor or system administrator who wishes to test for this
vulnerability, a RADIUS server implementation is vulnerable if it does not
require a Message-Authenticator attribute in every client request. A RADIUS
client is vulnerable if it does not require a Message-Authenticator attribute
from every server response. See Alan DeKok’s white paper for more information.

HASN'T MD5 BEEN BROKEN FOR 20 YEARS? HOW IS THIS ATTACK NEW?

Our attack is more complex than simply applying an old MD5 collision attack.

While an MD5 hash collision was first demonstrated in 2004, it was not thought
to be possible to exploit this in the context of the RADIUS protocol. Our attack
identifies a protocol vulnerability in the way RADIUS uses MD5 that allows the
attacker to inject a malicious protocol attribute that produces a hash collision
between the server-generated Response Authenticator and the attacker’s desired
forged response packet.

In addition, because our attack is online, the attacker needs to be able to
compute a so-called chosen-prefix MD5 collision attack in minutes or seconds.
The previous best reported chosen-prefix collision attack times took hours, and
produced collisions that were not compatible with the RADIUS protocol.

We introduce several improvements in speed, space, and scaling for the existing
MD5 attacks to demonstrate that these collisions can be computed in at most
minutes and can fit within RADIUS protocol attributes.

IS YOUR ATTACK PRACTICAL?

Yes and no. In the proof-of-concept attacks described in our paper, it took us 3
to 6 minutes to compute the MD5 chosen-prefix hash collision required for the
attack. This is longer than the 30- to 60-second timeouts that are commonly used
in practice for RADIUS.

However, every step of the collision algorithm parallelizes well and is amenable
to hardware optimization, so we expect a well-resourced attacker could obtain
running times that are tens or hundreds of times faster by implementing the
attack on GPUs, FPGAs, or hardware.

Our reported running times are from optimizing some 15 year old code and running
it on a bunch of 7 to 10 year old CPUs, because this is what we have access to.
We did not think that spending further engineering effort to make MD5 collisions
faster was a good use of time when MD5 should have been abolished 20 years ago.

WHAT IS THE THREAT MODEL FOR THIS ATTACK? WHO CAN RUN IT?

Our attack requires the adversary to have network access to act as a
man-in-the-middle attacker on the connection between the victim device’s RADIUS
client and RADIUS server. When there are proxies, the attack can occur between
any hop. Our attacker will need to be able to act as a full network
man-in-the-middle who can read, intercept, block, and modify inbound and
outbound network packets.

Such access to RADIUS traffic may happen through different mechanisms. Although
sending RADIUS/UDP over the open internet is discouraged, this is still known to
happen in practice. For internal network traffic, the attacker might initially
compromise part of an enterprise network; such compromises appear frequently in
news reports and security advisories. Even if RADIUS traffic is confined to a
protected part of an internal network, configuration or routing mistakes might
unintentionally expose this traffic. An attacker with partial network access may
be able to exploit DHCP or other mechanisms to cause victim devices to send
traffic outside of a dedicated VPN.

Our adversary does not know the shared secret between the RADIUS client and
server.

OUR RADIUS TRAFFIC IS IN A SEPARATE VLAN; ARE WE SECURE AGAINST THIS ATTACK?

A current best practice for RADIUS/UDP traffic is to expose it only to a
restricted-access management VLAN within an organization. While this reduces the
attack surface and is certainly preferable to exposing UDP traffic to a broader
network or the open internet, there may still be vulnerabilities in case of a
network misconfiguration or attacker compromise of this portion of the network.

This approach is also at odds with the US Executive Branch Office of Management
and Budget’s 2022 memo, which envisions moving to systems that do not rely on
network separation for security: “A key tenet of a zero trust architecture is
that no network is implicitly considered trusted”.

WHO IS AFFECTED BY THESE VULNERABILITIES?

Nearly all RADIUS/UDP implementations are vulnerable to our protocol attack when
using non-EAP authentication methods. RADIUS is used by many organizations to
control access to a wide variety of network devices and services. Our attack
requires man-in-the-middle network access; organizations should evaluate their
own network security threat model.

RADIUS implementers, vendors, and system administrators should follow best
practices and the guidance in this document. Our attack does not compromise end
user credentials, and there is nothing that end users can do to protect against
this attack.

EAP authentication methods are protected against our attack because RFC 2869
mandates that a Message-Authenticator attribute must be present, and this
attribute is an HMAC-MD5 over the entire packet that we cannot forge. A
theoretical protocol vulnerability appears to exist, but may not be practically
exploitable. RADIUS Accounting also appears to be affected by a theoretical
protocol vulnerability that seems to be difficult to exploit in practice.

WHAT IS THE IMPACT OF YOUR ATTACKS?

An adversary exploiting our attack can escalate privileges from partial network
access to being able to log into any device that uses RADIUS for authentication,
or to assign itself arbitrary network privileges.

RADIUS is used for remote access for diverse use cases including network routers
and switches, industrial control systems, VPNs, ISPs using DSL or FTTH, Linux
Pluggable Authentication Modules, 2G and 3G cellular roaming and 5G DNN
authentication, and mobile Wi-Fi offload with SIM card-based authentication.

CAN I DETECT WHETHER THIS ATTACK WAS RUN ON MY NETWORK?

Yes, but you need log files of Access-Rejects on the RADIUS server and
Access-Accepts on the RADIUS client.

If you have detailed log files on the RADIUS client that log the values of all
attributes, you could look for suspicious Proxy-State attributes. If there are
Access-Accept packets with Proxy-State attributes consisting of random bytes,
then this might be a sign of an attack. End clients should not receive packets
with Proxy-State attributes.

To confirm an attack, you need would need to find the corresponding
Access-Reject (or any other type) response packet in the RADIUS server logs, and
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.

If both of these packets produce the same MD5 hash in the Response
Authenticator, this issue was exploited in your system.

HOW CAN WE MITIGATE THIS ATTACK IN OUR SYSTEM?

We recommend reading the detailed guide for implementors published by Alan
DeKok, the maintainer of FreeRADIUS.

Patches including the short-term mitigation described in the mitigation section
will be available from major RADIUS implementations in coordinated release with
this work; downstream vendors and network operators should check for and apply
these patches. Where an option exists to require a Message-Authenticator
attribute on all packets, this option should be enabled.

Implementers, vendors, and admins should follow the guidance in this IETF draft
to deprecate insecure practices in RADIUS to mitigate numerous other attacks; we
expect future versions to mandate Message-Authenticator attributes in more
settings.

The long-term mitigation for our attack is to use RADIUS inside of a modern
cryptographically protected transport like TLS 1.3. The IETF RADEXT working
group has existing drafts in progress outlining RADIUS/(D)TLS.

ARE YOUR RECOMMENDED MITIGATIONS BACKWARD COMPATIBLE?

It depends.

Including a Message-Authenticator attribute in every packet is backward
compatible. Unfortunately, requiring the presence of a Message-Authenticator
attribute in requests and responses may not be backward compatible with old
client or server implementations that do not have the option to include them.

Our long-term mitigation of moving to RADIUS/TLS requires clients and servers
that support TLS, as well as new configuration (like PKI) on the part of network
operators. TLS may not be supported at all on older hardware.

I HAVE A DIFFERENT IDEA FOR A MITIGATION THAT I THINK WORKS BETTER.

A number of tempting, commonly suggested countermeasures do not sufficiently
mitigate the vulnerability.


DECREASING TIMEOUTS

It is tempting to hope that simply setting a shorter client timeout would
mitigate our attack. We believe this should not be done: it decreases usability
and does not protect against our attack.

Our MD5 collisions were computed after applying some optimizations to a
15-year-old proof-of-concept codebase, which we are running on CPUs mostly
dating from seven to ten years ago, because these are the resources we have
access to. An adversary with a budget for professional engineering would be able
to decrease the computational cost of the collision by a factor of tens to
hundreds.

The most common timeout in practice is 30 seconds, and 60 seconds is commonly
recommended when multifactor authentication is involved, since shorter timeouts
could be problematic for real users.


USING TACACS+ OR DIAMETER

RADIUS is not the only protocol to suffer from the types of security issues that
we outline. TACACS+ is a popular (TCP-based) administrator login protocol for
switches that also does not meet modern cryptographic security standards. RFC
8907 was published in September 2020, and explicitly mandates that TACACS+ be
used with a secure transport. However, much like RADIUS, TACACS+ is still most
commonly used over insecure transports.

Diameter (RFC 6733) was initially designed as a successor to RADIUS, although it
never replaced RADIUS for many common use cases. It is used in 3G+ networks, and
is generally only supported in large NAS equipment used by bigger ISPs and
telecommunications providers; consumer or enterprise-grade equipment typically
only supports RADIUS.
Although Diameter was intended to replace RADIUS, the protocol itself offers no
security when used over TCP. As a result, RFC 6733 suggests that Diameter
messages should be secured using TLS or DTLS; 5G has replaced Diameter with
signaling over HTTP/2. The US government has described exploits against Diameter
targeting mobile users.


RANDOM SHARED SECRETS

Organizations can protect against dictionary attacks on the shared secret by
picking random shared secrets of sufficient length, as the runtime of such an
attack grows exponentially with the entropy of the secret. For example, this
work-in-progress IETF draft recommends shared secrets with at least 96 bits of
entropy, so an offline dictionary attack would involve on the order of 296296
MD5 compressions. However, as our attack does not try to brute force the shared
secret, choosing a strong shared secret does not affect the runtime of our
attack.


USING MULTI-FACTOR AUTHENTICATION (MFA)

Using MFA or 2FA is not a mitigation either. Our attack largely bypasses the
user authentication mechanism, and forges the accept response from the server’s
reject. MFA may be supported through multiple mechanisms within the RADIUS
protocol, including authentication protocols like PAP that are vulnerable by
default to our attack.


REJECTING PROXY-STATES

Our forged Access-Accept packets contain Proxy-State attributes that the client
is not expecting. However, having the client discard packets with unexpected
Proxy-States does not mitigate the vulnerability. First, such a mitigation would
only apply to a NAS; the Proxy-State attribute is actually used by RADIUS server
proxies and thus difficult to remove without breaking functionality.

Even if NAS clients rejected unexpected Proxy-State attributes, it would be
possible to craft colliding packets where the Access-Accept has the collision
gibberish in a different attribute such as Vendor-Specific or Reply-Message that
is likely to be accepted; the client does not need to support or attempt to
interpret the garbage attribute to be vulnerable.

The colliding Access-Reject packet would still use Proxy-State attributes, as
the server is guaranteed to include Proxy-State attributes unchanged in an
Access-Reject. For simplicity our implementation uses Proxy-States in both
colliding packets, as no RADIUS client we tested complained about the unexpected
Proxy-State.


REPLACING MD5

It is tempting to think that simply replacing MD5 in the Response Authenticator
with a secure hash function like SHA-2 or SHA-3 might be a short-term mitigation
against our attacks. However, since the RADIUS protocol does not provide for any
cryptographic agility, such a change would be incompatible with all existing
implementations, and thus be equivalent to requiring a new protocol. Given the
other security and privacy concerns with the rest of RADIUS, it would be better
at that point to redesign the entire protocol or transport.

IS USING RADIUS WITH EAP-TLS THE SAME AS RADIUS/TLS? IS EAP-TLS VULNERABLE?

EAP-TLS is not the same as RADIUS/TLS. EAP-TLS uses a TLS handshake to carry out
certificate-based authentication, but does not use TLS to encrypt the RADIUS
access request and response packets, which are still transmitted over UDP in the
clear. This is different from RADIUS/TLS, which transmits all RADIUS packets
inside of an encrypted TLS session.

In more detail, when EAP (Extensible Authentication Protocol) is used for
authentication within RADIUS, the client NAS sends a RADIUS Access-Request
packet to the RADIUS server that contains a RADIUS attribute called EAP-Message.
For RADIUS/UDP, this Access-Request is sent in the clear via UDP. The
authenticating peer and server then authenticate using the requested EAP method:
for EAP-TLS, they use certificates to complete a TLS handshake. After the end of
the EAP authentication process, the server completes the RADIUS conversation by
sending a RADIUS Access-Accept or Access-Reject packet; for RADIUS/UDP this
packet is again sent in the clear over UDP.

Our attack targets RADIUS access requests and responses. However, EAP-TLS does
not appear to be practically exploitable by our attack because all packets
containing EAP-Message attributes must contain a MD5-HMAC Message-Authenticator
attribute that we cannot forge. However, a theoretical protocol attack may still
be possible against RADIUS even when clients make an EAP-TLS (or other EAP)
authentication request. The details and the impact of such an attack would be
implementation-dependent and we have not found a practically exploitable
implementation.

A more detailed explanation is in Section 5.6 of our paper.

HOW CAN YOUR ATTACK TIME BE FURTHER REDUCED?

We reduced the online running time for our MD5 chosen-prefix attack from hours
down to minutes. However, this should be interpreted as a generous upper bound
for the true cost of such collisions, because of the limits on our computational
resources. Newer CPUs than the seven to ten year old machines we have access to
would likely provide minutes of improvement, as would optimizing cache locality.

Access to more and faster GPUs for the chosen-prefix attack would reduce the
time for the birthday stage and/or reduce the number of near-collision blocks,
reducing time for the near-collision stage.

Reimplementing hashclash in hardware, for example on FPGAs (Field Programmable
Gate Arrays) or ASICs (Application-Specific Integrated Circuits) would likely
improve the running time by a factor of ten to a hundred.

It would be eminently feasible to run this attack on cloud resources. Amazon EC2
lists the on-demand price of a c7a.48xlarge instance with 192 vCPUs at
$9.85/hour, and the price of a g6.48xlarge instance with 192 vCPUs and 8 NVIDIA
L4 GPUs at $13.35/hour. It would cost around $50/hour to exceed our computing
capacity, and in principle one could scale to many more machines.

HOW MANY RADIUS DEPLOYMENTS ARE VULNERABLE TO THIS ATTACK?

Unfortunately, we are not able to use network scanning to provide a
representative picture of RADIUS deployments. Many RADIUS servers will be on
internal networks. Even for external-facing servers, RADIUS hosts are identified
by IP address and servers only accept packets from allowed addresses. The RADIUS
RFC specifies that servers should drop requests for hosts that they have not
been pre-configured to have a shared secret with. Our scanning host would not be
whitelisted by properly configured servers, so an internet-wide scan would thus
only turn up misconfigured servers. Additionally, since it is a UDP-based
protocol with no handshake before a login request, we cannot do TCP SYN scanning
and would need to scan using a well-formed UDP Access-Request, which would
appear as an attack to network administrators.

This does not affect the adversary in our attack model, who intercepts traffic
between a legitimate client and server.

However, since this vulnerability is in the protocol, nearly all RADIUS/UDP
implementations are vulnerable to our attack when using non-EAP authentication
methods.

DO YOU HAVE A LOGO FOR YOUR ATTACK?

Of course! Various versions with transparent, white, and black background are
available here.


RESEARCH TEAM

--------------------------------------------------------------------------------

This research was conducted by

 * Sharon Goldberg (Boston University and Cloudflare),
 * Miro Haller (University of California, San Diego),
 * Nadia Heninger (University of California, San Diego),
 * Mike Milano (BastionZero),
 * Dan Shumow (Microsoft Research),
 * Marc Stevens (Centrum Wiskunde & Informatica), and
 * Adam Suhl (University of California, San Diego)



You can email us at blast.radius.attack@gmail.com

Last updated on Jul 09, 2024