RADIUS Vulnerabilities
RADIUS is known to have a set of weaknesses that are either presented in the protocol itself or caused by poor client implementation. The stateless UDP protocol itself allows easier packet forging and spoofing. The vulnerabilities shown in this section do not represent a complete list of protocol issues and are shown to highlight several methods of circumventing user authentication. Attacks can be summarized into the following categories:
Response Authenticator Attack
The Response Authenticator is primarily an MD5-based hash. If an attacker observes a valid Access-Request, Access-Accept, or Access-Reject packet sequence, he or she can launch an exhaustive offline attack on the shared secret. An attacker can compute the MD5 hash for (Code+ID+Length+RequestAuth+Attributes), as the majority of compiling parts of the Authenticator are known, and then resume it for each shared secret guess.
Password Attribute-Based Shared Secret Attack
Because of the way the User/Password credentials are protected, attackers can gain information about the shared secret if they can monitor authentication attempts. Assuming that the cracker can attempt to authenticate with a known password and then capture the resulting Access-Request packet, he or she can XOR the protected portion of the User-Password attribute with the password they provided to the client. As the Request Authenticator is known and can be found in the client's Access-Request packet, the attacker can launch an offline brute-force attack against the shared secret.
User Password-Based Attack
This is similar to the previous attack: By knowing the shared secret the attacker can successfully enumerate the user password by modifying and replaying the modified Access-Request packets. Additionally, if the server does not enforce the user-based authentication limits, this will allow the attacker to efficiently perform an exhaustive online search for the correct user password. Always remember that a strong data authentication scheme in the Access-Request packet will make this attack almost impossible.
Request Authenticator-Based Attacks
RADIUS packet security depends on the formation of the Request Authenticator field. Thus, the Request Authenticator must be unique and nonpredictable for RADIUS to be secure. However, the protocol specifications do not emphasize the importance of Authenticator generation and create a large number of implementations that sometimes lead to a poorly generated Request Authenticator. If the client uses a PRNG that repeats values or has a short cycle, this can make the protocol ineffective in the provision of a desired level of security. See the previous applied cryptography chapters to refresh your memory on PRNG's operation and testing.
Replay of Server Responses
The attacker can generate a database of Request Authenticators, identifiers, and associated server responses by periodically sniffing and intercepting the server/client traffic. When the cracker sees a request that uses a Request Authenticator matching the database entries, he or she can masquerade as the server and replay the previously observed server response. Additionally, an attacker can replay the valid-looking Access-Accept server response and successfully authenticate to the client without valid credentials.
Shared Secret Issues
The RADIUS standard permits the use of the same shared secret by many clients. This methodology is insecure, as it allows any flawed client to compromise many machines. We advise you to carefully choose the shared secret values for each of the clients and make it a nondictionary value that is difficult to guess, while preserving physical security of the client devices.
| 
