CVE-2025-30095 in VyOS
Summary
by MITRE • 03/31/2025
VyOS 1.3 through 1.5 or any Debian-based system using dropbear in combination with live-build has the same Dropbear private host keys across different installations. Thus, an attacker can conduct active man-in-the-middle attacks against SSH connections if Dropbear is enabled as the SSH daemon. I n VyOS, this is not the default configuration for the system SSH daemon, but is for the console service. To mitigate this, one can run "rm -f /etc/dropbear/*key*" and/or "rm -f /etc/dropbear-initramfs/*key*" and then dropbearkey -t rsa -s 4096 -f /etc/dropbear_rsa_host_key and reload the service or reboot the system before using Dropbear as the SSH daemon (this clears out all keys mistakenly built into the release image) or update to the latest version of VyOS 1.4 or 1.5. Note that this vulnerability is not unique to VyOS and may appear in any Debian-based Linux distribution that uses Dropbear in combination with live-build, which has a safeguard against this behavior in OpenSSH but no equivalent one for Dropbear.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/31/2025
The vulnerability described in CVE-2025-30095 represents a critical security flaw affecting VyOS versions 1.3 through 1.5 and any Debian-based systems utilizing dropbear with live-build configurations. This issue stems from the improper generation of cryptographic host keys during the system image creation process, where identical private host keys are embedded across all installations. The vulnerability specifically impacts the console service which defaults to using dropbear as the SSH daemon, creating a persistent security risk that allows attackers to execute active man-in-the-middle attacks against SSH connections. This flaw directly violates security principles established in the National Institute of Standards and Technology cybersecurity framework, particularly concerning the protection of cryptographic keys and secure communication channels.
The technical implementation of this vulnerability occurs through the live-build process which pre-generates dropbear host keys during image creation, resulting in identical private keys being distributed across all affected systems. This represents a CWE-310 weakness related to cryptographic issues, specifically involving the use of predictable or reused cryptographic keys. The flaw exists because dropbear's key generation process within the live-build environment does not properly randomize or regenerate host keys for each individual installation, unlike the more secure OpenSSH implementation which includes safeguards against this behavior. When an attacker intercepts SSH traffic, they can leverage these identical keys to impersonate the target system and decrypt communications, effectively bypassing the fundamental security assurances provided by SSH protocol encryption.
The operational impact of this vulnerability extends beyond simple credential theft to encompass complete system compromise through active attack vectors. Attackers can exploit this weakness to establish persistent backdoors, perform session hijacking, and execute arbitrary commands on affected systems without detection. This vulnerability particularly affects network infrastructure devices running VyOS where console access is critical for system administration. The attack surface is broadened because the console service typically requires elevated privileges and provides direct access to system configuration and management interfaces. Organizations using affected versions may experience unauthorized access to sensitive network infrastructure, potentially leading to complete network compromise and data exfiltration as outlined in the MITRE ATT&CK framework under the T1021.004 technique for remote services and T1566 for credential harvesting.
Mitigation strategies for this vulnerability require immediate system intervention including the removal of pre-generated keys followed by proper key regeneration using the dropbearkey utility. The recommended approach involves executing rm -f /etc/dropbear/key and rm -f /etc/dropbear-initramfs/key commands to eliminate the vulnerable keys, followed by regeneration using dropbearkey -t rsa -s 4096 -f /etc/dropbear_rsa_host_key. System administrators must then reload the dropbear service or reboot the affected systems to ensure the new keys are properly loaded. The most effective long-term solution involves upgrading to VyOS 1.4 or 1.5 versions which address this specific vulnerability through proper key generation during the system installation process. Additionally, organizations should implement monitoring for unusual SSH connection patterns and consider disabling dropbear console access if not required, following the principle of least privilege as recommended in the NIST cybersecurity framework. This vulnerability serves as a reminder of the critical importance of proper cryptographic key management in embedded systems and the necessity of validating security configurations during the software development lifecycle.