RUS-CERT Advisory 2007-06:01 – Insecure Defaults in Alcatel-Lucent OmniPCX 7.0
The built-in Mini Switch in Alcatel-Lucent’s IP-Touch Telephones under OmniPCX 7.0 and later Allows Un-Authenticated Access to the Voice VLAN in IEEE 802.1x-Authenticated Environments
2007-06-07 10:54:27 UTC
Insecure default configurations in Alcatel-Lucent’s Voice-over-IP Telephone System OmniPCX Enterprise Release 7.0 and later can be exploited to gain un-authenticated access to the voice VLAN through daisy chained computer systems. By default the mini switch built into the IP Touch telephone is enabled in a configuration vulnerable to the issue described in this document. Changing the configuration in a specific way remediates the problem. The scope of this document is limited to 802.1x- and 801.1q-enabled infrastructures. In scenarios not using 802.1x authentication, access to the voice VLAN is trivial.
|Affected:||Alcatel-Lucent OmniPCX Enterprise Release 7.0 and later|
|Impact:||un-authenticated access to the Voice-VLAN|
|Vector Class:||mediately remote (see Attack Requirements for details)|
|Problem Class:||insecure defaults|
Alcatel-Lucent was contacted in 02-2007 and the publication of this announcement was co-ordinated with A-L’s PSIRT and development department.
Who Should Read this Document
- Users of Alcatel-Lucent OmniPCX Enterprise Release 7.0 and later operating Alcatel-Lucent IP Touch telephones in a network configuration that uses IEEE 802.1q (VLAN) technology to separate voice and data traffic (VLAN segmentation) and IEEE 802.1x authentication for IP Touch telephones.
- Alcatel-Lucent OmniPCX Enterprise Release 7.0 and later with IEEE 802.1x authentication enabled and default configuration for the PC port of the mini switch integrated in IP Touch telephones.
Not Affected Systems
- Alcatel-Lucent OmniPCX Enterprise Release 7.0 and later when the PC port of the IP Touch telepone’s mini switch either is configured to
- ‘disabled port’ with no daisy-chained computer system or
- ‘filtering port’ with a computer system is daisy-chained.
Note: IEEE 802.1x is not implemented in earlier versions of OmniPCX Enterprise nor on OmniPCX Office.
- Mini switch in Alcatel-Lucent IP Touch telephone when daisy-chaining a IEEE 802.1q capable computer system
- Physical access to the built-in mini switch in an Alcatel-Lucent IP Touch telephone;
In a typical configuration this will be provided by a daisy-chained computer system. If this system is compromised, the attack can be performed remotely.
- Improper configuration of the PC port state on the IP Touch’s mini switch;
This is the default.
To successfully attack an infrastructure the following extra requirements must be met:
- IEEE 801.1q VLAN segmentation must be used to separate the “voice network” from other networks
- IEEE 802.1x authentication must be enabled to authenticate telephones and control their access to the voice VLAN
Both technologies are recommended and commonly used in VoIP environments.
- Un-authenticated access to the VLAN defined to separate voice traffic from data traffic
- insecure defaults
Only installations featuring IEEE 802.1q and IEEE 802.1x to separate the voice infrastructure from other networks and IP-Touch telephones with an improperly configured built-in mini switch are affected.
See RUS-CERT’s risk and threat rating.
The Common Vulnerability Scoring System (CVSS) is an approach to provide a standardized severety rating system for software vulnerabilities.
|CVSS Base Score||7|
|CVSS Temporal Score||5.8|
|CVSS Environmental Score||6.2|
|Overall CVSS Score||6.2|
|Base Score Metrics|
|Related exploit range (AccessVector)||Remote 1)|
|Attack complexity (AccessComplexity)||Low|
|Level of authentication needed (Authentication)||Not Required|
|Confidentiality impact (ConfImpact)||Partial|
|Integrity impact (IntegImpact)||Partial|
|Availability impact (AvailImpact)||Partial|
|Impact value weighting (ImpactBias)||Weight Availability|
1) In a typical scenario with a compromised computer system that is daisy-chained to a telephone this vulnerability can be expoited remotely. A value between ‘local’ and ‘remote would fit here, something like ’mediately remote’.
Voice-over-IP telephony technology uses IP-based data networks to communicate both signalling and voice data.
A common way to separate data and voice networks is the use of VLAN (IEEE 802.1q) technology in switched networks. Alongside tagged or untagged (“default VLAN”) traffic for data of various purposes (“Data VLAN”) an extra tagged VLAN is introduced to be the telephony network (“Voice VLAN”). Besides the logical separation, this mechanism also can implement quality of service features that are necessary to provide a minimum level of speech quality within the telephone system.
VLANs are an OSI 2 mechanism and hence can be defined in switched networks where at least the switches serving clients (e.g. computers and other equipment attached to the network) must support this technology if access to the VLANs shall be controllable.
An IEEE 802.1q-capable switch can be configured to provide an arbitrary set (also sometimes called “trunk”) of the VLANs handled on a switch-port. It then provides only the traffic defined on this port and
filters all other VLANs.
Implementation of IEEE 802.1x authentication mechanisms on a switch makes it possible to decide on-the-fly if a VLAN shall be put on a port or not. In IEEE 802.1x a client system connected to the switch (supplicant) must authenticate itself to the switch (authenticator) which in turn asks a subsequent AAA server and then – depending on the server’s answer – puts the appropriate trunk containing the configured VLANs on the port.
In a VoIP scenario with IEEE 802.1x hardware authentication, telephones authenticate to the network switch they are connected to using IEEE 802.1x mechanisms. If authentication is successful the switch grants access to the Voice VLAN.
Since almost all VoIP installations use an already existing networking infrastructure, a telephone seldomly is provided with an exclusive switchport but uses the same port that is used by the PC on the desk of its user.
Therefore most physical IP-telephones feature a built-in mini switch that acts as the IEEE 802.1x supplicant to get access to the Voice VLAN. The PC is then connected (daisy chained) to the mini switch.
After successful authentication performed by the telephone’s mini switch the network switch grants access by providing a trunk containig the telephony and the data VLANs on the switch port the telephone is connected to. The telephone’s mini switch then provides the traffic running on the Voice VLAN to the telephone’s hardware and all the other traffic to the port the PC is connected to. So, the PC is getting access to the data network without seeing any traffic from the Voice VLAN.
Thus, the authentication and the correct VLAN filtering of the mini switch in the telephone prevents trivial unauthorized access to the Voice VLAN by directly connecting a PC or device to the network switch. Other than the telephone, the PC would not be able to authenticate as a telephone and hence the switch that is acting as the authenticator would not put a trunk containing the Voice VLAN on the port.
As a result, the Voice-VLAN is protected from possibly infected or otherwise compromised PCs since the mini switch in the telephone effectively can filter Voice-VLAN traffic off the trunk before it is forwarded to the daisy chained PC.
The built-in mini switch in Alcatel-Lucent IP-Touch telephones does not properly filter VLAN traffic received in multicast or broadcast mode and thus does not prevent it from being forwarded to daisy-chained equipment.
This fact effectively invalidates the IEEE 802.1x mechanism for daisy- chained devices because the daisy-chained device gets partial access to the tagged VLAN without performing an authentication. The telephone performs the authentication and then acts as a hub for a subset of the voice VLAN traffic.
If no cryptographic mechanisms are implemented, negotiations using broadcast or multicast traffic within the Voice-VLAN are done in clear text (e.g. DHCP, ARP). Hence, a daisy-chained device or PC is able to see this information.
Negotiations performed by the telephone using unicast traffic are not seen by the daisy-chained device. So, the device does not see the IP address assigned to the telephone because the DHCP server usually sends DHCPOFFER messages in unicast mode.
It also prevents daisy-chained equipment from sending tagged traffic into the voice VLAN.
Nevertheless, daisy-chained devices can determine the telephone’s hardware address by analyzing the broadcast traffic unintentionally sent from the switch. When initiating the DHCP process the telephone sends a broadcast message to the server that includes its hardware address.
A human attacker having physical access to the telephone can obtain the telephone’s hardware address and IP address by using the ‘Options’ menu in the telephone’s GUI. The GUI can be protected by a password preventing disclosure of the addresses to an unprivileged user.
This vulnerability can be exploited in the following scenarios:
- An attacker having physical access to the mini switch in a telephone would be able to access the Voice VLAN and all ressources available to the telephone. This could be used to conduct various attacks on the telephony equipment including some denial-of-service attacks and attempts to compromise the systems.
- An attacker being able to remotely compromise a PC in a daisy-chained configuration would be able to gain partial access to the Voice VLAN and all ressources available to the telephone. This could be used to conduct various attacks on the telephony equipment including denial-of-service attacks and attempts to compromise the systems.
- Since protocols and technology that are used to get access to the telephony VLAN are standardized, attacks can be automated. Consequently, a much higher threat arises from the fact that such attacks can be built into malware that automatically performs them and that can be deployed via a worm or bot. In a daisy-chained configuration an infected computer system can become a threat to the telephony network.
Users of OmniPCX Enterprise Release 7.x are advised to configure the PC port status to:
- ‘disabled port’ if no computer system is daisy-chained to the telephone or
- to ‘filtering port’ if a computer system is daisy-chained.
More information on this issue
- Wikipedia: IEEE 802.1q
- Wikipedia: Quality of Service
- Wikipedia: OSI Model
- Wikipedia: IEEE 802.1x
- Wikipedia: AAA
- Wikipedia: Daisy Chain
- Wikipedia: Dynamic Host Configuration Protocol
- RFC2131: DHCP
- RFC3351: DHCPv6
- Wikipedia: Address Resolution Protocol
- RFC826: An Ethernet Address Resolution Protocol
- V 1.0: published 2007-06-07 10:54:27 UTC