Log Injection

[Loginsoft-Research]

Describe Your Environment

• ZoneMinder v1.33.1
• Installed from - ppa:iconnor/zoneminder-master

Describe the bug
This attack targets the log files of the target host. The attacker injects, manipulates or forges malicious log entries in the log file, allowing him to mislead a log audit, cover traces of attack, or perform other malicious actions. The target host is not properly controlling log access. As a result tainted data is resulting in the log files leading to a failure in accountability, non-repudiation and incident forensics capability

Most components of ZoneMinder can emit informational, warning, error and debug messages in a standard format. These messages can be logged in..

Example of these messages is:

03/01/06 13:46:00.166046 zmpkg[11148].INF [Command: start]

The first part refers to the date and time of the entry, the next section is the name (or an abbreviated version) of the script, followed by the process id in square brackets, a severity code (INF, WAR, ERR or DBG) and the debug text.

All the mentioned information can be manipulated & inject by an attacker by enticing the victim to visit a specially crafted link, which in turn will inject a custom Log message provided by the attacker. The same will be reflected in the Log view page

To Reproduce
Affected URL :
http://localhost/zm/index.php

POST Data - browser[name]=chrome&browser[platform]=win&browser[version]=41&file=admin&level=INF&line=128&message=User 'admin' Logged in&page=1&request=log&task=create

• Navigate to the Affected URL, Custom Log will be injected.
• Navigate to the http://localhost/zm/index.php?view=log, Log will be visible.

Expected behavior

• Do not allow tainted data to be written in the log file without prior input validation. Whitelisting may be used to properly validate the
  data.

Debug Logs

None

[mnoorenberghe]

The first part refers to the date and time of the entry, the next section is the name (or an abbreviated version) of the script, followed by the process id in square brackets, a severity code (INF, WAR, ERR or DBG) and the debug text.

All the mentioned information can be manipulated & inject by an attacker by enticing the victim to visit a specially crafted link, which in turn will inject a custom Log message provided by the attacker.

This is a bit of an overstatement… we already validate the log level, the date/time come from the server, and the component will always be "web_js". Therefore, the only ones that can be spoofed are:

• message - This is the main concern though an auditor should notice that "web_js" isn't the correct component for most operations.
• file - We convert absolute URLs to relative ones. Perhaps we could use the referrer header though that is spoofable in different ways.
• line - I'm adding an integer check but other than that I don't think spoofing this is really a problem.

Note that this API already falls under a CSRF check so an attacker would need a CSRF token to log (though that's not hard since even un-authenticated user can log).

Perhaps we should include the user ID / username in these logs (new column or message prefix?)? We could also only allow logging for logged-in users since I believe it's mostly diagnostic logging (CSP and JS error reports)? That would mean no logging for sites not using auth though. What does @ZoneMinder/comitters think?

[connortechnology]

Adding User info is definitely on my todo list. There are a lot of actions that should be logged. Things like editing a monitor. Who changed it and what did they change. etc

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.