CWE-1240 Base Brouillon

Use of a Cryptographic Primitive with a Risky Implementation

This weakness occurs when a product uses a custom, unverified, or non-compliant implementation of a cryptographic algorithm instead of a trusted, standard solution.

Définition

What is CWE-1240?

This weakness occurs when a product uses a custom, unverified, or non-compliant implementation of a cryptographic algorithm instead of a trusted, standard solution.
Cryptographic systems rely on proven building blocks like encryption, hashing, and digital signatures. These primitives are mathematically designed to withstand a specific number of attack attempts. When developers implement their own versions or use deprecated algorithms, they often introduce subtle flaws that cryptographers already understand, making the entire system vulnerable to data exposure or tampering. Using risky implementations is especially dangerous in hardware, where fixes often require physical recalls. Cryptographic standards are continuously reviewed and updated as computing power grows and new attack methods emerge. Relying on non-standard or weakened primitives, even for a single component, can compromise the security of the entire application over its lifespan.
Impact réel

Real-world CVEs caused by CWE-1240

  • CVE-2020-4778

    software uses MD5, which is less safe than the default SHA-256 used by related products

  • CVE-2005-2946

    Default configuration of product uses MD5 instead of stronger algorithms that are available, simplifying forgery of certificates.

  • CVE-2019-3907

    identity card uses MD5 hash of a salt and password

  • CVE-2021-34687

    personal key is transmitted over the network using a substitution cipher

  • CVE-2020-14254

    product does not disable TLS-RSA cipher suites, allowing decryption of traffic if TLS 2.0 and secure ciphers are not enabled.

  • CVE-2019-1543

    SSL/TLS library generates 16-byte nonces but reduces them to 12 byte nonces for the ChaCha20-Poly1305 cipher, converting them in a way that violates the cipher's requirements for unique nonces.

  • CVE-2017-9267

    LDAP interface allows use of weak ciphers

  • CVE-2017-7971

    SCADA product allows "use of outdated cipher suites"

Comment les attaquants l'exploitent

Parcours de l'attaquant étape par étape

  1. 1

    Identifier un chemin de code qui traite des entrées non fiables sans validation.

  2. 2

    Élaborer une charge utile qui exploite le comportement non sécurisé — injection, traversal, débordement ou abus de logique.

  3. 3

    Délivrer la charge utile via une requête normale et observer la réaction de l'application.

  4. 4

    Itérer jusqu'à ce que la réponse divulgue des données, exécute le code de l'attaquant ou élève les privilèges.

Exemple de code vulnérable

Vulnerable Other

Re-using random values may compromise security.

Vulnérable Other 
Suppose an Encryption algorithm needs a random value for a key. Instead of using a DRNG (Deterministic Random Number Generator), the designer uses a linear-feedback shift register (LFSR) to generate the value.
Exemple de code sécurisé

Secure Other

While an LFSR may provide pseudo-random number generation service, the entropy (measure of randomness) of the resulting output may be less than that of an accepted DRNG (like that used in dev/urandom). Thus, using an LFSR weakens the strength of the cryptographic system, because it may be possible for an attacker to guess the LFSR output and subsequently the encryption key.

Sécurisé Other 
If a cryptographic algorithm expects a random number as its input, provide one. Do not provide a pseudo-random value.
What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Liste de contrôle de prévention

How to prevent CWE-1240

  • Requirements Require compliance with the strongest-available recommendations from trusted parties, and require that compliance must be kept up-to-date, since recommendations evolve over time. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-267].
  • Architecture and Design Ensure that the architecture/design uses the strongest-available primitives and algorithms from trusted parties. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-267].
  • Architecture and Design Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. As with all cryptographic mechanisms, the source code should be available for analysis. If the algorithm may be compromised when attackers find out how it works, then it is especially weak.
  • Architecture and Design Try not to use cryptographic algorithms in novel ways or with new modes of operation even when you "know" it is secure. For example, using SHA-2 chaining to create a 1-time pad for encryption might sound like a good idea, but one should not do this.
  • Architecture and Design Ensure that the design can replace one cryptographic primitive or algorithm with another in the next generation ("cryptographic agility"). Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. This is especially important for hardware, which can be more difficult to upgrade quickly than software; design the hardware at a replaceable block level.
  • Architecture and Design Do not use outdated or non-compliant cryptography algorithms. 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].
  • Architecture and Design / Implementation Do not use a linear-feedback shift register (LFSR) or other legacy methods as a substitute for an accepted and standard Random Number Generator.
  • Architecture and Design / Implementation Do not use a checksum as a substitute for a cryptographically generated hash.
