CWE-345, Insufficient Verification of Data Authenticity, is a class level weakness. MITRE describes it as a product that does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
Many other weaknesses sit underneath it: missing signature checks, unchecked integrity values, spoofable origins. If your software takes in anything from outside, such as updates, packages, configuration, messages or files, this weakness is in your threat model whether you named it or not.
How it happens
Data arrives. The software asks, does this parse, and does it look right? Those are questions about format. They say nothing about who produced it or whether someone altered it on the way.
The result is a program that will accept any well formed input from any source. If an attacker can place data in the path, by controlling a network hop, a download mirror, a file share or a build step, then what they place is accepted.
MITRE's observed examples come from industrial systems. CVE-2022-30260 and CVE-2022-30267 describe a distributed control system that does not sign firmware images and relies only on insecure checksums for integrity checks. CVE-2022-30272 describes a remote terminal unit with the same design: no signatures on firmware images, and reliance on insecure checksums.
The detail that matters is "insecure checksums." A checksum shipped next to the data proves nothing about origin. An attacker who replaces the firmware replaces the checksum too.
What an attacker gains
MITRE lists integrity impact, with other effects that vary by context and an unexpected state. When the data is code, such as firmware or an update, accepting it means running it. When the data is configuration or a message, it means changing behavior the owner never approved.
How to find it
MITRE notes that automated static analysis (SAST) can find some instances of this weakness by analyzing source code without running it. Add a plain review of every data entry point.
- List every place your software loads data it did not create: updates, plugins, packages, config, uploads, messages.
- For each, write down the sentence "we know this came from X because Y." If Y is "it was in the right folder" or "the checksum matched a file next to it," that is a gap.
- Check update paths first. They carry code, so they carry the most risk.
- Ask whether any check can be satisfied by the attacker, for example by recomputing a checksum.
In a software supply chain, the same question applies to dependencies. Where did this package come from, and who vouches for it?
How to fix it
MITRE's record lists no mitigations for this class, so the steps below are standard practice following from the definition.
- Use digital signatures, not bare checksums, for anything that carries code or trust. The signature binds the data to a key.
- Verify the signature against a key you already hold, obtained through a separate channel. A key delivered with the file proves nothing.
- Verify before you parse or use the data. Reject on any failure, with no fallback to an unsigned path.
- Pin or tightly control which keys are accepted, and plan for key rotation and revocation.
- For software you consume, prefer sources that publish signed artifacts and provenance records, and verify them in your pipeline.
A simple command line version of the idea:
# Weak: the checksum came from the same server as the file
curl -O https://example.org/tool.tar.gz
curl -O https://example.org/tool.tar.gz.sha256
sha256sum -c tool.tar.gz.sha256
# Better: verify a signature with a key you obtained separately
gpg --verify tool.tar.gz.sig tool.tar.gz
In the first case an attacker who controls the server controls both files. In the second, they would need the signing key.
Try it yourself
Provenance and attestation are the supply chain answer to this weakness. The demo walks through checking where a component came from and what is vouched for.
Click through it at your own pace, or open it full screen.
You can also check your own dependencies. The free scan at gold.safeguard.sh/scan runs in your browser with no login. Your file stays on your machine, up to 100 dependencies.
Quick check
Why is a checksum next to a download not proof of authenticity?
An attacker who can replace the file can replace the checksum with it. A signature checked against a key you already trust ties the data to its origin.
What did the firmware examples in the MITRE record have in common?
The devices did not sign firmware images and relied on insecure checksums for integrity, so altered firmware could pass the check.
When should verification happen?
Before the data is parsed or used, and failure should reject the data outright.
Sources
- MITRE CWE-345: https://cwe.mitre.org/data/definitions/345.html
