Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | [NEWS] Cisco PIX / CS ACS Downloadable RADIUS ACLs |
|---|---|
| Date: | 26 Dec 2005 18:37:11 +0200 |
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com - - promotion The SecuriTeam alerts list - Free, Accurate, Independent. Get your security news from a reliable source. http://www.securiteam.com/mailinglist.html - - - - - - - - - Cisco PIX / CS ACS Downloadable RADIUS ACLs ------------------------------------------------------------------------ SUMMARY 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 (a.k.a. cut-through proxy) and VPN 3000 concentrators. DETAILS 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: 1) User goes to Internet (for example) through the PIX via HTTP(s). PIX asks a username and a password. User enters them into the dialog window. 2) PIX sends Radius Access-Request to CS ACS to authenticate the user (the user password is encrypted by Radius). 3) 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. 4) PIX again sends Radius Access-Request to authenticate the user #ACSACL#-IP-uacl-43a97a9d. 5) Radius server authenticates the user and sends back the ACL body as another cisco-av-pair VSA attribute (ip:inacl#1= ...). 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. ADDITIONAL INFORMATION The information has been provided by <mailto:ovt@redcenter.ru> Oleg Tipisov. ======================================== This bulletin is sent to members of the SecuriTeam mailing list. To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com ==================== ==================== DISCLAIMER: The information in this bulletin is provided "AS IS" without warranty of any kind. In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [EXPL] GoldenFTPd APPE Stack Overflow (Exploit), SecuriTeam |
|---|---|
| Next by Date: | [NT] McAfee VirusScan Privileges Escalation, SecuriTeam |
| Previous by Thread: | [EXPL] GoldenFTPd APPE Stack Overflow (Exploit), SecuriTeam |
| Next by Thread: | [NT] McAfee VirusScan Privileges Escalation, SecuriTeam |
| Indexes: | [Date] [Thread] [Top] [All Lists] |