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
- - - - - - - - -
A-L OmniPCX 7.0 Insecure Defaults
------------------------------------------------------------------------
SUMMARY
The built-in Mini Switch in Alcatel-Lucent's IP-Touch Telephones under
OmniPCX Enterprise 7.0 and later allows unauthenticated access to the
Voice VLAN in IEEE 802.1x authenticated environments.
DETAILS
Vulnerable Systems:
* 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
Immune 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.
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.
Vendor Status:
Alcatel-Lucent was contacted in 02-2007 and the publication of this
announcement was co-ordinated with A-L's PSIRT[7] 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)[1] technology to separate voice and data
traffic (VLAN segmentation) and .
Attack Vector:
* Mini switch in Alcatel-Lucent IP Touch telephone when daisy-chaining a
IEEE 802.1q capable computer system
Attack Requirements:
* 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.
Impact:
* Un-authenticated access to the VLAN defined to separate voice traffic
from data traffic
Vulnerability Description:
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[4] 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[8], ARP[9]). 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.
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:
1. An attacker having physical access to the mini switch in a telephone
would be able to access the Voice VLAN and all resources 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.
2. 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.
3. 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.
Countermeasures:
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
* See Alcatel-Lucent PSIRT's Security Statements Page[11] for
Alcatel-Lucent's Announcement on this issue.
CVE Information:
<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2512>
CVE-2007-2512
References
[1] <http://en.wikipedia.org/wiki/IEEE_802.1Q>
http://en.wikipedia.org/wiki/IEEE_802.1Q
[2] <http://en.wikipedia.org/wiki/Quality_of_Service>
http://en.wikipedia.org/wiki/Quality_of_Service
[3] <http://en.wikipedia.org/wiki/OSI_model>
http://en.wikipedia.org/wiki/OSI_model
[4] <http://en.wikipedia.org/wiki/802.1x>
http://en.wikipedia.org/wiki/802.1x
[5] <http://en.wikipedia.org/wiki/AAA_protocol>
http://en.wikipedia.org/wiki/AAA_protocol
[6] <http://en.wikipedia.org/wiki/Daisy-chain>
http://en.wikipedia.org/wiki/Daisy-chain
[7] <http://www1.alcatel-lucent.com/psirt>
http://www1.alcatel-lucent.com/psirt
[8] <http://en.wikipedia.org/wiki/DHCP>
http://en.wikipedia.org/wiki/DHCP,
<http://archive.cert.uni-stuttgart.de/rfc/rfc2131.txt>
http://archive.cert.uni-stuttgart.de/rfc/rfc2131.txt and
<http://archive.cert.uni-stuttgart.de/rfc/rfc3315.txt>
http://archive.cert.uni-stuttgart.de/rfc/rfc3315.txt
[9] <http://en.wikipedia.org/wiki/Address_Resolution_Protocol>
http://en.wikipedia.org/wiki/Address_Resolution_Protocol,
<http://archive.cert.uni-stuttgart.de/rfc/rfc826.txt>
http://archive.cert.uni-stuttgart.de/rfc/rfc826.txt
[10] <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2512>
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2512
[11] <http://www1.alcatel-lucent.com/psirt/statements.htm>
http://www1.alcatel-lucent.com/psirt/statements.htm
ADDITIONAL INFORMATION
The information has been provided by
<mailto:goebel@cert.uni-stuttgart.de> Oliver Goebel.
The original article can be found at:
<http://cert.uni-stuttgart.de/advisories/al-ip-touch-vlan-filtering.php>
http://cert.uni-stuttgart.de/advisories/al-ip-touch-vlan-filtering.php
========================================
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
====================
====================
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.
