Cisco IOS Firewall Authentication Proxy for FTP and Telnet Sessions Buffer Overflow

Introduction
Firewall Authentication Proxy Feature
  Firewall Authentication Proxy
  Firewall Authentication Proxy for FTP and Telnet Sessions
  Cisco Secure ACS for Windows (TACACS+) Server Profile
Workarounds and Mitigations
  Workarounds
  Mitigations
Conclusion
Acknowledgments

Introduction

Cisco Systems has released Cisco Security Advisory: Cisco IOS Firewall Authentication Proxy for FTP and Telnet Sessions Buffer Overflow. The advisory is posted at https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-20050907-auth_proxy.html

This paper describes the Firewall Authentication Proxy (Auth-Proxy) feature and discusses the workarounds and mitigations identified in the advisory.

Firewall Authentication Proxy Feature

Firewall Authentication Proxy

The firewall authentication proxy feature allows network administrators to apply specific security policies on a per-user basis. Previously, user identity and related authorized access were associated with a user's IP address, or a single security policy had to be applied to an entire user group or subnet. Now, users can be identified and authorized on the basis of their per-user policy, and access privileges tailored on an individual basis are possible.

With the authentication proxy feature, users can log into the network or access the Internet via HTTP, and their specific access profiles are automatically retrieved and applied from a CiscoSecure Access Control Server (ACS) or other RADIUS or TACACS+ authentication server.

The authentication proxy is compatible with other Cisco IOS security features such as Network Address Translation (NAT), Context-Based Access Control (CBAC), IP Security (IPSec) encryption, and VPN client software.

Additional information is available in Authentication Proxy Configuration Guide, Cisco IOS Release 15M&T at https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_auth/configuration/15-mt/sec-usr-auth-15-mt-book/sec-cfg-authen-prxy.html

Firewall Authentication Proxy for FTP and Telnet Sessions

Before the introduction of the Firewall Authentication Proxy for FTP and Telnet Sessions feature, users could enable only HTTP when configuring authentication proxy. This feature introduces support for FTP and Telnet, providing users with three protocol options when configuring authentication proxy. This feature was first introduced in Cisco IOS Software versions 12.3(1), 12.2ZL, and 12.2ZH.

As with HTTP, the authentication proxy router intercepts traffic that is sent from the client host. Upon receiving an FTP or Telnet packet, the router will look into its authentication cache to check whether the client host has already been authenticated. If it has been authenticated, the router will forward the client host's traffic to the FTP or Telnet server for additional authentication. If the IP address of the client host is not in the cache of the router, the router will try to authenticate the client host with the AAA server using the username and password of the router.

Figure 1. Typical Authentication Proxy Topology

Additional information is available in Firewall Authentication Proxy for FTP and Telnet Sessions at https://www.cisco.com/c/en/us/td/docs/ios/sec_user_services/configuration/guide/12_4/sec_securing_user_services_12-4_book/sec_fwall_auth_ftp.html

Cisco Secure ACS for Windows (TACACS+) Server Profile

Cisco Secure server profiles for auth proxy and a description of what the user sees when auth-proxy is in use are available at Implementing Authentication Proxy at http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a0080094eb0.shtml

The Cisco Secure Windows (TACACS+) server profile authentication proxy for Telnet and FTP sessions is slightly different from the HTTP authentication proxy server profile. The following steps implement this server profile:

1. From the Cisco Secure ACS Homepage select Interface Configuration.

2. From Interface Configuration select TACACS+ (Cisco IOS).

3. Under New Services, select the Group option and type "auth-proxy" in the Service column and type "ip" the Protocol column. The Protocol column setting is the difference between the Telnet and FTP server profile and the HTTP server profile. This step is shown in the figure below:

Figure 2. ACS Interface Configuration

4. In Group Setup select the user group to Edit Settings.

5. In Group Setup for the selected group check "auth-proxy ip" and enter the priv-lvl and proxy access-lists (proxyacl) entries for this group. A text example and example figure are shown below:

priv-lvl=15
proxyacl#1=permit icmp any any
proxyacl#2=permit tcp any any
proxyacl#3=permit udp any any

