Re: An Analysis of the TACACS+ Protocol and its Implementations

[Alan DeKok <aland () FREERADIUS ORG>]

"Juan M. Courcoul" <courcoul () CAMPUS QRO ITESM MX> wrote:
> For those of us who have opted to use RADIUS instead of TACACS, is there
> an equivalent vulnerability analysis available somewhere ?

  I can give a quick summary, but I don't know of any such document.

  RADIUS simply has a better design than TACACS+.  Each message is
authenticated.  Messages are sent (usually) via unconnected UDP
sockets, so any TCP attacks are side-stepped.  Messages can only come
from known clients, and messages from unknown clients are ignored.
Messages contain explicit lengths, and inconsistent messages are
ignored.  The contents of messages contain attributes, with explicit
lengths, and inconsistent attributes result in the message being
ignored.

  That being said, there are a few comments I can make:

- To attack a RADIUS server, any attacker MUST be able to send packets
from a known client, and MUST be able to sign the packet.  A common
shared "secret", however, is "testing123".  I would not be surprised
if many administrators left this unchanged.

- the connectionless nature of UDP means that an attacker does NOT
have to establish a conversation with the server.  One spoofed UDP
packet is often enough.

- However, for authentication, the attacker must be able to convince a
local machine (NAS) to accept the RADIUS packet on his behalf.  This
is quite difficult...

- MD5 is used as a message authenticator.  There are known issues with
MD5, and any new implementation would probably choose SHA-1 over MD5.
However, I do not know of any MD5-based attacks on RADIUS.

- The original Livingston v1.16 server could process accounting
packets with an all-zero message authenticator.  This meant that
ANYONE on a client could send bogus accounting updates, as the
authentication was being ignored.

  Most servers now do not allow this behaviour.

- Many older implementations did not properly check the sizes of
attributes or messages, and could possibly be convinced to core dump
with carefully constructed packets.

- The original Livingston 1.16 server (used as a basis for many other
implementations) had local root exploits if it's configuration files
had open write permissions.  (See my earlier Bugtraq post).

- There seems to be little benefit other than DoS for spoofed
authentication packets.

- Spoofed accounting packets are MUCH easier to create, especially
with older servers, which can accept unsigned account packets.  One
possible mode of this attack is to log in to an ISP, and spoof an
accounting 'Stop' status message.  However, you WILL need to guess the
accounting session-ID in order for the packet to be accepted.  This is
often easy to do, as many NAS vendors have predictable methods of
choosing it.  It may then be possible to stay on-line for hours,
without being billed, if your ISP's billing software is forgiving.


  You will note that many of these problems are *implementation* dependent,
and not *protocol* dependent.  While the RADIUS protocol MAY have
security issues, I cannot recall seeing any other than the ones
mentioned above.

  And the last problem should be enough to convince administrators to
upgrade from Livingston 1.16. :)

  Alan DeKok.