Message-ID: <20070607105426.GC9425@cert.uni-stuttgart.de>
Date: Thu, 7 Jun 2007 12:54:27 +0200
From: Oliver Goebel <goebel@...t.uni-stuttgart.de>
To: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
Subject: RUS-CERT 2007-06:01 (1380): Insecure Defaults in
	A-L OmniPCX 7.0

Dear all,

for your information.

------------------------------------------------------------------------

RUS-CERT Security Announcement 2007-06:01 (1380)
================================================

  The built-in Mini Switch in Alcatel-Lucent's IP-Touch Telephones under
  OmniPCX Enterprise 7.0 and later Allows Un-Authenticated Access to the
  Voice VLAN in IEEE 802.1x-Authenticated Environments


URL
===
This announcement is available at:
http://cert.uni-stuttgart.de/advisories/al-ip-touch-vlan-filtering.php


Synopsis
========
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.


Extract
=======
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
Technical Risk: high
Threat:  	medium
CVSS:		6.2
CVE-Name:       CVE-2007-2512


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 IEEE 802.1x[4]
  authentication for IP Touch telephones.


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


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.


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 Type
==================
* insecure defaults


Technical Risk
==============
* high


Threat
======
* medium

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 http://cert.uni-stuttgart.de/advisories/rating.php for RUS-CERT's
risk and threat rating.


CVSS Rating
===========
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 scenario with a compromised computer system that is
daisy-chained to a telephone this vulnerability can be expoited
remotely.


Technical Context
=================
See
http://cert.uni-stuttgart.de/advisories/al-ip-touch-vlan-filtering.php#context
for details.

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

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.


Vulnerability ID
================
CVE-2007-2512[10]


More Information on This Issue
==============================

* See Alcatel-Lucent PSIRT's Security Statements Page[11] for
  Alcatel-Lucent's Announcement on this issue.


References
==========
[1] http://en.wikipedia.org/wiki/IEEE_802.1Q
[2] http://en.wikipedia.org/wiki/Quality_of_Service
[3] http://en.wikipedia.org/wiki/OSI_model
[4] http://en.wikipedia.org/wiki/802.1x
[5] http://en.wikipedia.org/wiki/AAA_protocol
[6] http://en.wikipedia.org/wiki/Daisy-chain
[7] http://www1.alcatel-lucent.com/psirt
[8] http://en.wikipedia.org/wiki/DHCP,
    http://archive.cert.uni-stuttgart.de/rfc/rfc2131.txt and
    http://archive.cert.uni-stuttgart.de/rfc/rfc3315.txt
[9] http://en.wikipedia.org/wiki/Address_Resolution_Protocol, 
    http://archive.cert.uni-stuttgart.de/rfc/rfc826.txt
[10] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2512
[11] http://www1.alcatel-lucent.com/psirt/statements.htm


------------------------------------------------------------------------

-- 
Oliver Goebel                        mailto:Goebel@...T.Uni-Stuttgart.DE
Stabsstelle DV-Sicherheit (RUS-CERT) Tel:+49 711 685 1 CERT
Universitaet Stuttgart               Tel:+49 711 685 8-3678 / Fax:-3688
Breitscheidstr. 2, 70174 Stuttgart   http://CERT.Uni-Stuttgart.DE/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists