[NEWS] Cisco 802.1x Voice-Enabled Interfaces Allow Anonymous Voice VLAN Access

From: SecuriTeam (support_at_securiteam.com)
Date: 06/20/05

  • Next message: SecuriTeam: "[NEWS] Cisco VPN Concentrator Groupname Enumeration Vulnerability"
    To: list@securiteam.com
    Date: 20 Jun 2005 10:22:52 +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.

    - - - - - - - - -

      Cisco 802.1x Voice-Enabled Interfaces Allow Anonymous Voice VLAN Access


    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.


    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

     * Configure DHCP snooping to lower the risk of DHCP server spoofing

     * 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

    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

    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 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 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

    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

    2. Plug a machine that supports 802.1q trunking directly into the

    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.


    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: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com


    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.

  • Next message: SecuriTeam: "[NEWS] Cisco VPN Concentrator Groupname Enumeration Vulnerability"

    Relevant Pages

    • [Full-disclosure] Voice VLAN Access/Abuse
      ... Cisco switches that support both 802.1x security and Cisco IP Phones have the ability to differentiate ... Unfortunately access to the voice VLAN cannot be so securely authenticated ... switch which opens access to the voice VLAN for frames originating from that Cisco IP Phone's MAC ...
    • Re: Pilot - Nortel VoIP phones connecting to Cisco 6500
      ... Sounds like you are embarking on a similar venture to us. ... rolling out the I.P. phones themselves due to the Data Network Team's ... applied to each Cisco Data Switch to allow DHCP to work. ...
    • Re: Pilot - Nortel VoIP phones connecting to Cisco 6500
      ... guides that speak to how Nortel VoIP phones interact with Cisco ... and anything daisy chained off goes in a voice vlan. ...
    • (OT) vlans and cisco switches and dhcp to my system
      ... Cisco switches aren't my forte. ... That switch is running to offices for Cisco IP phones, ... The response I got was that the phones are on a separate VLAN. ...
    • Re: cisco 7960 POE on linksys SRW 244 P
      ... The following Cisco IP Phones have been tested by Linksys and are: ... when connected to the SRW224P switch. ... Because these Cisco IP Phone models are not IEEE 802.3af compliant: ...