OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: Cisco PIX / CS ACS: Downloadable RADIUS ACLs vulnerability

From: 3APA3A (3APA3ASECURITY.NNOV.RU)
Date: Thu Dec 22 2005 - 09:37:01 CST


Dear ovtredcenter.ru,

--Wednesday, December 21, 2005, 8:27:10 PM, you wrote to bugtraqsecurityfocus.com:

orr> Generally speaking the Radius protocol is not appropriate for
orr> doing such things as downloading ACLs or other attributes on behalf
orr> of the user on an "as-needed" basis, as it doesn't separate the
orr> authentication and authorization. Usually this leads to creation of
orr> a fake user with the password "cisco" or "<username>".
orr> Unfortunately this practice is common on Cisco devices.

 You're 100% right with your statements, but not with conclusion on
 RADIUS usability. Problem described is implementation vulnerability. Of
 cause, RADIUS was never meant to transmit large amount of data, as ACL
 may be. But this procedure can be done secure. In this scenario

orr> The protocol used by the PIX to download the ACL works as follows:
orr> 0) User goes to Internet (for example) thru the PIX via HTTP(s).
orr> PIX asks a username and a password. User enters them into the
orr> dialog window. 1) PIX sends Radius Access-Request to CS ACS to
orr> authenticate the user (the user password is encrypted by Radius).
orr> 2) Radius server authenticates the user and sends back the
orr> cisco-av-pair Vendor-specific attribute (VSA) with the value
orr> ACS:CiscoSecure-Defined-ACL=#ACSACL#-IP-uacl-43a97a9d. 3) PIX again
orr> sends Radius Access-Request to authenticate the user
orr> #ACSACL#-IP-uacl-43a97a9d. 4) Radius server authenticates the user
orr> and sends back the ACL body as another cisco-av-pair VSA attribute
orr> (ip:inacl#1= ...).

 It's possible to send ACL body on step 2 instead of 4, as it should
 according to RADIUS ideology. Of cause, for large ACL whole ACL may not
 fit in a single RADIUS reply, because RADIUS packet is limited to 4096
 bytes according to standard. Probably, in Cisco case NAS repeats steps
 3-4 instead of 1-2 and pseudo-user was implemented for performance in
 case of large ACLs, because real user authentication for each loop
 requires more resources. It's clearly Cisco specific performance vs
 security design bug. Of cause better solution is to send ACL number
 with RADIUS and receive ACL itself with i.e. TFTP.

--
~/ZARAZA
http://www.security.nnov.ru/