[WEB SECURITY] Log Injection
daniel.grzelak at sift.com.au
Wed Feb 14 17:06:48 EST 2007
Log injection seems to be a topic that is inherently simple and is usually
treated somewhat lightly. However, from our experience the unfortunate
reality appears to be that most applications are vulnerable (particularly
web applications) and most application assessment reports/methodologies
don't touch on the issue. Even when the issue is addressed, it seems to be
trivialised. Hence, a paper has been published discussing log injection,
both from the developer's point of view and the tester's point of view. It
covers many forms of log injection and provides practical advice on
analysing and countering vulnerabilities.
The paper is available here:
Log Injection: Subverting Accountability
As outlined by the ASX Corporate Governance Council in their "Principles of
Good Corporate Governance and Best Practice Recommendations":
"Good corporate governance structures encourage companies to create value
(through entrepreneurism, innovation, development and exploration) and
provide accountability and control systems commensurate with the risks
Often much of this accountability is realised in the form of system logging.
Unfortunately, while the logging mechanisms have become commonplace and are
regarded as a necessity, their implementations are often flawed and the logs
themselves are often ignored. Despite these failings, it is crucial to
ensure that logs are accurate so that when it becomes necessary to use them,
the information they contain can be depended upon.
Malicious individuals and those who may wish to cover their tracks have
found ways to subvert the logging process. There are many ways to protect
the logging process; however log injection is one attack that is difficult
to defend against and can be applied in many forms, several of which include
subverting countermeasures specifically developed to protect against it.
What is log injection?
A log injection vulnerability occurs when a poorly-written program uses
user-provided data to write to a system or application log without any
security pre-processing. If an attacker controls this data they can then
manipulate entries in the log for their purposes. Based on their level of
knowledge of log format and content, this often results in the ability to
add new entries and falsify events and actions.
Why is logging Important?
>From a corporate perspective the biggest driver for logging is compliance.
Whether it driven by a necessity to comply with legislation, industry
regulation or self imposed mandates, auditability and subsequent
accountability are usually high on the list of requirements. This is
typified by the ISO17799 requirement that "Systems should be monitored and
information security events should be recorded. Operator logs and fault
logging should be used to ensure information system problems are identified"
The above translates into the following operational drivers for logging:
- Debugging and performance management
- Event detection and incident analysis
- Evidence and accountability
Typically logs are created for debugging purposes early in the application
development lifecycle and sometimes these features are also transferred to
production systems. In terms of log injection, debug logs are of the least
value to attackers and are typically only attacked for nuisance value.
Where integrity becomes important is in the detection and handling of
malicious activity. Manipulating log entries and inserting new data makes
analysis extremely difficult and is likely to mask unauthorised acts. Should
the activity be detected, presenting logs as evidence for legal or internal
accountability purposes can be seriously hampered. Any failure to maintain
the integrity of logs increases the probability the evidentiary value they
contain can be successfully challenged.
What types of log injection attacks are there?
Log injection attacks are highly dependant on the implementation of the
logging mechanism, and the visibility of internal details to the attacker.
Some subversion techniques identified in the full paper include:
o Supplying 'new line' characters to create new entries o Supplying
characters which separate different fields of an entry o Inserting false
timestamps o Abusing viewers software that word wraps entries to make it
appear that multiple entries exist o Supplying HTML code which will be
rendered in a browser as something other than the entry o Including terminal
special characters that can clear the screen or otherwise obfuscate entries
How can an organisation be protected?
Different systems require different approaches to logging. Some require a
lightweight solution with little overhead, while others require
functionality that necessitates a large custom implementation. However,
functional requirements must always be considered in light of security risks
An ideal solution incorporates digital signatures stored out of band,
integrated with a custom viewing platform that allows for raw viewing. In
practice, using a combination of the simplest defences combined with an
understanding of their relative strengths and weaknesses is likely to be the
best approach. Most importantly, it is important to be aware that logging
components cannot always be trusted and everything is not always as it
A long-held industry principle dictates that the best security mechanisms
are published and can withstand open scrutiny over an extended period of
time. However, where this is not a viable option, log formats and other
implementation details may be closely guarded in an attempt to withhold
vital information from attackers to reduce the risk of successful
Developers, analysts, architects, and testers working with logging systems
are encouraged to review and implement the recommendations of the full
technical paper which accompanies this executive brief.
Join us on IRC: irc.freenode.net #webappsec
The Web Security Mailing List:
The Web Security Mailing List Archives:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
More information about the websecurity