Keypoints
- Multiple defaults and hardcoded credentials (root, sannav, SSH keys, Docker keys) permit local or network login to the SANnav appliance.
- Management traffic uses HTTP fallback and syslog is sent in clear-text, enabling network credential interception and MITM of switch management connections.
- Kafka, Docker cluster ports (2377/7946) and Kafka APIs (18081/18082/19094) are exposed on WAN with no authentication, allowing remote write/injection and DoS by disk-filling payloads.
- Postgres inside Docker runs with trust/no-auth on localhost and hardcoded user dcmadmin, letting attackers dump and modify the dcmdb database (switch configs, credentials, SNMP secrets).
- Docker containers have insecure bind mounts (RW) and some expose /var/run/docker.sock, enabling container-to-host escalation and arbitrary host control by replacing binaries or mounts.
- Backups are world-readable and contain credentials/configs; attackers with local access can restore to a malicious appliance to extract switch passwords offline.
- Vendor issued CVEs and advisories; recommended remediation is upgrading to SANnav 2.3.1 and applying provided security bulletins.
MITRE Techniques
- [T1078.001] Default Accounts – Appliance ships with documented/undocumented accounts and known passwords enabling direct login (‘Using this password, it is possible to get a root access to the appliance’).
- [T1040] Network Sniffing – Clear-text HTTP/syslog traffic allows interception of switch credentials and management data (‘syslog traffic sent in clear-text’ / ‘connects to remote switches using a clear-text network protocol (HTTP)’)
- [T1552] Unsecured Credentials – Hardcoded SSH keys and Docker keys in images expose private keys and TLS material for MITM and unauthorized access (‘SSH keys inside the OVA image are hardcoded’ / ‘/etc/docker/key.json’).
- [T1190] Exploit Public-Facing Application – Exposed, unauthenticated Kafka/Schema Registry HTTP APIs permit remote schema creation and message injection (‘Kafka is reachable from the WAN interface’ / ‘There is no authentication implemented in the Kafka APIs’).
- [T1005] Data from Local System – Postgres trust configuration and accessible backups allow full database dumps and extraction of switch configs, SNMP communities, and stored credentials (‘pg_hba.conf … host all all 127.0.0.1/32 trust’ / ‘pg_dump -d dcmdb …’).
- [T1610] Escape to Host (Container Escape / Privilege Escalation) – Docker containers have RW bind mounts and access to /var/run/docker.sock allowing containerized processes to modify host files or launch privileged containers (‘Mounts … RW”: true’ / ‘bind … “/var/run/docker.sock” … “RW”: true’).
Indicators of Compromise
- [CVE IDs] Reported advisories – CVE-2024-4161, CVE-2024-29967, CVE-2024-29960, and several others (see vendor bulletins) and other CVEs referenced in the report.
- [IP Addresses] SANnav appliance and switches – 10.13.3.7 (appliance), 10.13.3.8 (switch), and remote endpoints like 151.101.2.132 (ignite.apache.org) / 104.20.72.180 (www.gridgain.com).
- [Open Ports / Services] Exposed services – 18081/tcp, 18082/tcp, 19094/tcp (Kafka/APIs), 2377/tcp and 7946/tcp (Docker/Swarm), 22/tcp (SSH), 80/443 (HTTP/HTTPS).
- [Files / Paths] Sensitive files & keys – /etc/docker/key.json (hardcoded Docker key), /etc/ssh/ssh_host_* (hardcoded SSH keys), /sannav-portal-v211/…/backuprestore/dcm-ondemand-backup-*.tar.gz (world-readable backups), and /etc/kafka/secrets/keystore_creds.
- [Usernames & Passwords] Accounts and credentials – root and sannav accounts with documented password ‘SANnav!@#’, Postgres user ‘dcmadmin’ with no password, and Kafka password ‘passw0rd’ found in config files.
- [URLs / Sources] Reference and disclosure links – https://pierrekim.github.io/blog/2024-04-24-brocade-sannav-18-vulnerabilities.html#insecure-sannav-access (primary report), Broadcom PSIRT advisories (vendor CVE pages).
SANnav technical summary (procedural focus):
The SANnav appliance (≤ v2.3.0) exposed a combination of insecure defaults and misconfigurations that let an attacker move from network to host to SAN switch compromise. Network-facing services (Kafka schema-registry/APIs on 18081/18082/19094, Docker swarm ports 2377/7946) were reachable from the WAN and lacked authentication, while management traffic (HTTP fallback to clear-text and syslog) leaked credentials on the wire. An attacker can sniff HTTP/syslog to recover base64-encoded credentials, SSH into switches, and inject malicious Kafka messages or fill disk storage to cause DoS.
At the host/container layer, Postgres ran inside a Docker container configured with trust for localhost and a hardcoded dcmadmin user, allowing SSH tunneling + psql to dump and edit the dcmdb database (containing encrypted/base64 credentials, SNMP communities, switch WWNs and configs). Multiple containers had RW bind mounts into host paths (JRE, bin, backuprestore) and some had /var/run/docker.sock exposed; this enables an attacker who gains container access to overwrite host binaries, restore backups, or launch privileged containers to obtain full root on the appliance. World-readable backup tarballs and permissive file/directory permissions further permit local credential extraction and offline analysis.
Mitigation steps executed in vendor patches included removing hardcoded keys, enforcing SSH and SSHD restrictions, securing Docker mounts and socket access, enabling authentication and encryption for Kafka and management channels, and correcting Postgres authentication; the report recommends upgrading to SANnav 2.3.1 and applying the related Broadcom security bulletins immediately to close these vectors and rotate all affected credentials and certs.