CWE-778 is not a bug that an attacker triggers directly. It is a gap that lets everything else go unnoticed. When a security-critical event happens, the product either does not record it or leaves out the details you need to understand it.
It affects every team that will one day have to answer the question "what happened?" after an incident.
How it happens
Common causes:
- Failed authentication is not logged, or is logged without source address or username.
- Privileged actions such as role changes, token creation or data export leave no record.
- Logs exist but omit who, what, when and from where.
- In the cloud, detailed audit logging often needs to be switched on, and it can cost money. MITRE points out that in Azure the default value for logging is disabled, which can leave telemetry gaps in critical audit logs.
The MITRE record lists real cases. CVE-2008-4315 describes a server that does not log failed authentication attempts, making brute force password guessing easier to carry out without being detected. CVE-2008-1203 is the same pattern in an admin interface. CVE-2007-3730 is a POP server whose default configuration did not log source IP or username for login attempts.
What an attacker gains
The record lists the consequences as non-repudiation and hiding activities. With no trail, attackers can act without being noticed, and defenders cannot work out the cause of a problem afterward or prove who did what.
How to find it
- List the security events your system should record, then trigger each one in a test environment and look for the log line.
- Check what each entry contains. A line that says "login failed" with no user, no source and no timestamp is not enough.
- Review default settings on cloud services and managed products. Confirm that audit logging is on.
- MITRE says static analysis can find some instances, for example by flagging authentication code paths with no logging call.
How to fix it
Log the events that matter for security, with enough detail to act on:
- Successful and failed logins, lockouts, password and MFA changes.
- Permission and role changes.
- Access denied decisions.
- Administrative and data export actions.
- Input validation failures that look like probing.
Each record should have a timestamp, the actor, the source address, the action and the result. Send logs off the host to a separate store so an intruder cannot erase them, and alert on patterns such as many failures from one source.
log.warning(
"auth_failed user=%s src_ip=%s reason=%s",
username, request.remote_addr, reason,
)
Do not write secrets, passwords or full tokens into the log. Missing logs and leaky logs are opposite problems, and both are weaknesses. Also avoid the other extreme, which is covered in CWE-779 on logging excessive data.
Try it yourself
Insufficient logging is easier to fix when you can see changes over time. This demo shows how ongoing monitoring surfaces new findings.
Click through it at your own pace, or open it full screen.
Quick check
Is a log line that says only "login failed" enough?
No. Without the account, the source address and the time, you cannot tell a typo from a brute force attempt.
Why ship logs to a separate system?
An attacker with access to the host can edit or delete local logs. A separate store keeps the trail intact.
