Under certain error conditions at time of SANnav installation or upgrade, the encryption key can be written into and obtained from a Brocade SANnav supportsave. An attacker with privileged access to the Brocade SANnav database could use the encryption key to obtain passwords used by Brocade SANnav.
CalInvocationHandler in Brocade
SANnav before 2.3.1b logs sensitive information in clear text. The
vulnerability could allow an authenticated, local attacker to view
Brocade Fabric OS switch sensitive information in clear text. An
attacker with administrative privileges could retrieve sensitive
information including passwords; SNMP responses that contain AuthSecret
and PrivSecret after collecting a “supportsave” or getting access to an
already collected “supportsave”. NOTE: this issue exists because of an incomplete fix for CVE-2024-29952
Possible information exposure through log file vulnerability where sensitive fields are recorded in the debug-enabled logs when debugging is turned on in Brocade SANnav before 2.3.0 and 2.2.2a
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.
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.
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.
Brocade SANnav before v2.3.0a lacks protection mechanisms on port 2377/TCP and 7946/TCP, which could allow an unauthenticated attacker to sniff the SANnav Docker information.
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.
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.
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.