These proxy access-list entries are installed at the top of the access-list applied inbound on the interface configured for auth-proxy authentication. The IP source any is converted to the actual host IP address of the auth-proxy authenticated user. For example, if a user authenticated from 10.1.1.1, the above three proxy access-lists entries would be applied to the interface access-list as:

permit icmp host 10.1.1.1 any
permit tcp host 10.1.1.1 any
permit udp host 10.1.1.1 any

Note: The proxyacl entries are examples only and should be modified for your network.

Figure 3. ACS Group Setup

Workarounds and Mitigations

Workarounds

If software cannot be upgraded to a fixed version, either of these workarounds can be implemented to eliminate exposure to the vulnerability.

Please note that in order to exploit this vulnerability an attacker must first complete a TCP connection to the Cisco IOS device running affected software and receive an auth-proxy authentication prompt.

Disable Cisco IOS Firewall Authentication Proxy Feature for Telnet/FTP Sessions

In networks where the Cisco IOS Firewall Authentication Proxy feature for Telnet/FTP sessions is enabled but not required, disabling the feature on the IOS device will eliminate exposure to this vulnerability. Disable this feature by issuing the command: no ip auth-proxy name <auth-proxy-name> {ftp | telnet}. In this example the auth-proxy-name is "tel-ftp-proxy":

! Disable ftp auth-proxy
no ip auth-proxy name tel-ftp-proxy ftp
! Disable telnet auth-proxy
no ip auth-proxy name tel-ftp-proxy telnet

Deploy Cisco IOS Firewall Authentication Proxy Feature for HTTP/HTTPS Sessions

Configure the device to use the Cisco IOS Firewall Authentication Proxy feature for HTTP/HTTPS sessions and allow the Telnet and FTP services within the per-user TACACS+/RADIUS profile.

Note: The Authentication Proxy feature for Telnet/FTP sessions must also be disabled as shown in the above workaround to eliminate exposure to the vulnerability.

An example of the configuration statements for HTTP session auth-proxy is:

! Configure auth-proxy for http session authentication
ip auth-proxy name http-proxy http
! Configure the router's web server to service auth-proxy authentication attempts
ip http server
! Set the HTTP server authentication method to AAA
ip http authentication aaa

After successful authentication via HTTP/HTTPS, the user can initiate required FTP or Telnet sessions.

The Cisco Secure Windows (TACACS+) server profile Group setting below allows FTP and Telnet as part of access-list entry proxyacl#2=permit tcp any any

priv-lvl=15
proxyacl#1=permit icmp any any
proxyacl#2=permit tcp any any
proxyacl#3=permit udp any any

Mitigations

If the workarounds cannot be applied and software cannot be upgraded to a fixed version, the features shown below can be used to reduce exposure to this vulnerability. Because users on trusted networks could still exploit the vulnerability, these mitigations cannot completely eliminate the vulnerability.

Configure Firewall Authentication Proxy Access Lists (ACLs)

Deploying IP access-lists can mitigate the effects of this vulnerability by allowing Firewall Authentication Proxy access only from trusted subnets. This feature must be used in conjunction with interface access-lists to ensure that IP traffic from untrusted subnets is dropped by the router and not forwarded around the auth-proxy feature.

Once the IP access-list is created, it is applied to the authentication proxy by adding the keyword list followed by the IP access-list name or number. In the example below, the trusted network is 169.160.160.0/24 and the auth-proxy router interface is 10.66.65.47.

! Permit trusted network 169.160.160.0/24 to access auth-proxy
access-list 105 permit tcp 169.160.160.0 0.0.0.255 any eq telnet
!
! Deny all IP traffic that is not authenticated by auth-proxy
! Note: Management and Control traffic to the router itself would
! need to be allowed in this access-list
access-list 106 deny ip any any
!
! Modify the telnet auth-proxy config to use access-list 105
ip auth-proxy name tel-proxy telnet inactivity-time 60 list 105
!
! Apply interface access-list 106 and auth-proxy test
interface FastEthernet1/0
ip address 10.66.65.47 255.255.255.0
ip access-group 106 in
ip auth-proxy tel-proxy

For further information on creating IP access lists, see:

Protecting Your Core: Infrastructure Protection Access Control Lists: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml
Transit Access Control Lists: Filtering at Your Edge: https://www.cisco.com/c/en/us/support/docs/ip/access-lists/44541-tacl.html

