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 Rascunho
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.
Definição
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.
Impacto no mundo real
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"
Como os atacantes a exploram
Trajeto do atacante passo a passo
- 1
Identificar um caminho de código que trata input não confiável sem validação.
- 2
Criar um payload que explora o comportamento inseguro — injeção, traversal, overflow ou abuso de lógica.
- 3
Entregar o payload através de um pedido normal e observar a reação da aplicação.
- 4
Iterar até que a resposta exponha dados, execute código do atacante ou escale privilégios.
Exemplo de código vulnerável
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. Exemplo de código seguro
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.
Lista de verificação de prevenção
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.
Sinais de deteção
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).
O Plexicus deteta automaticamente o CWE-1240 e abre um PR de correção em menos de 60 segundos.
O Codex Remedium analisa cada commit, identifica esta fraqueza exata e entrega um pull request pronto para revisão com o patch. Sem tickets. Sem transferências.
Perguntas frequentes O que é o CWE-1240?
Qual a gravidade do CWE-1240?
Que linguagens ou plataformas são afetadas pelo CWE-1240?
Como posso prevenir o CWE-1240?
Como é que o Plexicus deteta e corrige o CWE-1240?
Onde posso saber mais sobre o CWE-1240?
Frequently asked questions
O que é o 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.
Qual a gravidade do CWE-1240?
A MITRE não publicou uma classificação de probabilidade de exploração para esta fraqueza. Trate-a como impacto médio até o seu modelo de ameaças provar o contrário.
Que linguagens ou plataformas são afetadas pelo CWE-1240?
MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, System on Chip.
Como posso prevenir o 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…
Como é que o Plexicus deteta e corrige o CWE-1240?
O motor SAST do Plexicus correlaciona a assinatura de fluxo de dados do CWE-1240 em cada commit. Quando é encontrada uma correspondência, o nosso agente Codex Remedium abre um PR de correção com o código corrigido, testes e um resumo de uma linha para o revisor.
Onde posso saber mais sobre o CWE-1240?
A MITRE publica a definição canónica em https://cwe.mitre.org/data/definitions/1240.html. Pode também consultar a documentação da OWASP e do NIST para orientações adjacentes.
Fraquezas relacionadas
Weaknesses related to CWE-1240
CWE-327 Pai
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 Irmão
Use of Weak Hash
This vulnerability occurs when software uses a hashing algorithm that is cryptographically weak, allowing attackers to feasibly reverse…
CWE-780 Irmão
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 Irmão
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…
Recursos
Further reading
- MITRE — CWE-1240 oficial 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
Pronto quando você estiver
Pare de pagar por desenvolvedor.
Comece a fechar o ciclo.
O Plexicus é o ASPM nativo de IA que verifica, filtra, corrige, pentesta e explica — de forma autónoma. Programadores ilimitados, repos ilimitados, ações de IA de utilização justa. Nível gratuito real, €269/mo anual quando estiver pronto.