Signaux de détection

How to detect CWE-1240

Architecture or Design Review High

Review requirements, documentation, and product design to ensure that primitives are consistent with the strongest-available recommendations from trusted parties. If the product appears to be using custom or proprietary implementations that have not had sufficient public review and approval, then this is a significant concern.

Manual Analysis Moderate

Analyze the product to ensure that implementations for each primitive do not contain any known vulnerabilities and are not using any known-weak algorithms, including MD4, MD5, SHA1, DES, etc.

Dynamic Analysis with Manual Results Interpretation Moderate

For hardware, during the implementation (pre-Silicon / post-Silicon) phase, dynamic tests should be done to ensure that outputs from cryptographic routines are indeed working properly, such as test vectors provided by NIST [REF-1236].

Dynamic Analysis with Manual Results Interpretation Moderate

It needs to be determined if the output of a cryptographic primitive is lacking entropy, which is one clear sign that something went wrong with the crypto implementation. There exist many methods of measuring the entropy of a bytestream, from sophisticated ones (like calculating Shannon's entropy of a sequence of characters) to crude ones (by compressing it and comparing the size of the original bytestream vs. the compressed - a truly random byte stream should not be compressible and hence the uncompressed and compressed bytestreams should be nearly identical in size).

Correction automatique Plexicus

Plexicus détecte automatiquement CWE-1240 et ouvre une PR de correction en moins de 60 secondes.

Codex Remedium analyse chaque commit, identifie cette faiblesse précise et livre une pull request prête à être relue avec le correctif. Pas de tickets. Pas de transferts.

Obtenir une démo Essayer Plexicus gratuitement
Questions fréquentes

Frequently asked questions

Qu'est-ce que CWE-1240 ?

This weakness occurs when a product uses a custom, unverified, or non-compliant implementation of a cryptographic algorithm instead of a trusted, standard solution.

Quelle est la gravité de CWE-1240 ?

MITRE n'a pas publié de note de probabilité d'exploitation pour cette faiblesse. Traitez-la comme un impact moyen jusqu'à ce que votre modèle de menace prouve le contraire.

Quels langages ou plateformes sont affectés par CWE-1240 ?

MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, System on Chip.

Comment puis-je prévenir CWE-1240 ?

Require compliance with the strongest-available recommendations from trusted parties, and require that compliance must be kept up-to-date, since recommendations evolve over time. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-267]. Ensure that the architecture/design uses the strongest-available primitives and algorithms from trusted parties. For example, US government systems require FIPS 140-3 certification, which supersedes…

Comment Plexicus détecte et corrige CWE-1240 ?

Le moteur SAST de Plexicus reconnaît la signature de flux de données de CWE-1240 à chaque commit. Lorsqu'une correspondance est trouvée, notre agent Codex Remedium ouvre une PR de correction avec le code corrigé, les tests et un résumé d'une ligne pour le relecteur.

Où puis-je en savoir plus sur CWE-1240 ?

MITRE publie la définition canonique à https://cwe.mitre.org/data/definitions/1240.html. Vous pouvez également consulter la documentation OWASP et NIST pour des conseils adjacents.

Faiblesses associées

Weaknesses related to CWE-1240

CWE-327 Parent

Use of a Broken or Risky Cryptographic Algorithm

The software relies on a cryptographic algorithm or protocol that is either fundamentally flawed or considered too weak by modern security…

CWE-328 Frère

Use of Weak Hash

This vulnerability occurs when software uses a hashing algorithm that is cryptographically weak, allowing attackers to feasibly reverse…

CWE-780 Frère

Use of RSA Algorithm without OAEP

This vulnerability occurs when an application implements RSA encryption but fails to use Optimal Asymmetric Encryption Padding (OAEP),…

CWE-916 Frère

Use of Password Hash With Insufficient Computational Effort

This vulnerability occurs when a system protects passwords by hashing them, but uses a hashing algorithm that is too fast or…

Ressources

Further reading

Prêt quand vous l'êtes

Arrêtez de payer par développeur.
Commencez à fermer la boucle.

Plexicus est l'ASPM natif IA qui scanne, filtre, corrige, penteste et explique — de façon autonome. Développeurs illimités, dépôts illimités, actions IA à usage équitable. Vrai niveau gratuit, €269/mo annuel quand vous êtes prêt.

Commencer gratuitement Réserver une démo