From: SecuriTeam <support@securiteam.com.>
To: [email protected]
Date: 20 Jun 2005 10:22:52 +0200
Subject: [NEWS] Cisco 802.1x Voice-Enabled Interfaces Allow Anonymous Voice VLAN Access
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20050620092318.96AB1584B@mail.tyumen.ru.>
X-Virus-Scanned: antivirus-gw at tyumen.ru
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 802.1x Voice-Enabled Interfaces Allow Anonymous Voice VLAN Access
------------------------------------------------------------------------
SUMMARY
Cisco switches that support both 802.1x security and Cisco IP Phones have
the ability to differentiate between access of the voice VLAN by Cisco IP
Phones and access of the data VLAN by devices connected to the auxiliary
ports (daisy-chained) of IP Phones. Thus 802.1x port-level security can be
achieved on switch ports connected to Cisco IP Phones which are, in turn,
connected to end-user devices.
In this configuration data VLAN access provided to devices connected to IP
Phone auxiliary ports is authenticated via 802.1x. Unfortunately access to
the voice VLAN cannot be so securely authenticated due to the lack of
802.1x supplicant software in Cisco IP Phones. It has been found that a
specifically crafted Cisco Discovery Protocol (CDP) message is sent from
the Cisco IP Phone to the switch which opens access to the voice VLAN for
frames originating from that Cisco IP Phone's MAC address. Although 802.1x
port-security may be configured on the switch port voice VLAN access is
trivially gained by spoofing a CDP message.
DETAILS
Risk Mitigation:
There is no *fix* to this issue as of yet. The true resolution would be to
provide 802.1x supplicant software on IP phones such that voice VLAN and
data VLAN access are both 802.1x authenticated.
Traditionally, access to the voice VLAN of a voice-enabled system such as
is described above was provided by a switch to any device without
authentication. Cisco has provided the ability to differentiate between
phones and other devices albeit in a such away that voice VLAN access is
still trivially gained. It should be noted that this configuration is
still preferred over the old method which uses no authentication for
either VLAN. However, it is still important to note that true port-level
authentication is still not being provided.
Currently the best way to mitigate the risk introduced by unauthorized
voice VLAN access is to implement traditional security measures as well as
some of the advanced security features available in Cisco networking
equipment. Cisco CallManager 4.x and certain Cisco IP Phones now support
the authentication of phone registration through the use of certificates.
Features like this reduce the risk of unauthorized voice VLAN access if
other necessary controls are also put into place such as the following:
* Disable telnet on phones.
* Always use cryptographically secure management protocols such as SSH,
HTTPS, and SNMPv3 when possible to lower the risk of eavesdropping that
ARP poisoning and DNS manipulation attacks present.
* Disable all administrative access to network infrastructure from voice
VLAN addresses.
* Configure dynamic ARP inspection to lower the risk of ARP poisoning
attacks.
* Configure DHCP snooping to lower the risk of DHCP server spoofing
attacks.
* Configure limits on the amount of MAC addresses allowed to be connected
to a switch port. This will lower the risk of port-stealing by
overwhelming the switch CAM table.
* Configure storm control to limit the risk of a DOS attack via
non-unicast traffic.
* Configure proper filtering between voice and data networks to ensure
that even if unauthorized voice VLAN access is achieved the risk presented
by this access is less than the risk posed by unauthorized data VLAN
access.
Findings:
Cisco Systems produces many different models of switches that are 802.1x
capable. Many of these switches also provide the capability to recognize
and participate in the configuration of Cisco IP Phones. Cisco IP phones
are designed to accommodate connected workstations so that only one
network drop is required per user workspace. There are three possible base
configurations of Cisco IP phone-enabled switch ports, one of which
applies to this issue.
These phones do not contain an 802.1x supplicant, which means that user or
device credentials cannot be entered and provided to an 802.1x
authentication server. This obstacle is compounded by the fact that voice
services are usually required even in situations where there are no user
workstations connected to the phones, such as during non-business hours or
on non-workstation community phones, etc.
This means that enterprises requiring 802.1x port security and user
workstations chained to Cisco IP phones cannot rely on the users attached
to the Cisco IP phones to authenticate for both the user and the phone if
voice services are required in the absence of the user. This has lead
Cisco Systems to provide an alternative means of identifying Cisco IP
phones on 802.1x-enabled switch interfaces so that they can function
independently of data services.
This issue is dependent upon the following conditions:
* Cisco IP phones are being utilized with user workstations connected to
the PC Port of the phones.
* The switch interfaces are configured to separate voice traffic from
data traffic on different VLANs.
* 802.1x port security is enabled on the interfaces connected to the
phones.
The following configuration was used on a Cisco Catalyst 3560G-24PS-24
switch to validate the vulnerability:
aaa new-model
aaa group server radius RADIUS
server 192.168.1.100 auth-port 1812 acct-port 1813
!
aaa authentication dot1x default group tacacs+
!
interface FastEthernet0/4
switchport access vlan 100
switchport trunk native vlan 100
switchport mode access
switchport voice vlan 200
no ip address
srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape 10 0 0 0
mls qos trust device cisco-phone
mls qos trust cos
no mdix auto
dot1x port-control auto
auto qos voip cisco-phone
spanning-tree portfast
!
radius-server host 192.168.1.100 auth-port 1812 acct-port 1813 key RADk3y
Although not every Cisco switching platform has been tested due to lack of
hardware, it is assumed that this vulnerability applies to any Cisco
switch platform that supports 802.1x port security and IP phone
functionality on the same port.
FishNet Security has determined that Cisco Systems is using CDP messages
to identify Cisco IP phones and allow access to the voice VLAN independent
of the workstation's access to the data VLAN on 802.1x-secured ports.
Further testing indicated that the switches identify IP phones on
802.1x-secured ports by matching a string found in a particular field in
the CDP message that the phones generate upon connection to the
switch-port.
When a Cisco switch receives a CDP message with this particular string in
the correct CDP field on an 802.1x-secured port, it allows access to the
voice VLAN even if a user has not authenticated. Publicly available tools
can trivially subvert this means of identification by spoofing these CDP
messages to cause the port to enable access to the voice VLAN. Once this
is done network access is gained, and there are many attacks that can be
waged on the voice system if proper controls have not been put into place.
Although it is against Cisco SAFE recommendations it is common for data
VLAN hosts to be reachable from voice VLAN hosts due to poorly configured
access control. In these cases access of the voice VLAN versus the data
VLAN may be irrelevant.
The concept for the following exploit was inspired directly from a couple
of small mentions of 802.1x port security using voice-enabled ports on
Cisco System's website. It should be noted that Cisco Systems never claims
that the voice VLAN is 802.1x authenticated in its literature. However, it
does not directly state how trivial it is to gain access to the voice
VLAN, which could potentially leave system administrators with the false
impression that any access to that port from any device other than an IP
phone must be securely authenticated via 802.1x.
CDP Packet format
Version (1 byte)
Time-to-live (1 byte)
Checksum (2 bytes)
Type (2 bytes)
Length (2 bytes)
Value (variable)
Exploiting this weakness in allowing access to voice VLANs on
802.1x-secured ports involves the following steps:
1. Gain physical access to an 802.1x-secured port that is also
voice-enabled.
2. Plug a machine that supports 802.1q trunking directly into the
switch-port.
3. Passively sniff traffic until an 802.1q encapsulated frame tagged with
the VLAN ID of the voice VLAN arrives on the port.
4. Create an 802.1q subinterface to participate on this VLAN.
5. Inject two specially crafted CDP packets with the correct string placed
in the correct field. Access to the voice VLAN is now granted.
6. Inject one CDP packet every minute or so such that the CDP entry does
not time out of the connected switches CDP table.
7. Send a DHCP request on the voice VLAN in an attempt to get an address
or statically assign one if DHCP fails.
If all of this is successful then attacks can be mounted on the network
infrastructure and phone system. The TFTP server can be easily discovered
by looking at the DHCP response and spoofed such that the configurations
of all phones can be arbitrarily configured. Voice calls can be monitored
by ARP spoofing or port stealing if proper switch configuration is not
followed. The amount of attacks are virtually limitless.
ADDITIONAL INFORMATION
The information has been provided by <mailto:csirt@fishnetsecurity.com.>
CSIRT - FishNet.
The original article can be found at:
<http://www.fishnetsecurity.com/csirt/disclosure/cisco/Cisco+802.1x+Advisory.aspx> http://www.fishnetsecurity.com/csirt/disclosure/cisco/Cisco+802.1x+Advisory.aspx
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: [email protected]
In order to subscribe to the mailing list, simply forward this email to: [email protected]
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.
