CVE Vulnerabilities


Use of a Broken or Risky Cryptographic Algorithm

Published: Mar 23, 2018 | Modified: Apr 19, 2018
CVSS 3.x
CVSS 2.x

DBS3900 TDD LTE V100R003C00, V100R004C10 have a weak encryption algorithm security vulnerability. DBS3900 TDD LTE supports SSL/TLS protocol negotiation using insecure encryption algorithms. If an insecure encryption algorithm is negotiated in the communication, an unauthenticated remote attacker can exploit this vulnerability to crack the encrypted data and cause information leakage.


The use of a broken or risky cryptographic algorithm is an unnecessary risk that may result in the exposure of sensitive information.

Potential Mitigations

  • When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis.
  • For example, US government systems require FIPS 140-2 certification.
  • Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak.
  • Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267]
  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • Industry-standard implementations will save development time and may be more likely to avoid errors that can occur during implementation of cryptographic algorithms. Consider the ESAPI Encryption feature.