When a security-critical event occurs, the product either does not record the event or omits important details about the event when logging it.
View on MITREWhen security-critical events are not logged properly, such as a failed login attempt, this can make malicious behavior more difficult to detect and may hinder forensic analysis after an attack succeeds. As organizations adopt cloud storage resources, these technologies often require configuration changes to enable detailed logging information, since detailed logging can incur additional costs. This could lead to telemetry gaps in critical audit logs. For example, in Azure, the default value for logging is disabled.
If security critical information is not recorded, there will be no trail for forensic analysis and discovering the cause of problems or the source of attacks may become more difficult or impossible.
Use a centralized logging mechanism that supports multiple levels of detail.
Ensure that all security-related successes and failures can be logged. When storing data in the cloud (e.g., AWS S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to enable and capture detailed logging information.
Be sure to set the level of logging appropriately in a production environment. Sufficient data should be logged to enable system administrators to detect attacks, diagnose errors, and recover from attacks. At the same time, logging too much data (CWE-779) can cause the same problems, including unexpected costs when using a cloud environment.
To enable storage logging using Azure's Portal, navigate to the name of the Storage Account, locate Monitoring (CLASSIC) section, and select Diagnostic settings (classic). For each of the various properties (blob, file, table, queue), ensure the status is properly set for the desired logging data. If using PowerShell, the Set-AzStorageServiceLoggingProperty command could be called using appropriate -ServiceType, -LoggingOperations, and -RetentionDays arguments.
No detection method information available for this CWE.
The example below shows a configuration for the service security audit feature in the Windows Communication Foundation (WCF).
The previous configuration file has effectively disabled the recording of security-critical events, which would force the administrator to look to other sources during debug or recovery efforts.
The example below shows a configuration for the service security audit feature in the Windows Communication Foundation (WCF).
The previous configuration file has effectively disabled the recording of security-critical events, which would force the administrator to look to other sources during debug or recovery efforts.
In the following Java example the code attempts to authenticate the user. If the login fails a retry is made. Proper restrictions on the number of login attempts are of course part of the retry functionality. Unfortunately, the failed login is not recorded and there would be no record of an adversary attempting to brute force the program.
It is recommended to log the failed login action. Note that unneutralized usernames should not be part of the log message, and passwords should never be part of the log message.
In the following Java example the code attempts to authenticate the user. If the login fails a retry is made. Proper restrictions on the number of login attempts are of course part of the retry functionality. Unfortunately, the failed login is not recorded and there would be no record of an adversary attempting to brute force the program.
It is recommended to log the failed login action. Note that unneutralized usernames should not be part of the log message, and passwords should never be part of the log message.
Consider this command for updating Azure's Storage Logging for Blob service, adapted from [REF-1307]:
The "--log d" portion of the command says to log deletes. However, the argument does not include the logging of writes and reads. Adding the "rw" arguments to the -log parameter will fix the issue:
Consider this command for updating Azure's Storage Logging for Blob service, adapted from [REF-1307]:
The "--log d" portion of the command says to log deletes. However, the argument does not include the logging of writes and reads. Adding the "rw" arguments to the -log parameter will fix the issue:
Consider this command for updating Azure's Storage Logging for Blob service, adapted from [REF-1307]:
The "--log d" portion of the command says to log deletes. However, the argument does not include the logging of writes and reads. Adding the "rw" arguments to the -log parameter will fix the issue:
server does not log failed authentication attempts, making it easier for attackers to perform brute force password guessing without being detected
View Detailsadmin interface does not log failed authentication attempts, making it easier for attackers to perform brute force password guessing without being detected
View Detailsdefault configuration for POP server does not log source IP or username for login attempts
View Detailsproxy does not log requests without "http://" in the URL, allowing web surfers to access restricted web content without detection
View DetailsCWE-778: Insufficient Logging is a Common Weakness Enumeration (CWE) entry maintained by MITRE. When a security-critical event occurs, the product either does not record the event or omits important details about the event when logging it. When security-critical events are not logged properly, such as a failed login attempt, this can make malicious behavior more difficult to detect and may hinder forensic analysis after an attack succeeds. As organizations adopt cloud storage resources, these technologies often require configuration changes to enable detailed logging information, since detailed logging can incur additional costs. This could lead to telemetry gaps in critical audit logs. For example, in Azure, the default value for logging is disabled.
If exploited, CWE-778 (Insufficient Logging) it can compromise Non-Repudiation, leading to outcomes such as Hide Activities.
Recommended mitigations for CWE-778 include: Use a centralized logging mechanism that supports multiple levels of detail. Ensure that all security-related successes and failures can be logged. When storing data in the cloud (e.g., AWS S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to enable and capture detailed logging information. Be sure to set the level of logging appropriately in a production environment. Sufficient data should be logged to enable system administrators to detect attacks, diagnose errors, and recover from attacks. At the same time, logging too much data (CWE-779) can cause the same problems, including unexpected costs when using a cloud environment.
CWE-778 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
MITRE documents real CVEs mapped to CWE-778, including CVE-2008-4315, CVE-2008-1203, CVE-2007-3730, CVE-2007-1225 and CVE-2003-1566. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.
A CWE (Common Weakness Enumeration) like CWE-778 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.