lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <4B7092C6.4040607@arubanetworks.com>
Date: Mon, 08 Feb 2010 14:40:06 -0800
From: Robbie Gill <rgill@...banetworks.com>
To: bugtraq@...urityfocus.com
Subject: Aruba Advisory ID: AID-020810 TLS Protocol Session Renegotiation
 Security Vulnerability

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aruba Networks Security Advisory

Title: TLS Protocol Session Renegotiation Security Vulnerability

Aruba Advisory ID: AID-020810
Revision: 1.0

For Public Release on 02/08/2010

+----------------------------------------------------

SUMMARY

This advisory addresses the renegotiation related vulnerability
disclosed recently in Transport Layer Security protocol [1][2]. This
vulnerability may allow a Man-in-the-Middle (MITM) attacker to inject
arbitrary data into the beginning of the application protocol stream
protected by TLS.

The only ArubaOS component that seems affected by this issue is the
HTTPS WebUI administration interface. If a client browser (victim) is
configured to authenticate to the WebUI over HTTPS using a client
certificate, an attacker can potentially use the victim's credentials
temporarily to execute arbitrary HTTP request for each initiation of an
HTTPS session from the victim to the WebUI. This would happen without
any HTTPS/TLS warnings to the victim. This condition can essentially be
exploited by an attacker for command injection in beginning of a HTTPS
session between the victim and the ArubaOS WebUI.

ArubaOS itself does not initiate TLS renegotiation at any point and
hence is only vulnerable to scenario where a client explicitly requests
TLS renegotiation. Captive Portal users do not seem vulnerable to this
issue unless  somehow client certificates are being used to authenticate
captive portal users.

AFFECTED ArubaOS VERSIONS

   2.5.6.x, 3.3.2.x, 3.3.3.x, 3.4.0.x, 3.4.1.x, RN 3.1.x, 3.3.2.x-FIPS,
2.4.8.x-FIPS


CHECK IF YOU ARE VULNERABLE

The only ArubaOS component that seems affected by this issue is the
HTTPS WebUI administration interface. ArubaOS is vulnerable only if its
configuration permits WebUI administration interface clients to connect
using either username/password or client certificates. If only one of
the two authentication method is allowed, this issue does not seem to apply.

Check if the following line appears in your configuration:
	
	web-server mgmt-auth username/password certificate

If the exact line does not appear in the configuration, this issue does
not apply.
	

DETAILS

An industry wide vulnerability was discovered in TLS protocol's
renegotiation feature, which allows a client and server who already have
a TLS connection to negotiate new session parameters and generate new
key material.  Renegotiation is carried out in the existing TLS
connection. However there is no cryptographic binding between the
renegotiated TLS session and the original TLS session. An attacker who
has established MITM between client and server may be able to take
advantage of this and inject arbitrary data into the beginning of the
application protocol stream protected by TLS. Specifically arbitrary
HTTP requests can be injected in a HTTPS session where attacker (MITM)
blocks HTTPS session initiation between client and server, establishes
HTTPS session with the server itself, injects HTTP data and initiates
TLS renegotiation with the server. Then attacker allows the
renegotiation to occur between the client and the server. After
successful HTTPS session establishment with the server, now the client
sends its HTTP request along with its HTTP credentials (cookie) to the
server. However due to format of attacker's injected HTTP data, the
client's HTTP request is not processed, rather the attacker's HTTP
request gets executed with credentials of the client. The attacker is
not able to view the results of the injected HTTP request due to the
fact that data between the client and the server is encrypted over
HTTPS.

ArubaOS itself does not initiate TLS renegotiation at any point.

IMPACT

This vulnerability may allow a MITM attacker to inject arbitrary HTTP
request data into the beginning of a HTTPS session between client and
server (ArubaOS WebUI). The only ArubaOS component that seems affected
by this issue is the HTTPS WebUI administration interface.

Pre-requisites for this attack :
 1. The attacker must be able to establish a MITM between the client and
the server (ArubaOS WebUI).
 2. The attacker must be able to establish a successful HTTPS session
with the server (ArubaOS WebUI)
 3. ArubaOS must be configured to allow certificate based HTTPS
authentication for WebUI clients (client certs).

Captive Portal users do not seem vulnerable to this issue unless somehow
client certificates are being used to authenticate captive portal users.

CVSS v2 BASE METRIC SCORE: 6.4 (AV:N/AC:L/Au:N/C:N/I:P/A:P)


