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.
A vulnerability in Brocade SANnav before v2.3.1 and v2.3.0a could allow an authenticated user to print the Auth, Priv, and SSL key store passwords in unencrypted logs by manipulating command variables.
A vulnerability in Brocade SANnav before v2.3.1 and v2.3.0a could allow a privileged user to print the SANnav encrypted key in PostgreSQL startup logs.
This could provide attackers with an additional, less-protected path to acquiring the encryption key.
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.
Brocade SANnav Web interface before Brocade SANnav v2.3.0 and v2.2.2a
allows remote unauthenticated users to bypass web authentication and
authorization.
Brocade
SANnav before v2.3.0 and v2.2.2a stores SNMPv3 Authentication passwords
in plaintext. A privileged user could retrieve these credentials with
knowledge and access to these log files. SNMP
credentials could be seen in SANnav SupportSave if the capture is
performed after an SNMP configuration failure causes an SNMP
communication log dump.
Possible
information exposure through log file vulnerability where sensitive
fields are recorded in the configuration log without masking on Brocade
SANnav before v2.3.0 and 2.2.2a. Notes:
To access the logs, the local attacker must have access to an already collected Brocade SANnav "supportsave"
outputs.
Brocade SANnav before v2.2.1 logs usernames and encoded passwords in
debug-enabled logs. The vulnerability could allow an attacker with admin
privilege to read sensitive information.