Brocade SANnav OVA appliance image, before v2.3.1 and v2.3.0a: Three defects that together mean every SANnav OVA

Impact

Three defects that together mean every SANnav OVA deployment shares the same secrets. The documentation ships what is effectively the appliance's root password; every VM built from the official OVA carries identical SSH host keys, so SSH to SANnav is trivially machine-in-the-middle-able; and appliance backups are created world-readable, so a local user can copy a backup, restore it onto their own appliance and recover the passwords of every switch in the fabric. For an operator this is the cheapest possible path from 'someone got a shell somewhere near the management network' to 'attacker holds admin on every FC switch', and therefore to zoning changes that expose one tenant's LUNs to another.

Who can reach it

The root password and SSH keys are usable by anyone with network access to the appliance; the world-readable backup requires only an unprivileged local account on the SANnav host.

What to do

Upgrade to SANnav 2.3.1 / 2.3.0a, then do the cleanup the upgrade does not do for you: change the appliance root password, regenerate the SSH host keys so your instance is no longer keyed identically to every other deployment, fix permissions on existing backup files and move them off the appliance, and rotate every switch credential that a stolen backup would have exposed. Management-plane work only - no switch firmware flash, no fabric outage.

References