Brocade SANnav OVA before v2.3.1, and v2.3.0a, contain hardcoded TLS keys used by Docker. Note: Brocade SANnav doesn't have access to remote Docker registries.
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.
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.
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.