Use of Obsolete and Cryptographically Broken SSH Protocols and Algorithms Leading to Credential Disclosure and Session Compromise
Product: Beetel 777VR1 Broadband Router
Firmware Versions: V01.00.09 / V01.00.09_55
- CWE-327 – Use of a Broken or Risky Cryptographic Algorithm (Primary)
- CWE-326 – Inadequate Encryption Strength
- CWE-310 – Cryptographic Issues
- CWE-522 – Insufficiently Protected Credentials
- CWE-295 – Improper Certificate Validation
A critical cryptographic vulnerability exists in the SSH service implemented in the Beetel 777VR1 Broadband Router firmware versions V01.00.09 and V01.00.09_55 due to the use of obsolete SSH protocol versions and cryptographically broken algorithms.
The router’s SSH daemon identifies itself as SSH_0.48, an extremely outdated implementation dating back to approximately 2006, despite the firmware having a very recent date and year of build (Nov 7, 2019). This version predates modern SSH security hardening and supports only deprecated key exchange mechanisms, host key algorithms, and ciphers that are no longer considered secure.
Specifically, the SSH service enforces the use of weak cryptographic primitives such as diffie-hellman-group1-sha1, ssh-rsa with SHA-1, and 3des-cbc. These algorithms have been formally deprecated due to known cryptographic weaknesses and are disabled by default in modern SSH clients.
As a result, SSH sessions established with the router lack confidentiality, integrity, and resistance to active or passive attacks. Network attackers can exploit these weaknesses to intercept credentials, perform man-in-the-middle attacks, or decrypt SSH traffic.
The SSH service exhibits the following critical weaknesses:
-
Obsolete SSH protocol implementation
- Server version:
SSH_0.48
- Server version:
-
Broken key exchange
diffie-hellman-group1-sha1(768-bit MODP group)
-
Weak host key algorithms
ssh-rsausing SHA-1
-
Insecure symmetric cipher
3des-cbc(64-bit block size, vulnerable to Sweet32)
These cryptographic mechanisms are mathematically broken or deprecated and violate modern security standards including NIST, CIS Benchmarks, and RFC recommendations.
Because of these cryptographic weaknesses:
- SSH authentication credentials can be intercepted
- SSH sessions can be decrypted offline
- Man-in-the-middle attacks can be performed without detection
- Session integrity cannot be guaranteed
- Attackers can downgrade or manipulate cryptographic negotiation
When combined with weak or reused credentials, these issues significantly amplify the risk of full device compromise.
- Disclosure of SSH authentication credentials
- Man-in-the-middle attacks against management sessions
- Decryption of SSH traffic
- Loss of confidentiality and integrity
- Increased likelihood of full administrative compromise
- Network-based attacker
- LAN or WAN (as SSH is exposed)
- Passive or active interception
Critical
Observation : We note that the cryptographic algorithm offered by the router for authentication is diffie-hellman-group1-sha1 and the router ssh version is SSH_0.48.
This is a serious vulnerability. diffie-hellman-group1-sha1 is a critical vulnerability because it relies on a 768-bit key size that is computationally too small to withstand modern brute-force attacks. Since this encryption standard was mathematically broken in 2010, attackers can now decrypt your SSH sessions to steal credentials and read your data as if the connection were plain text.
The router ssh version SSH_0.48 also happens to be ancient (circa ~2006). SSH_0.48 is a critical vulnerability because it relies on broken cryptography, such as Diffie-Hellman Group 1 and 3DES, which allows attackers to decrypt traffic and steal credentials. Due to missing nearly two decades of security patches, it exposes the system to specific known exploits including user enumeration, Denial of Service (DoS), and Man-in-the-Middle (MITM) attacks. Most critically, unpatched flaws in this version create a high risk of memory corruption and format string vulnerabilities, potentially allowing attackers to execute arbitrary code (RCE) and take full control of the device. Bots on the web specifically scan for these vulnerabilities and version numbers to find targets to exploit.
ssh command parameters explanation:
-
-o KexAlgorithms=+diffie-hellman-group1-sha1: Re-enables the specific key exchange the router is demanding. -
-o HostKeyAlgorithms=+ssh-rsa: Old routers usually sign their identity with ssh-rsa (SHA-1), which is also disabled on modern clients.
The second cryptographic exchange algorithm is 3des-cbc. 3des-cbc is a critical vulnerability because it relies on a small 64-bit block size, making it directly susceptible to "Sweet32" collision attacks. This design flaw allows attackers to recover sensitive plaintext, such as session cookies or authentication credentials, by capturing a relatively small amount of traffic from long-lived connections. Additionally, it offers only 112 bits of effective security, which is insufficient against modern cryptanalysis, leading to its official deprecation by NIST and removal from modern security standards due to the high risk of data compromise.
-
Remove obsolete SSH implementations entirely
-
Upgrade to a modern, maintained SSH server, as and when the cryptographic algorithm is no longer secure.
-
Disable all deprecated algorithms, including:
diffie-hellman-group1-sha1ssh-rsa(SHA-1)3des-cbc
-
Enforce modern cryptographic standards:
- Strong key exchange (e.g., ECDH / Curve25519)
- Strong ciphers (AES-GCM / ChaCha20-Poly1305)
- Modern host keys (ED25519 / RSA-SHA2)
-
Enforce secure credential policies and key-based authentication
This vulnerability is distinct from the SSH service exposure / activation vulnerability reported separately for the same device.
This issue specifically concerns the use of obsolete and cryptographically broken SSH protocols and algorithms (SSH_0.48, diffie-hellman-group1-sha1, ssh-rsa with SHA-1, 3des-cbc) after the SSH service is reachable, regardless of how that reachability occurs.
The cryptographic weakness exists independently of the service exposure mechanism and would remain exploitable even if SSH were intentionally enabled by an administrator or exposed through misconfiguration. Conversely, the SSH service exposure vulnerability focuses on improper access control and unauthorized activation, not cryptographic design.
These issues represent separate root causes and should be tracked as distinct vulnerabilities.
RAGHAV AGRAWAL