8.1 Vulnerabilities

It has been discovered by many that RADIUS has some fundamental flaws that may allow an attacker to compromise the integrity of a transaction. Primarily, the User -Password protection mechanism is inherently quite insecure , employing encryption and cryptographic techniques improperly. The concept of a response authenticator inside the RADIUS packet is genuinely good, but the implementation of such in the protocol is poorly designed. The Access-Request packet is not authenticatedat least as per the protocol specificationby any machine party to the transaction. The randomness of a client's generation of request authenticators is not really random enough. And finally, the shared secret is a primitive method of securing RADIUS client-to-server transactions.

Now I'll look at each of these vulnerabilities in greater detail.

8.1.1 MD5 and the Shared Secret

The shared secret is vulnerable because of the weak MD5 hash that hides the response authenticator. A hacker could easily attack the shared secret by sniffing a valid Access-Request packet and its corresponding response. He can easily get the shared secret by pre-computing the MD5 calculation from the code, ID, length, request authenticator, and attributes portion of the packets and then resuming the hash for each guess he makes.

8.1.2 The Access-Request Packet

There is no verification or authentication of the RADIUS Access-Request packet, as per the RFC specification, by default. The RADIUS server will perform a check to ensure that the message originated from an IP address listed as one of its clients , but in this day and age, spoofed IP addresses are easy to find and use. This is a serious limitation of the RADIUS protocol design.

As of now, the only workable solution is to require the presence of the Message-Authenticator attribute in all Access-Request messages. Briefly, the Message-Authenticator is the MD5 hash of the entire Access-Request message, using the client's shared secret as the key. When a RADIUS server is configured to only accept Access-Request messages with a valid Message-Authenticator attribute present, it must silently discard those packets with invalid or missing attributes. More information on the Message-Authenticator attribute can be found in Chapter 9 or in the RFC 2869.

If your implementation somehow prevents the use of the Message-Authenticator attribute, at least consider using some sort of account-lockout feature, which disables authentications after a specified number of authentication attempts within a specified time.

8.1.3 The User-Password Cipher Scheme

The way in which the User-Password attribute is handled, on a very general basis, is known as a stream cipher. A stream cipher is an encryption method that works with continuous streams of input, which is usually a stream of plain-text bits rather than fixed blocks; its opposite is a block cipher , which is an encryption method that processes input in fixed blocks of input, which are typically 64- or 128-bits long. A stream cipher generates a keystream , and this is used in the encryption: when you combine this keystream with the plain-text input stream using the XOR operation, the contents of the stream are encrypted. The generation of the keystream can be independent of the plain text and ciphertext , yielding what is termed a synchronous stream cipher, or it can depend on the data and its encryption, in which case the stream cipher is said to be self-synchronizing.

In the User-Password scheme, the first 16 octets act as a synchronous stream cipher, since the plain text input is independent of the keystream . However, after the first 16 octets, the keystream integrates the previous plain-text input and now becomes self-synchronizing. While this may seem overtly technical, the security of this cipher is questionable: the RADIUS protocol specification doesn't make clear what the requirements are for this cipher. MD5 hashes are generally meant to be cryptographic hashes, not stream ciphers. There may be a security problem in this possible misuse. Even the RADIUS RFC 2865 acknowledges this problem:

The User-Password hiding mechanism described in Section 5.2 has not been subjected to significant amounts of cryptanalysis in the published literature. Some in the IETF community are concerned that this method might not provide sufficient confidentiality protection [15] to passwords transmitted using RADIUS. Users should evaluate their threat environment and consider whether additional security mechanisms should be employed.

Unfortunately , the only way (at least using an Internet standard) to further secure the attributes and message of a RADIUS packet is to use the IPsec protocol with the encapsulated security payload (ESP) extensions and an encryption algorithm such as the triple data encryption standard (3DES). RFC 3162 describes this process in more detail.

8.1.4 The User-Password Shared Secret

