From: "Emerald" <emerald@nls.net> Subject: [Emerald] Radius Exploit Date: Fri, 22 Feb 2002 13:50:16 -0500 Message-ID: <NABBJLKKPKIHDIMKFKGCOEGBPGAB.emerald@nls.net>
Can anyone here tell me if the IEA version of radius is susceptable to the
following exploit?
Geo.
--------------
There was a report recently to the maintainers of FreeRADIUS of a
DoS attack against it. For background, FreeRADIUS is a free software
RADIUS authentication, authorization, and accounting server. [1]
The attack was launched from a Nortel Shasta BSN 5000, by a user who
flooded the NAS with PPP requests containing an invalid password, over
a DSL link. All of the PPP requests failed, as when the NAS sent an
Access-Request to the RADIUS server, it responded with an
Access-Reject response, due to the invalid password.
However, the flood of Access-Request packets caused the server to
effectively lock up while the attack was in progress. The system load
during the attack was 60. When the attack stopped, the server
resumed its normal operation.
During the attack, few other users were able to authenticate, as the
server was busy processing the flood of requests from the attack.
The code was subsequently patched so that it would wait for a
configurable time before sending an Access-Reject to the NAS. This
change caused the NAS to ignore any new PPP requests from the problem
user, until it received a response from the RADIUS server. These
changes are available in the current CVS snapshot FreeRADIUS [2], and will
be included in any subsequent release.
Nortel was contacted by the administrator of the NAS under attack,
and their apparent response was that it wasn't their job to limit
RADIUS traffic. While I can understand that approach, I would have
preferred that the NAS was part of the solution to network problems.
My examination of other freely available RADIUS implementations
indicates that most, if not all, of them would be vulnerable to the
same attack. I believe that many commercial RADIUS servers are also
vulnerable. Other NAS boxes may also contribute to the problem, by
originating non-rate-limited RADIUS packets.
Coupled with the previous message to BugTraq from
3apa3a@security.nnov.ru [3], these problems indicate a severe
vulnerability in most RADIUS implementations.
A decent method of avoiding these problems is to place the RADIUS
server on a protected network, where the traffic to it may be
controlled. Dial-up users should not be able to route packets to the
server, and packets from the Internet should not be routable to the
server. If proxying to another site across the internet is required,
then a secure transport protocol like IPSec should be used.
In such a configuration, the server will be exposed to a minimum of
possible attacks.
Alan DeKok.
References
----------
[1] FreeRADIUS: http://www.freeradius.org
[2] ftp://ftp.freeradius.org/pub/radius/CVS-snapshots/
[3] http://online.securityfocus.com/archive/1/239784
.