Cisco PIX / CS ACS: Downloadable RADIUS ACLs vulnerability

Discussion in 'Cisco' started by ovt, Dec 23, 2005.

  1. ovt

    ovt Guest

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

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

    Vulnerability:

    This basically means that everybody with a sniffer can see the username
    #ACSACL#-IP-uacl-43a97a9d which is sent over the network in clear by
    the Radius protocol from the CS ACS server to the PIX. The password of
    this user is the same as the username. If some network device is
    configured to use the very same CS ACS server for login authentication
    then the sniffed username can be used to login to this network device.

    Setting Radius IETF attribute Service-type to "Outbound" to prevent
    using this username for logins may not help: 1) it's impossible to set
    this attribute for the user #ACSACL#-IP-uacl-43a97a9d, because the user
    is not seen in the CS ACS Web interface 2) it's not always possible to
    set it for the "default" group (the user #ACSACL#-IP-uacl-43a97a9d
    always belongs to the "default" CS ACS group), because this group may
    be used for something else 3) some network devices (most notably the
    PIX firewall) ignore the Service-Type attribute (PIX firewall 6.x code
    does not support login authorization at all (!)). Cisco routers ignore
    this attribute if authorization is not configured (only authentication
    is configured).

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

    Thx,
    Oleg Tipisov,
    Moscow
     
    ovt, Dec 23, 2005
    #1
    1. Advertisements

  2. Your description of the problem is both readable and thorough. Thank
    you for taking the time to document this.
     
    Walter Roberson, Dec 23, 2005
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.