WORKAROUNDS

Aruba Networks recommends that all customers apply the appropriate
patch(es) as soon as practical. However, in the event that a patch
cannot immediately be applied, the following steps will help to mitigate
the risk:

- - - Disable certificate based HTTPS authentication (and only allow
username-password based authentication) for WebUI clients. Client's
username-password authentication POST request will prohibit attacker's
injected HTTP data from executing with client's cookie.
     CLI command: web-server mgmt-auth username/password

- - - Permit certificate based HTTPS authentication ONLY and disable
username-password based authentication to WebUI. This will prohibit
attacker from establishing a HTTPS session with ArubaOS (for MITM)
without a valid client cert.
	 CLI command: web-server mgmt-auth certificate
	
	Note: This step won't stop command injection from attackers who have
valid client certificates but their assigned management role privileges
are lower than that of the admin. This attack may allow them to run
commands at higher privilege than what is permitted in their role.

- - - Do not expose the Mobility Controller administrative interface to
untrusted networks such as the Internet.



SOLUTION

Aruba Networks recommends that all customers apply the appropriate
patch(es) as soon as practical.

The following patches have the fix (any newer patch will also have the fix):

- - - - 2.5.6.24
- - - - 3.3.2.23
- - - - 3.3.3.2
- - - - 3.4.0.7
- - - - 3.4.1.1
- - - - RN 3.1.4

Please contact Aruba support for obtaining patched FIPS releases.

Please note: We highly recommend that you upgrade your Mobility
Controller to the latest available patch on the Aruba support site
corresponding to your currently installed release.


REFERENCES

[1] http://extendedsubset.com/?p=8

[2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555




+----------------------------------------------------

OBTAINING FIXED FIRMWARE

Aruba customers can obtain the firmware on the support website:
	http://www.arubanetworks.com/support.

Aruba Support contacts are as follows:

	1-800-WiFiLAN (1-800-943-4526) (toll free from within North America)

	+1-408-754-1200 (toll call from anywhere in the world)

	e-mail: support(at)arubanetworks.com

Please, do not contact either "wsirt(at)arubanetworks.com" or
"security(at)arubanetworks.com" for software upgrades.


EXPLOITATION AND PUBLIC ANNOUNCEMENTS

This vulnerability will be announced at

Aruba W.S.I.R.T. Advisory:
http://www.arubanetworks.com/support/alerts/aid-020810.txt

SecurityFocus Bugtraq
http://www.securityfocus.com/archive/1


STATUS OF THIS NOTICE: Final

Although Aruba Networks cannot guarantee the accuracy of all statements
in this advisory, all of the facts have been checked to the best of our
ability. Aruba Networks does not anticipate issuing updated versions of
this advisory unless there is some material change in the facts. Should
there be a significant change in the facts, Aruba Networks may update
this advisory.

A stand-alone copy or paraphrase of the text of this security advisory
that omits the distribution URL in the following section is an uncontrolled
copy, and may lack important information or contain factual errors.


DISTRIBUTION OF THIS ANNOUNCEMENT

This advisory will be posted on Aruba's website at:
http://www.arubanetworks.com/support/alerts/aid-020810.txt


Future updates of this advisory, if any, will be placed on Aruba's worldwide
website, but may or may not be actively announced on mailing lists or
newsgroups. Users concerned about this problem are encouraged to check the
above URL for any updates.


REVISION HISTORY

      Revision 1.0 / 02-08-2010 / Initial release


ARUBA WSIRT SECURITY PROCEDURES

Complete information on reporting security vulnerabilities in Aruba Networks
products, obtaining assistance with security incidents is available at
      http://www.arubanetworks.com/support/wsirt.php


For reporting *NEW* Aruba Networks security issues, email can be sent to
wsirt(at)arubanetworks.com or security(at)arubanetworks.com. For sensitive
information we encourage the use of PGP encryption. Our public keys can be
found at
	http://www.arubanetworks.com/support/wsirt.php


      (c) Copyright 2010 by Aruba Networks, Inc.
This advisory may be redistributed freely after the release date given at
the top of the text, provided that redistributed copies are complete and
unmodified, including all date and version information.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktwksYACgkQp6KijA4qefXErQCeKJW3YU3Nl7JY4+2Hp2zqM3bN
bWAAoJWQT+yeWX2q+02hNEwHWQtGf1YP
=CrHf
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