Reilly <<rich.friedeman@anixter.com>
Remote Authentication Dial In User Services (RADIUS) is an increasingly
widespread authentication and accounting method defined by RFCs 2138 and
2139. The sole method of authentication between a RADIUS client
(generally a Network Access Server) and a RADIUS server which is not
plainly visible on the network is a shared secret. While this shared
secret is never transmitted across the network, it is often used in the
user-password hiding process and always in the server's response
authentication. Through packet capture and exploitation of the fact that
the shared secret is the only unknown present, the shared secret can be
recovered. This has extremely significant implications.
It should be noted that this process directly compromises the RADIUS
clients and servers themselves rather than the user passwords used to
authenticate against those servers. While user passwords can generally
be recovered after a RADIUS client and server have been compromised, that
is of secondary consideration here.
Scope
A basic understanding of RADIUS authentication and accounting is assumed.
Readers should refer to RFCs 2138 and 2139 for details beyond the scope
of this document
Authentication for standard SLIP, PPP, telnet etc. sessions as are
commonly defined in RADIUS dictionaries is assumed. Use of RADIUS to
provide direct authentication for, say, Unix logins, Windows NT domains
or Netware NDS trees could entail proprietary encoding which may be seen
as materially altering the RADIUS authentication process and lies beyond
the scope of this document
The RADIUS Packet
A summary of the RADIUS data format is shown below. The fields are
transmitted from left to right. (1)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
The code field contains the packet type. The codes significant to this
paper are: (1)
1 Access-Request
2 Access-Accept
3 Access-Reject
4 Accounting-Request
5 Accounting Response
11 Access-Challenge
The identifier is a session ID used to match requests and replies.
The Authenticator, for purposes of shared secret recovery, is a 16 byte
number which should be unique over the life of a shared secret. It is
used in authentication process between client and server (as opposed to
the ultimate authentication of the user) and in the user-password hiding
process.
The RADIUS Access-Request with plaintext passwords and PAP
When a user connects to a RADIUS client (NAS), the client issues a single
Access-Request packet. The client generates the pseudo random request
authenticator, takes the password entered by the user, and performs the
following calculation:
Call the shared secret S and the pseudo-random 128-bit Request
Authenticator RA. Break the password into 16-octet chunks p1,
p2,
etc. with the last one padded at the end with nulls to a
16-octet
boundary. Call the ciphertext blocks c(1), c(2), etc. We'll
need
intermediate values b1, b2, etc.
b1 = MD5(S + RA) c(1) = p1 xor b1
b2 = MD5(S + c(1)) c(2) = p2 xor b2
. .
. .
. .
bi = MD5(S + c(i-1)) c(i) = pi xor bi
The String will contain c(1)+c(2)+...+c(i) where + denotes
concatenation.
On receipt, the process is reversed to yield the original
password. (1)
The result of this calculation is used as the value of the User-Password
attribute.
It should be noted that the value generated for the request authenticator
is used to calculate, but is distinct from, the response authenticator.
Shared Secret Recovery with plaintext passwords and PAP
Recovery of the shared secret is a simple, though computationally
demanding process. A user connects to the RADIUS client (NAS) using a
null or a known password. The Access-Request sent by the client is
obtained through packet capture. Because either a null or known password
is used, the value MD5(S + RA) can be extracted from the User-Password
attribute. As the value RA is visible in plaintext earlier in the
captured packet, the only remaining unknown is the shared secret S which
can be obtained through a brute force dictionary attack. With sufficient
computational time, the shared secret will be recovered.
The RADIUS Response Authenticator and CHAP
The process previously outlined assumes a null or known password is used
and that a User-Password attribute is present. In the case of CHAP
authentication, the CHAP-Password attribute takes the place of
User-Password. Because CHAP is itself a password hiding process, the
client simply transmits the CHAP response in the Access-Request and does
not use the shared secret. Depending on implementation, the request
authenticator may be used as the CHAP challenge.
Because the shared secret is not used in encoding the CHAP-Password
value, the shared secret must be recovered elsewhere. In the user
authentication process, the RADIUS server's response (either an
Access-Accept, Access-Reject or Access-Challenge) to the client is
authenticated with the response authenticator. This 16 byte value
resides in the Authenticator field of the RADIUS packet and is calculated
with:
MD5(Code+ID+Length+RequestAuthenticator+Attributes+Secret), where +
denotes concatenation.
Each of these values is visible in plaintext in the response packet with
the exception of the shared secret and the request authenticator. The
request authenticator, however, is visible in the preceding
Access-Request packet.
By taking the appropriate values from the Access-Request and the
corresponding response, the shared secret can be subject to a nearly
identical dictionary attack as in the method outlined for plaintext and
PAP passwords.
It should be noted that this is a general purpose method and clearly in
no way limited to the case of CHAP authentication. It is outlined
separately as it is required in the case of CHAP and demands that more of
the exchange between RADIUS client and server be available for
inspection.
Third Party Authenticators
One of the capabilities that has made RADIUS attractive is its ability to
provide a standard front end interface to third party authentication
methods. Authentication against third party databases (external
username/password databases, token authentication, etc.) does not
materially affect the process of shared secret recovery. As seen in the
recovery method outlined for CHAP, knowledge of the actual password
transmitted is not necessary to obtain the shared secret.
Implications
The ability to obtain user passwords is a serious concern. The ability
to obtain the shared secret is disastrous to the entire remote access
security structure. With the shared secret it is possible to:
Permit unauthorized users access to the network by issuing apparently
valid Access-Accept packets. This will even allow strong token based
challenge-response authentication to be bypassed. A valid username is
not even required.
Reject or modify the access of legitimate users. By issuing apparently
valid Access-Reject packets or by issuing apparently valid Access-Accepts
which include attributes that restrict user access, significantly fine
tuned denial of service can be achieved.
Flood a RADIUS server with apparently valid Access-Request packets,
making it unavailable to legitimate client requests, producing a denial
of service.
Produce fraudulent RADIUS accounting records. This can have direct and
profound financial impact, as RADIUS accounting is often used for billing
purposes.
Circumvent challenge/response authentication by issuing apparently valid
previously known Access-Challenge packets.
Each of these possible exploitations requires successful address spoofing
to effectively impersonate either the RADIUS client or server. There are
currently publicly available tools which make address spoofing a
relatively simple matter.
Preventative Measures
The easiest way to effectively prevent this sort of attack is to first
choose good shared secrets of at least 16 characters (as recommended in
the RFC) and second, to change them periodically. If the shared secret
is sufficiently large and unguessable that it cannot be recovered before
it is changed, the entire RADIUS environment remains intact from these
attacks. Having a different shared secret for each RADIUS client will
also limit the range of an attack should one of the shared secrets be
obtained by an attacker.
Summary
While not necessarily a weakness in the RADIUS protocol per se, this
document outlines a method that can be used to compromise a RADIUS system
that has been subject to poor administration. With good, conscientious
administration RADIUS remains quite secure. With poor administration,
however, it becomes a house of cards which can be toppled by a single,
relatively unsophisticated attack.
Acknowledgements
Thanks to Sluggo, Mudge, Hobbit, and Dominique Brezinski.
Bibliography
(1) RFC 2138, Remote Authentication Dial In User Service (RADIUS), C.
Rigney, A. Rubens, W. Simpson, S. Willens, April 1997
(2) RFC 2139, RADIUS Accounting, C. Rigney, April 1997
(3) RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP), W.
Simpson, August 1996
</bigger>