Brocade SANnav OVA before v2.3.1 and v2.3.0a contain hard-coded credentials in the documentation that appear as the appliance's root password. The vulnerability could allow an unauthenticated attacker full access to the Brocade SANnav appliance.
A vulnerability in Brocade SANnav exposes Kafka in the wan interface.
The vulnerability could allow an unauthenticated attacker to perform various attacks, including DOS against the Brocade SANnav.
Brocade SANnav OVA before SANnav 2.3.1b enables SHA1 deprecated setting for SSH for port 22.
A flaw was found in the Java logging library Apache Log4j in version 1.x. JDBCAppender in Log4j 1.x is vulnerable to SQL injection in untrusted data. This allows a remote attacker to run SQL statements in the database if the deployed application is configured to use JDBCAppender with certain interpolation tokens.
Webtools in Brocade SANnav before version 2.1.1 allows unauthenticated users to make requests to arbitrary hosts due to a misconfiguration; this is commonly referred to as Server-Side Request Forgery (SSRF).
In Brocade SANnav before Brocade SANnav 2.2.0, multiple endpoints associated with Zone management are susceptible to SQL injection, allowing an attacker to run arbitrary SQL commands.
A flaw was found in the Java logging library Apache Log4j in version 1.x. JMSSink in Log4j 1.x is vulnerable to deserialization of untrusted data. This allows a remote attacker to execute code on the server if JMSSink is deployed and has been configured to perform JNDI requests.
A vulnerability in the role-based access control (RBAC) functionality of the Brocade SANNav before 2.2.0 could allow an authenticated, remote attacker to access resources that they should not be able to access and perform actions that they should not be able to perform. The vulnerability exists because restrictions are not performed on Server side to ensure the user has required permission before processing requests.
A vulnerability in Brocade SANnav before v2.3.1 and v2.3.0a prints Brocade Fabric OS switch encrypted passwords in the Brocade SANnav Standby node's support save.
In Brocade SANnav, before Brocade SANnav v2.3.0, syslog traffic received clear text. This could allow an unauthenticated, remote attacker to capture sensitive information.
A vulnerability affects Brocade SANnav before v2.3.1 and v2.3.0a. It allows a Brocade SANnav service to send ping commands in the background at regular intervals to gridgain.com to check if updates are available for the Component. This could make an unauthenticated, remote attacker aware of the behavior and launch a supply-chain attack against a Brocade SANnav appliance.
A vulnerability in Brocade SANnav before 2.4.0b and 3.0.0 prints encoded passwords and authentication tokens in log files. The vulnerability could allow an authenticated attacker with access to the log file including the SANnav supportsave to access the passwords.
The PostgreSQL implementation in Brocade SANnav versions before 2.3.0a is vulnerable to an incorrect local authentication flaw. An attacker accessing the VM where the Brocade SANnav is installed can gain access to sensitive data inside the PostgreSQL database.
An information disclosure vulnerability exists in Brocade SANnav before v2.3.1 and v2.3.0a when Brocade SANnav instances are configured in disaster recovery mode. SQL Table names, column names, and SQL queries are collected in DR standby Supportsave. This could allow authenticated users to access the database structure and its contents.
The class FileTransfer implemented in Brocade SANnav before v2.3.1, v2.3.0a, uses the ssh-rsa signature scheme, which has a SHA-1 hash. The vulnerability could allow a remote, unauthenticated attacker to perform a man-in-the-middle attack.
A vulnerability in Brocade SANnav before v2.3.1 and v2.3.0a prints the encryption key in the console when a privileged user executes the script to replace the Brocade SANnav Management Portal standby node. This could provide attackers an additional, less protected path to acquiring the encryption key.
When Brocade SANnav before v2.3.1 and v2.3.0a servers are configured in Disaster Recovery mode, the encryption key is stored in the DR log files. This could provide attackers with an additional, less-protected path to acquiring the encryption key.
In Brocade SANnav server before v2.3.1 and v2.3.0a, the SSH keys inside the OVA image are identical in the VM every time SANnav is installed. Any Brocade SAnnav VM based on the official OVA images is vulnerable to MITM over SSH. An attacker can decrypt and compromise the SSH traffic to the SANnav.
When a Brocade SANnav installation is upgraded from Brocade SANnav v2.2.2 to Brocade SANnav 2.3.0, TLS/SSL weak message authentication code ciphers are added by default for port 18082.
Brocade SANnav before version 2.1.1 logs account credentials at the ‘trace’ logging level.
Brocade SANnav before version 2.1.1 contains an Improper Authentication vulnerability that allows cleartext transmission of authentication credentials of the jmx server.
In Brocade SANnav before Brocade SANnav v2.2.0.2 and Brocade SANnav2.1.1.8, encoded scp-server passwords are stored using Base64 encoding, which could allow an attacker able to access log files to easily decode the passwords.
In Brocade SANnav version before SANN2.2.0.2 and Brocade SANNav before 2.1.1.8, the implementation of TLS/SSL Server Supports the Use of Static Key Ciphers (ssl-static-key-ciphers) on ports 443 & 18082.
By default, SANnav OVA is shipped with root user login enabled. While protected by a password, access to root could expose SANnav to a remote attacker should they gain access to the root account.
A path traversal vulnerability affects the The Zone Alias Import flow feature in Brocade SANnav before 3.0.0a. A local authenticated attacker can write an uploaded content outside the intended directory.
In Brocade SANnav before v2.3.1, and v2.3.0a, it is possible to back up the appliance from the web interface or the command line interface ("SSH"). The resulting backups are world-readable. A local attacker can recover backup files, restore them to a new malicious appliance, and retrieve the passwords of all the switches.
Brocade SANnav before Brocade SANnav 2.4.0a could log database passwords in clear text in audit logs when the daily data dump collector invokes docker exec commands. These audit logs are the local server VM’s audit logs and are not controlled by SANnav. These logs are only visible to the server admin of the host server and are not visible to the SANnav admin or any SANnav user.
A vulnerability in Brocade SANnav before v2.3.1 and v2.3.0a prints the Brocade SANnav password in clear text in supportsave logs when a user schedules a switch Supportsave from Brocade SANnav.
Brocade SANnav versions before v2.3.0a do not correctly set permissions on files, including docker files. An unprivileged attacker who gains access to the server can read sensitive information from these files.
Brocade SANnav before SANnav 2.2.0 application uses the Blowfish symmetric encryption algorithm for the storage of passwords. This could allow an authenticated attacker to decrypt stored account passwords.