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.
CWE-1240 Base Draft
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.
Definition
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.
Auswirkungen in der Praxis
Real-world CVEs caused by CWE-1240
-
software uses MD5, which is less safe than the default SHA-256 used by related products
-
Default configuration of product uses MD5 instead of stronger algorithms that are available, simplifying forgery of certificates.
-
identity card uses MD5 hash of a salt and password
-
personal key is transmitted over the network using a substitution cipher
-
product does not disable TLS-RSA cipher suites, allowing decryption of traffic if TLS 2.0 and secure ciphers are not enabled.
-
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.
-
LDAP interface allows use of weak ciphers
-
SCADA product allows "use of outdated cipher suites"
Wie Angreifer es ausnutzen
Angreiferpfad Schritt für Schritt
- 1
Identifiziere einen Codepfad, der nicht vertrauenswürdige Eingaben ohne Validierung verarbeitet.
- 2
Erzeuge eine Payload, die das unsichere Verhalten auslöst — Injection, Traversal, Overflow oder Logik-Missbrauch.
- 3
Liefere die Payload über einen normalen Request aus und beobachte die Reaktion der Anwendung.
- 4
Iteriere, bis die Antwort Daten preisgibt, Angreifer-Code ausführt oder Berechtigungen eskaliert.
Verwundbares Codebeispiel
Vulnerable Other
Re-using random values may compromise security.
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. Sicheres Codebeispiel
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.
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.
Präventions-Checkliste
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.
Erkennungssignale
How to detect CWE-1240
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.
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].
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).
CWE-1240
Don't catalog this weakness. Prove it's reachable.
Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.
Häufig gestellte Fragen Was ist CWE-1240?
Wie gravierend ist CWE-1240?
Welche Sprachen oder Plattformen sind von CWE-1240 betroffen?
Wie kann ich CWE-1240 verhindern?
Wie erkennt und behebt Plexicus CWE-1240?
Wo erfahre ich mehr über CWE-1240?
Frequently asked questions
Was ist 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.
Wie gravierend ist CWE-1240?
MITRE hat für diese Schwachstelle keine Exploit-Wahrscheinlichkeit veröffentlicht. Behandle sie als mittlere Auswirkung, bis dein Threat Model anderes belegt.
Welche Sprachen oder Plattformen sind von CWE-1240 betroffen?
MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, System on Chip.
Wie kann ich CWE-1240 verhindern?
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…
Wie erkennt und behebt Plexicus CWE-1240?
Die SAST-Engine von Plexicus erkennt die Datenfluss-Signatur von CWE-1240 bei jedem Commit. Bei einem Treffer öffnet unser Codex-Remedium-Agent einen Fix-PR mit korrigiertem Code, Tests und einer einzeiligen Zusammenfassung für den Reviewer.
Wo erfahre ich mehr über CWE-1240?
MITRE veröffentlicht die kanonische Definition unter https://cwe.mitre.org/data/definitions/1240.html. Für ergänzende Hinweise kannst du auch die OWASP- und NIST-Dokumentation heranziehen.
Verwandte Schwachstellen
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 Sibling
Use of Weak Hash
This vulnerability occurs when software uses a hashing algorithm that is cryptographically weak, allowing attackers to feasibly reverse…
CWE-780 Sibling
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 Sibling
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…
Ressourcen
Further reading
- MITRE — offizielle CWE-1240 https://cwe.mitre.org/data/definitions/1240.html
- FIPS PUB 140-2: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402.pdf
- Cryptographic primitive https://en.wikipedia.org/wiki/Cryptographic_primitive
- FIPS PUB 140-3: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES https://csrc.nist.gov/publications/detail/fips/140/3/final
- CAVP Testing: Individual Component Testing https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/component-testing
Bereit, das Wesentliche zu validieren?
Bereit zu validieren, was zählt.
Plexicus ist Proof-Driven AppSec: validierte Funde, kontextuelles Verständnis und geprüfte Remediation — in Evidenz verankert, mit Ihnen gescoped.