mnoorenberghe
commented
5 years ago 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
stale[bot]
Describe Your Environment
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
Logview pageTo 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=createExpected behavior
Debug Logs