Improper logging leads to vulnerabilities
Before we delve into the details of improper logging and its security ramification, let me quickly walk you through CWE ( Common Weakness Enumeration) and how does it help you manage bugs in your software. Every line of code that you write can introduce bugs into your software. Weakness in software can be categorized using CWE ( Common Weakness Enumeration)[1]. CWE is a community developed and funded by the Dept. of Homeland Security. It lists software and hardware weakness types that lead to security vulnerabilities. “Weaknesses” are flaws, faults, bugs, or other errors in software or hardware implementation, code, design, or architecture. If weaknesses are left unaddressed, it could result in systems, networks, or hardware being vulnerable to attacks.
Under software development, the CWE list contains 40 categories and 419 weaknesses[1]. It includes all aspects of the software development lifecycle, including both architecture and implementation.
Improper Output Neutralization for Logs(CWE-117)
The software does not neutralize or incorrectly neutralizes entries that are logged. This type of weakness allows an attacker to forge or inject a log entry. For example, this weakness can be exploited to inject fake log entries with fake timestamps using CRLF injection. Parsing the entries before writing into logs is a good practice. Parse your logging message before passing it on to your logger.
Truncation of Security-relevant Information(CWE-222)
The application truncates log entries of security-relevant information in a way that can obscure the source or nature of an attack. I could not find a vulnerable code example related to this weakness and will be revisited at a later date.
Omission of Security-relevant Information(CWE-223)
The application does not record or display information that would be important for identifying the source or nature of an attack or a false positive. This is part of the OWASP Top Ten.
Obscured Security-relevant Information by Alternate Name (CWE-224)
The software records security-relevant information according to an alternate name of the affected entity, instead of the canonical name.
Insertion of Sensitive Information into Log File(CWE-532)
Information written to log files can be sensitive and give valuable guidance to an attacker or expose sensitive user information. We could give multiple examples for this weakness. Here’s one that tops my chart.
Insufficient Logging (CWE-778)
When a security-critical event occurs, the software either does not record the event or omits details about the event when logging it. This is part of the OWASP Top Ten.
Logging of Excessive Data (CWE-779)
The software logs too much information, making log files hard to process and possibly hindering recovery efforts or forensic analysis after an attack.
Logging the right information and right verbosity based on the environment type is very important. Sufficient level of information is very important for intrusion detection and recovery. Over logging can negatively impact the same problem. Protect your log from unauthorized read and writes. Sensitive information should not be written to logs. Let me repeat, do not log sensitive information outside a trust boundary.
licensed under CC BY 4.0
Reference
- CWE VIEW: Software Development, https://cwe.mitre.org/data/definitions/699.html. 2021–08.
- Mark Dowd, John McDonald and Justin Schuh. “The Art of Software Security Assessment”. Chapter 2, “Accountability”, Page 40. 1st Edition. Addison Wesley. 2006.
- Greg Hoglund and Gary McGraw. “Exploiting Software: How to Break Code”. Addison-Wesley. 2004
- Michael Howard and David LeBlanc. “Writing Secure Code”. 2nd Edition. Microsoft Press. 2003.
- OWASP. “OWASP TOP 10”, https://owasp.org/www-project-top-ten/ . 2021–08
