[15249] in bugtraq
Potential DoS Attack on RSA's ACE/Server
daemon@ATHENA.MIT.EDU (JJ Gray)
Thu Jun 8 13:44:02 2000
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0111_01BFD154.8906B740"
Message-Id: <011a01bfd14c$3c206960$050010ac@xtranet.co.uk>
Date: Thu, 8 Jun 2000 14:19:19 +0100
Reply-To: JJ Gray <nexus@PATROL.I-WAY.CO.UK>
From: JJ Gray <nexus@PATROL.I-WAY.CO.UK>
X-To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
To: BUGTRAQ@SECURITYFOCUS.COM
This is a multi-part message in MIME format.
------=_NextPart_000_0111_01BFD154.8906B740
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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. I know =
of a number of ACE/Server installations that have no protection for =
their ACE/Server, nor are they hardened in any way.
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.
------=_NextPart_000_0111_01BFD154.8906B740
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3013.2600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hi folks,</FONT></DIV>
<DIV><FONT size=3D2> RSA Security <A=20
href=3D"http://www.rsasecurity.com/">http://www.rsasecurity.com/</A> =
;produce=20
a 2 factor secure authentication solution called ACE/Server. =
This=20
uses SecurID tokens to enforce authentication and runs on =
NT/2000 and=20
Solaris.</FONT></DIV>
<DIV><FONT size=3D2>It is possible for a nonprivileged user on the same =
network as=20
the ACE/Server to trivially produce a DoS attack that kills the =
aceserver=20
process thus denying all authentication requests.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Test Lab : ACE/Server version 3.1 and 4.1 on Solaris =
2.6,=20
Sparc Ultra5</FONT></DIV>
<DIV><FONT size=3D2>( For one reason and another I don't have the time =
to test=20
this on NT, if someone could attempt to replicate this attack, it would =
be=20
appreciated ;-) )</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Attack : A simple UDP portflooding at LAN speeds =
(250=20
packets/second) with randomly sized UDP packets at the port used for=20
authentication requests, default is 5500,UDP. Process dies =
in 15-20=20
seconds.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Result : The aceserver process dies and can no =
longer process=20
any SecurID authentication requests, denying all access to any SecurID =
protected=20
resources. The aceserver process has to be stopped/started =
to=20
restore functionality.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Vendor Status : Contacted, response :</FONT></DIV>
<DIV><FONT size=3D2>"<FONT size=3D2>With regards to your DoS query we =
don't see this=20
as a problem due to the fact that the ACE/Server should be in a 'secure' =
area=20
where people cannot send a large number of packets to it. The more =
likely=20
problem is to do with a DoS attack on a client (which is not in a secure =
area).=20
If it is ok with you I shall close the case."</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Solution : It is mentioned in the ACE/Server =
documentation=20
that it should be secured, however the only effective way to protect =
against=20
this attack would be to put the ACE/Server on a DMZ or equivalent and =
restrict=20
traffic to the ACE/Server ports from specific ACE/Clients only, however =
this is=20
not mentioned in their security requirements. I know of a =
number of=20
ACE/Server installations that have no protection for their ACE/Server,=20
nor are they hardened in any way.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>RSA Security do not consider this attack to be a=20
problem. I disagree as the end result could be that a =
nonprivelidged=20
user can deny all legitimate authentication requests to all SecurID =
protected=20
resources. I take the view that Administrators should be =
able to=20
decide for themselves whether or not this is a threat, hence this=20
post.</FONT></DIV>
<DIV><FONT size=3D2>( This has been posted to BugTraq and NTBugtraq (as =
there is=20
an NT version), feel free to distribute anywhere but please keep the =
post=20
intact, cheers. )</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Regards,</FONT></DIV>
<DIV><FONT size=3D2> =
JJ</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>JJ Gray, Security Analyst</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Sed quis custodiet ipsos custodes ?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>PGP Key available.</FONT></DIV></BODY></HTML>
------=_NextPart_000_0111_01BFD154.8906B740--