Since the User-Password attribute is protected by a stream cipher, as described earlier, it's certainly possible for attackers to obtain information on the shared secret if they can sniff network traffic and try to authenticate against a RADIUS server. For example, an attacker could attempt to authenticate using a password known to him. He then receives and captures an Access-Request packet and uses a hash on a combination of the protected portion of the User-Password and the password he originally used. Once that computation is complete, he has the result of the MD5 (shared secret + request authenticator) operation. He already knows the request authenticator from his original request, so he can now use a brute-force attack on the shared secret and determine it offline.

8.1.5 The User-Password Attribute and Password Attacks

An attacker can get around any rate limits of authentication placed by the administrator of the RADIUS server because of the use of the stream cipher to protect the User-Password attribute. Here's how it works: the hacker first tries to authenticate against a RADIUS server using a known good username and a known, but probably incorrect, password. She takes the resulting Access-Request packet and figures out the MD5 result of the request authenticator + shared secret combination, as described earlier. She can then use a brute-force password attack by switching out the passwords in the packet and using the same request authenticator and shared secret. This will only work, however, if the password is less than or equal to 16 characters , since the User-Password cipher becomes self-synchronizing at the 17 ^th character by including previous ciphertext in the encryption.

8.1.6 Attacks Using the Request Authenticator

There are several possible methods of attack on using the request authenticator portion of a RADIUS packet. In reality, all security in RADIUS is based on these authenticator fields, as they serve as unique and random "identifiers" (not to be confused with the ID field of the packet) for each packet. However, the ultimate security depends on how randomly these authenticators are generated. Most of the inherent security collapses when random number generators are used with cycles that are too short or values that are repeated. In this section, I'll take a look at some of the more probable attacks a hacker could wage against your systems through the request authenticator.

8.1.6.1 Repeated request authenticators and the User-Password attribute

It is possible to generate a bank of request authenticators and corresponding User-Password attributes if a hacker can sniff traffic on the wire between a RADIUS client and RADIUS server during a transaction. He can then see if any repeated values are used for the request authenticator; if they are, he can remove the shared secret from the first 16 octets of the password. In doing this, he gets the first 16 octets of two completely unprotected passwords that are XORed together.

Now, the bottom line here is that the attacker has gotten the first 16 octets unprotected. Most passwords that users choose, unfortunately, aren't even this long; even if they were, the hacker at least has a firm basis for a later brute-force attack. The attacker can't get any information at all only if all users have random passwords of the same length, which is a policy that would likely be applied and enforced by a system administrator. For this attack, a hacker wants two different passwords of significantly different lengths. Since the lowest length password has more padding, once the hacker completes his XOR he will have non-overlapping characters of the longer password exposed with minimal effort on his part.

Another attack can occur if a hacker attempts authentication multiple times using known passwords and intercepts the associated Access-Request packets. From these packets, she can get the request authenticator and the User-Password attribute. She then XORs the known password with the captured User-Password attribute and from the result, she has a valid bank of both request-authenticator values and the MD5 (request authenticator + shared secret) values. If she continues to sniff the wire and observes an request authenticator value that matches the one in her library, she can obtain the first 16 octets of the User-Password by looking up the MD5 sum from her library and XORing it with the User-Password attribute. As well, using this library of request authenticators, the hacker could also add appropriate identifiers and server responses she obtained by sniffing the wire. She could then masquerade as the server and replay the old server responses when an appropriate Access-Request packet came through.

8.1.6.2 Shared secrets

The use of a shared secret in the RADIUS protocol is one of the worst design decisions possible within the context of network security. By default, the RADIUS protocol specification allows the same shared secret to be used among any number of clients. Because of this, from a hacker's point of view, all RADIUS clients that use the same shared secret can effectively be considered the same client for their purposes. If one client is flawed, that machine can be compromised and used to compromise other machines not inherently flawed, since the shared secret was exposed. Additionally, only ASCII characters, of which there are 94 in total, are allowed to be used in making up a shared secret. Even more stringently, the shared secret is usually limited to 16 characters or less. This makes it nearly infinitely easier for an attacker to guess the shared secret, since he has finite bounds for both the characters and the length of the secret that he is trying to guess.