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: | Re: Cisco PIX / CS ACS: Downloadable RADIUS ACLs vulnerability |
|---|---|
| Date: | Thu, 22 Dec 2005 18:37:01 +0300 |
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/
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | CYBSEC - Security Advisory: httprint Multiple Vulnerabilities, Mariano Nuñez Di Croce |
|---|---|
| Next by Date: | Re: [Full-disclosure] Privilege escalation in McAfee VirusScanEnterprise 8.0i (patch 11) and CMA 3.5 (patch 5), Steven Rakick |
| Previous by Thread: | Cisco PIX / CS ACS: Downloadable RADIUS ACLs vulnerability, ovt |
| Next by Thread: | [Full-disclosure] [USN-231-1] Linux kernel vulnerabilities, Martin Pitt |
| Indexes: | [Date] [Thread] [Top] [All Lists] |