CWE-327, Use of a Broken or Risky Cryptographic Algorithm, is about choosing the wrong tool. The product uses an algorithm or protocol that has been broken, weakened, or was never sound to begin with.
It hits any codebase that encrypts, hashes or signs anything. That is nearly all of them, and the problem often hides in dependencies and old modules nobody has opened in years.
How it happens
MITRE explains that cryptography exists to scramble data so unauthorized actors cannot observe or influence it. It is very difficult to produce a secure algorithm, and even high profile algorithms by accomplished experts have been broken. Well known techniques exist to break or weaken various kinds of cryptography.
Several patterns recur:
- An old algorithm persists because it was once the standard. MITRE names MD4, MD5, SHA1 and DES as algorithms once regarded as strong that have since weakened. Some thought to need a billion years of computing time can now be broken in days or hours.
- A team invents its own scheme. MITRE warns against custom or private algorithms, since they will likely be exposed to attacks cryptographers already understand, and reverse engineering is mature.
- Obfuscation is mistaken for encryption.
- A mode of operation leaks structure.
# Vulnerable: MD5 for integrity, DES for confidentiality
digest = hashlib.md5(data).hexdigest()
cipher = DES.new(key, DES.MODE_ECB)
The observed examples show how basic some of these are. CVE-2022-30273 is a SCADA protocol with a legacy mode using the Tiny Encryption Algorithm in ECB mode, which leaks patterns in the data. CVE-2022-30320 is a controller using a protocol with a cryptographically insecure hash for passwords. CVE-2008-3775 is a product using "ROT-25" to obfuscate a registry password, and CVE-2007-4150 used only XOR to obfuscate sensitive data.
What an attacker gains
Per the record:
- Confidentiality. Sensitive data can be read.
- Integrity. Data can be modified in unexpected ways.
- Accountability. If the algorithm backs digital signatures, an attacker can spoof the source of data and deny or fake who did what.
How to find it
MITRE lists several approaches. Automated analysis helps recognize commonly used libraries or features that have become obsolete. Static analysis of binaries or bytecode can cheaply find calls to weak primitives. Manual analysis, including penetration testing, finds design level issues.
Simple checks to run now:
- Search your code for names such as md5, sha1, des, rc4 and ecb.
- List your TLS configuration and protocol versions.
- Check the cryptographic libraries in your dependency tree for deprecation notices.
Dependencies deserve their own pass. A library you did not write can carry a risky algorithm into your product. Scanning your manifest shows which components have known weaknesses, and the free in-browser scan runs without a login and keeps your file on your machine, for up to 100 dependencies.
Try it yourself
This demo shows a static code scan flagging risky calls.
Click through it at your own pace, or open it full screen.
How to fix it
MITRE's mitigations, in plain steps:
- Use strong, up to date algorithms from a well vetted source that experts currently consider strong, and use well tested implementations. The source code should be available for analysis. For US government systems, FIPS 140-2 certification is cited as an example.
- Do not develop custom or private cryptographic algorithms.
- Periodically confirm your cryptography has not become obsolete.
- Design so one algorithm can be replaced with another in the next version. Use wrappers where possible to keep the interface uniform, which makes upgrades easier. For hardware, design at the intellectual property level so an algorithm can be swapped in the next generation.
- Manage and protect keys. If keys can be guessed or stolen, the strength of the algorithm is irrelevant.
# Better: modern primitives from a maintained library
digest = hashlib.sha256(data).hexdigest()
ct = AESGCM(key).encrypt(nonce, data, None)
For passwords, use a password hashing function, not a general hash. See CWE-328.
Quick check
Is XOR with a secret value encryption?
No. A repeating XOR pattern is easy to recover, as CVE-2007-4150 shows. Use a standard authenticated cipher.
Why use wrappers around crypto calls?
One place to change when an algorithm ages out, instead of hunting through the codebase.
Is a custom algorithm safer if attackers do not know it?
No. MITRE notes that if an algorithm is only safe while it stays secret, it is especially weak.
