Onderwerp: Cisco PIX / CS ACS: Downloadable RADIUS ACLs vulnerability

Hi!

The following is the description of the vulnerability in the Cisco implementation of downloadable ACLs, which are used by the Cisco PIX firewall authentication proxy (aka cut-through proxy) and VPN 3000 concentrators.

When an administrator creates an ACL on the Cisco Secure Access Control Server (CS ACS Radius server) it is assigned the internal name #ACSACL#-IP-uacl-<random>. For example, the name may be the following: #ACSACL#-IP-uacl-43a97a9d. The <random> is change
d by CS ACS every time the ACL is modified by the administrator. At the same time the internal hidden user with the name #ACSACL#-IP-uacl-43a97a9d and the password #ACSACL#-IP-uacl-43a97a9d (!) is created by CS ACS. This user is not seen in the CS ACS GUI

Dear ovt@redcenter.ru,

--Wednesday, December 21, 2005, 8:27:10 PM, you wrote to bugtraq@securityfocus.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/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Response
==============

This is the Cisco Product Security Incident Response Team (PSIRT)'s
response to the statements made by Oleg Tipisov in his message with
subject "Cisco PIX / CS ACS: Downloadable RADIUS ACLs vulnerability",
posted to Bugtraq on 2005-Dec-21. An archived version of this message
can be found here:

http://www.securityfocus.com/archive/1/420020

Cisco confirms the statements made by Mr. Tipisov, and has published a
Field Notice to document the vulnerability and provide solutions and
workarounds.

The Field Notice can be found at the following location:

Field Notice: FN - 61965 - CS ACS for Windows Downloadable IP Access
Control List Vulnerability

http://www.cisco.com/en/US/products/...805bf1c4.shtml

We greatly appreciate the opportunity to work with researchers on
security vulnerabilities, and welcome the opportunity to review and
assist in product reports.

Best regards,

- --

Eloy Paris
Product Security Incident Response Team (PSIRT)
Cisco Systems, Inc.
Ph: +1 919 392-9118
Cell: +1 919 349-2990
Pager: (888) 347-7178

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDtZhkagjTfAtNY9gRAqhTAKCZ2HRGCLXu86ng/jJa3uaynVNQTACglVDA
JuYN8eOPy9HdQct1yR86GWY=
=swKK
-----END PGP SIGNATURE-----