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.
Threat Mapped score: 1.8
Industry: Finiancial
Threat priority: P4 - Informational (Low)
CVE: CVE-2008-4315
server does not log failed authentication attempts, making it easier for attackers to perform brute force password guessing without being detected
CVE: CVE-2008-1203
admin interface does not log failed authentication attempts, making it easier for attackers to perform brute force password guessing without being detected
CVE: CVE-2007-3730
default configuration for POP server does not log source IP or username for login attempts
CVE: CVE-2007-1225
proxy does not log requests without "http://" in the URL, allowing web surfers to access restricted web content without detection
CVE: CVE-2003-1566
web server does not log requests for a non-standard request type
N/A
N/A
| Phase | Note |
|---|---|
| Operation | COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic. |
Intro: The example below shows a configuration for the service security audit feature in the Windows Communication Foundation (WCF).
Body: 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.
<system.serviceModel> <behaviors> <serviceBehaviors> <behavior name="NewBehavior"> <serviceSecurityAudit auditLogLocation="Default" suppressAuditFailure="false" serviceAuthorizationAuditLevel="None" messageAuthenticationAuditLevel="None" /> ... </system.serviceModel>Intro: 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.
Body: 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.
if LoginUser(){ // Login successful RunProgram(); } else { // Login unsuccessful LoginRetry(); }Intro: Consider this command for updating Azure's Storage Logging for Blob service, adapted from [REF-1307]:
Body: 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:
az storage logging update --account-name --account-key --services b --log d --retention 90