OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Potential DoS Attack on RSA's ACE/Server
From: Vin McLellan (vinSHORE.NET)
Date: Mon Jun 12 2000 - 12:05:11 CDT


        JJ Gray <nexusPATROL.I-WAY.CO.UK> wrote:

> RSA Security http://www.rsasecurity.com/ produce a 2
> factor secure authentication solution called ACE/Server.
> This uses SecurID tokens to enforce authentication and runs
> on NT/2000 and Solaris. It is possible for a nonprivileged
> user on the same network as the ACE/Server to trivially
> produce a DoS attack that kills the aceserver process thus
> denying all authentication requests.

     Could I ask you to be more specific about what you are using to
generate your DoS attacks on the ACE/Servers, Mr. Gray? Any UDP payload?
Are you using malformed UDP packets? What patches have applied to your
v.3.1 and v.4.1 ACE/Servers? Could you describe the configuration of your
respective Solaris 2.6 Ultra5 hosts, and the resources available to them?

    I'm a consultant to RSA and I've been talking with them about this
DoS report. RSA's Tech Support guys told me Friday that they had been
flooding ACE/Servers with UDP packets all day, but had been unable --
with simple flooding -- to reproduce the crash of the process that Mr.
Gray reported.

    Mr. Gray said he crashed Sparc Ultra5-based ACE/Servers, running on
Solaris 2.6, with 250 packets per second. In the RSA Tech Support lab on
Friday, they force-fed some servers with 1000 packets per second...
without reproducing the process crash he reported.

        Trivial UDP floods don't seem to do the trick.

    With enough packets, the flow can overwhelm the (default) 5500 port,
of course. That brings the SecurID authentications first to a crawl, then
a halt. In RSA's tests, however, the ACE/Server has proven to be robust
enough to ride out the flood and bounce back, a couple of minutes after
the flood stops. The ACE/Server does _not_ have to be stopped and
rebooted.

    This is what it was designed and expected to do, when the ACE/Server
is properly configured.

    Playing with various configurations, RSA techs _were_ able crash a
number of ACE/Servers, but in each case the critical factor seemed to be
insufficient resources available to the host CPUs.

        In one test Friday, insufficient memory allocated for the audit log
crashed the ACE/Server's host. In another, a flooded ACE/Server finally
crashed because its host was spinning off mail daemons galore, trying to
fire off alerts to the sysadmin.

        (Capacity planning is not a trivial problem for either U*ix or NT/2K --
particularly planning for exceptional circumstances, like a system under
flood attack -- but if that is the problem here, identifying the
bottleneck is as much a generic sysadmin issue as it is an ACE/Server
problem, per se.)

    I agree with Mr. Gray, of course, that a UDP flood attack should not
kill a critical service like user authentication. Malformed UDP packets
should not kill a critical service either.

        In some sense, however, DoS is the universal threat to any networked
process. With sheer volume, any net-accessible server can be
overwhelmed, and the 5500 port, or any other ports, temporarily blocked.

    Since ACE/Servers (and virtually all ACE/Agents) are almost always
behind a corporate firewall, this class of DoS attacks is almost
exclusively an insider threat, as I am sure most readers here realize.

    (Surely, the wholly unprotected ACE/Servers Mr. Gray reports having
seen at some SecurID-protected sites are exceedingly rare. Few network
admins would so blatently ignore both common sense and minimal "due care"
requirements. Right? <fingers crossed>)

    The solution Mr. Gray suggests -- isolating the ACE/Server in a
secured subnet (by means of firewalls or routers) so that only UDP
packets from remote ACE/Agents on the internal net will be passed on to
it -- seems to me inadequate (although I think RSA has informally
recommended just that in some environments.)

        Since remote ACE/Agents (which proxy SecurID authentication requests
from the users) must be able to reach the ACE/Server with their UDP
packets, it is very difficult to block all potential DoS threats.
Unfortunately, spoofing UPD packets so that they appear to come from the
IP addresses of legitimate ACE/Agents is not too difficult, particularly
for a technically-savvy insider.

    A firewall between the ACE/Server and the internal net will raise the
bar, but it may not completely block all DoS threats. (The next
generation ACE/Server, v. 5.0, will offer optional TCP, as well as UDP,
connections between the ACE/Server and its ACE/Agents. That will ratchet
the bar still higher -- but an insider DoS threat could persist even
then.)

    The bottom line is that an authentication server -- like any other
critical resource on your corporate network -- necessarily depends upon
the network administrator to monitor the traffic on his net with an IDS
or some equivalent device to make sure the packet flow is appropriate
and non-malevolent.

        A critical service should survive an attack, sure -- but actually
responding to a packet-level attack by evil insiders may be a bit much to
ask of the technology. (Active defenses are fraught with risks, with
self-inflicted DoS being only the most obvious.)

    I'll report back to the List if this problem can be further isolated
and identified.

        Suerte,

                _Vin

 -----Original Message-----

From: Bugtraq List <BUGTRAQsecurityfocus.com> Behalf Of JJ Gray
Sent: Thursday, June 08, 2000 9:19 AM
To: BUGTRAQsecurityfocus.com
Subject: Potential DoS Attack on RSA's ACE/Server

Hi folks,

    RSA Security http://www.rsasecurity.com/ produce a 2 factor secure
authentication solution called ACE/Server. This uses SecurID tokens to
enforce authentication and runs on NT/2000 and Solaris. It is possible
for a nonprivileged user on the same network as the ACE/Server to
trivially produce a DoS attack that kills the aceserver process thus
denying all authentication requests.

Test Lab : ACE/Server version 3.1 and 4.1 on Solaris 2.6, Sparc Ultra5

(For one reason and another I don't have the time to test this on NT, if
someone could attempt to replicate this attack, it would be appreciated
;-) )

Attack : A simple UDP portflooding at LAN speeds (250 packets/second)
with randomly sized UDP packets at the port used for authentication
requests, default is 5500,UDP. Process dies in 15-20 seconds.

Result : The aceserver process dies and can no longer process any SecurID
authentication requests, denying all access to any SecurID protected
resources. The aceserver process has to be stopped/started to restore
functionality.

Vendor Status : Contacted, response :
"With regards to your DoS query we don't see this as a problem due to the
fact that the ACE/Server should be in a 'secure' area where people cannot
send a large number of packets to it. The more likely problem is to do
with a DoS attack on a client (which is not in a secure area). If it is
ok with you I shall close the case."

Solution : It is mentioned in the ACE/Server documentation that it should
be secured, however the only effective way to protect against this attack
would be to put the ACE/Server on a DMZ or equivalent and restrict
traffic to the ACE/Server ports from specific ACE/Clients only, however
this is not mentioned in their security requirements.
RSA Security do not consider this attack to be a problem. I disagree as
the end result could be that a nonprivelidged user can deny all
legitimate authentication requests to all SecurID protected resources.
I take the view that Administrators should be able to decide for
themselves whether or not this is a threat, hence this post.
( This has been posted to BugTraq and NTBugtraq (as there is an NT
version), feel free to distribute anywhere but please keep the post
intact, cheers. )

Regards,
        JJ

JJ Gray, Security Analyst

Sed quis custodiet ipsos custodes ?

PGP Key available.