bugtraq - Re: Cisco PIX / CS ACS: Downloadable RADIUS ACLs vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1867249297.20051222183701@SECURITY.NNOV.RU>
Date: Thu, 22 Dec 2005 18:37:01 +0300
From: 3APA3A <3APA3A@...URITY.NNOV.RU>
To: ovt@...center.ru
Cc: bugtraq@...urityfocus.com
Subject: Re: Cisco PIX / CS ACS: Downloadable RADIUS ACLs vulnerability

Dear ovt@...center.ru,

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