Re: [Emerald] Radius Exploit

New Message Reply Date view Thread view Subject view Author view
Dale E. Reed Jr. (daler@iea-software.com)
Fri, 22 Feb 2002 11:43:15 -0800



Message-ID: <3C769F53.9060107@iea-software.com>
Date: Fri, 22 Feb 2002 11:43:15 -0800
From: "Dale E. Reed Jr." <daler@iea-software.com>
Subject: Re: [Emerald] Radius Exploit

Emerald wrote:

> Can anyone here tell me if the IEA version of radius is susceptable to the
> following exploit?

See my comments inline. Any RADIUS server is susceptable to this.
However, the real question is how does a RADIUS server cope with
it. Thats going to depend on a lot of factors.

 
> 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.

This fix may possibly prevent anyone else on the box from authenticating
during that configurable time as well. (see below for why)

 
> 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.

This, IMHO, is the real problem. You are trusting a RADIUS client
to send you RADIUS requests. How to determine which ones are good
and which are bad, present a problem. By delaying the response (or
nor responding at all), the NAS could mark your RADIUS server as
down and not send requests for valid users.

The RadiusNT/X cache should prevent this from consuming all
resources, allowing it to respond to other requests as well.

> 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.

Have you ever seen a Max TNT with a DS3 (700+ lines) have the DS3
bounced? I've seen RadiusNT/X survive that onslaught (typically it
can send 700+ requests/second when this happens...bug in the Max)
where other RADIUS servers said "core dump". So I would expect
RadiusNT/X could sustain the load until the problem was resolved.

> 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.

Althought a good idea, this is misleading WRT this problem. That
solution would have no bearing or prevention on the reported
problem here, since the requests ARE coming from a valid RADIUS client
on your network that would be allowed through.

Just to clarify, the problem noted here is NOT that the users is
attacking the RADIUS server directly. They just misconfigured their
password in their DSL router (which happens more times than you can
imgaine). If DSL routers and/or DSLAM equipment can un-intentionally
cause a DOS attack on your RADIUS server as a result of this, then
IMHO it IS the resposbility of the vendor to address the problem (ie,
Nortel). We worked with Ascend on a couple of similar issues like
this years ago, that they did come up with a workaround or solution to.

-- 

Dale E. Reed Jr. Emerald and RadiusNT/X __________________________________________ IEA Software, Inc. www.iea-software.com

.



New Message Reply Date view Thread view Subject view Author view
This archive was generated on Fri Feb 22 2002 - 11:16:54 Pacific Standard Time