Control Plane Policing

The Control Plane Policing (CoPP) feature can be used to mitigate the effects of this vulnerability by allowing only trusted hosts to attempt connections through the auth-proxy router.

Care must be taken to ensure that legitimate management connections to the auth-proxy router itself are not dropped by the CoPP policy.

In the following example trusted management host 169.160.160.1 is allowed to establish Telnet connections to the auth-proxy router itself. Trusted network 169.160.160.0/24 is allowed to attempt FTP and Telnet auth-proxy connections to IP networks and addresses other than the auth-proxy router itself. All other inbound FTP and Telnet connections attempts are denied.

The auth-proxy router's IP addresses are 172.16.1.1 (Internet Side), 1.1.1.1/24 (Loopback) and 10.66.65.47 (Internal). The ACS server is 10.66.79.229.

! Do not police Telnet from trusted management host 169.160.160.1
! to the auth-proxy router
access-list 101 deny tcp host 169.160.160.1 host 172.16.1.1 eq telnet
access-list 101 deny tcp host 169.160.160.1 host 1.1.1.1 eq telnet
access-list 101 deny tcp host 169.160.160.1 host 10.66.65.47 eq telnet
!
! Police all other telnet and ftp connections to the auth-proxy router
access-list 101 permit tcp any host 172.16.1.1 eq telnet
access-list 101 permit tcp any host 1.1.1.1 eq telnet
access-list 101 permit tcp any host 10.66.65.47 eq telnet
access-list 101 permit tcp any host 172.16.1.1 eq ftp
access-list 101 permit tcp any host 1.1.1.1 eq ftp
access-list 101 permit tcp any host 10.66.65.47 eq ftp
!
! Allow telnet and ftp auth-proxy for trusted network 169.160.160.0/24
access-list 101 deny tcp 169.160.160.0 0.0.0.255 any eq telnet
access-list 101 deny tcp 169.160.160.0 0.0.0.255 any eq ftp
!
! Allow auth-proxy router to proxy connections back to trusted network 169.160.160.0/24
access-list 101 deny tcp any 169.160.160.0 0.0.0.255
!
! Allow TACACS+ from ACS server 10.66.79.229
access-list 101 deny tcp host 10.66.79.229 gt 1023 host 10.66.65.47 eq 49
access-list 101 deny tcp host 10.66.79.229 eq 49 host 10.66.65.47 gt 1023
!
! Police all TCP based management traffic from untrusted hosts to the router itself
! Note: If BGP is configured it would need to be allowed before this access-list entry
access-list 101 permit tcp any any
!
! Do not police any other types of traffic going to the router itself
access-list 101 deny ip any any
!
! Configure CoPP class-map to match access-list 101
class-map match-all only-allow-trusted-hosts
match access-group 101
!
! Configure CoPP policy-map to use configured class-map
policy-map control-plane-policy
! Drop all traffic that matches the class "only-allow-trusted-hosts"
class only-allow-trusted-hosts
drop
!
! Configure the Control-plane interface to use policy-map control-plane-policy
control-plane
service-policy input control-plane-policy

Note: CoPP is available only in Cisco IOS release trains 12.0S, 12.2S and 12.3T. Additional information on the configuration and use of the CoPP feature can be found in Control Plane Policing at https://www.cisco.com/c/en/us/td/docs/ios/12_2sb/feature/guide/cpp.html

Transit Access Control Lists

Additional mitigation can be added by Transit ACLs (TACLs) that filter transit and edge traffic at network ingress points. Transit ACLs should be configured so that IP traffic is only allowed from legitimate, trusted IP addresses. For more information on TACLs, refer to Transit Access Control Lists: Filtering at Your Edge at https://www.cisco.com/c/en/us/support/docs/ip/access-lists/44541-tacl.html.

Conclusion

Following the techniques described in this paper will remove or limit a network's exposure to the Cisco IOS Firewall Authentication Proxy for FTP and Telnet Sessions Buffer Overflow. Network administrators are advised to check the Cisco security advisory for potential updates.

Acknowledgments

Randy Ivener is an Incident Response Manager in the Cisco Product Security Incident Response Team.

This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.

This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.

Cisco IOS Firewall