COMMAND
RADIUS
SYSTEMS AFFECTED
Systems using RADIUS
PROBLEM
Following is based on Rich Friedman's work tittled Shared Secret
Recovery in RADIUS.
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. 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.
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.
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.
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 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.
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.
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.
Acknowledgements goes to Sluggo, Mudge, Hobbit, and Dominique
Brezinski.
SOLUTION
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.
Some work seems to be done by Dale Cook of SCIENTECH to solve
these issues, see:
http://www.livingston.com/Tech/Technotes/Security/RADIUS-RSA.shtml