This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Log Injection"

From OWASP
Jump to: navigation, search
(Re-designed by explaining the readers what is Log injection and when it is possible in detail also provided adequate prevention measures.)
m (→‎Code Execution via Log Injection)
 
(11 intermediate revisions by 2 users not shown)
Line 5: Line 5:
 
==Description==
 
==Description==
  
−
First to understand Log injection, lets first know what a log file is.
+
Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.
  
−
'''Log file''' - It is basically a file, probably residing on some server, database (depending on what kind of logs it notes down) or any other essential networking components, that keeps an accurate record of all the transactions and events taking place interminably from the start until the service has decided to terminate.
+
Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs. This is called log injection.
  
−
All major and vital decisions in relation to the web application are taken place by analyzing these logs.
+
Log injection vulnerabilities occur when:
  
−
So this points out 2 important things:
+
# Data enters an application from an untrusted source.
−
* How important logs are to every single organization existing over the web!
+
# The data is written to an application or system log file.
−
* Log files exist in the backend of practically anywhere you navigate on the web.
 
−
'''So how does log poisoning work?'''
 
  
−
First a PHP code is injected in the log file, and it can be achieved by doing something like:
+
Successful log injection attacks can cause:
−
  <code><nowiki>https://www.somedomain.tld/index.php?file=</nowiki><?php echo phpinfo(); ?></code>
+
 
 +
# Injection of new/bogus log events (log forging via log injection)
 +
# Injection of XSS attacks, hoping that the malicious log event is viewed in a vulnerable web application
 +
# Injection of commands that parsers (like PHP parsers) could execute
  
−
As it is an HTTP GET request, it will end up in the log file. This stage it is called '''log file poisoning'''. Although the above request will most likely display an error, by re-reading the web server's log file, the code will be executed.
+
== Log Forging ==
  
−
'''Code Execution'''
+
In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1].
  
−
Now the web server log file is poisoned with the previously injected PHP code, but '''loading the web server's log file''' the following will happen:
+
=== Log Forging Example ===
  
−
So the most important factor we can note here is, log files are not executable! But if the server side programming language is the same as the code injected(which is the obvious case) the server while loading the log file:
+
The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.
−
# (PHP) reads the log file.
 
−
# (PHP) detects the (PHP) code in the log file.
 
−
# (PHP) will parse the (PHP) code and parse its output to the user's browser, displaying the (PHP) info.
 
−
Also the most important thing to note down is the way it works:
 
−
* ''(Log_injection(Code_Execution(parsing)))''
 
−
# Read access to log files is enough to execute code after they're poisoned (this requires LFI)
 
  
−
'''Now let's understand when can all this work?'''
+
<pre>
 +
...
 +
String val = request.getParameter("val");
 +
try {
 +
int value = Integer.parseInt(val);
 +
}
 +
catch (NumberFormatException) {
 +
log.info("Failed to parse val = " + val);
 +
}
 +
...
 +
</pre>
  
−
Let's consider we have found a LFI(Local File Inclusion) vulnerability
+
If a user submits the string "twenty-one" for val, the following entry is logged:
−
<nowiki>http://vulnerable_host/preview.php?file=example.html</nowiki>
 
−
If an attacker is lucky enough, and instead of selecting the appropriate page from the array by its name, the script directly includes the input parameter, it is possible to include arbitrary files on the server (Also while at it lets assume for a moment that the PHP open_basedir* is not configured).
 
  
−
Now this would load the preview.php file which is located in the same directory as where the web pages served.
+
<pre>
 +
INFO: Failed to parse val=twenty-one
 +
</pre>
  
−
'''The POC(Proof of Concept) would be: ''To load a log_file file(in our case).'''''
+
However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged:
−
<nowiki>http://vulnerable_host/preview.php?file=../../../../etc/access_log</nowiki>
 
−
In this scenario, let's assume that the log file is loaded and displayed in the user's browser. In this case it's already bad enough because you can basically load any file that the www-user has read access to. And something like this would be displayed:
 
−
root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin alex:x:500:500:alex:/home/alex:/bin/bash margo:x:501:501::/home/margo:/bin/bash ...
 
−
So this answers when a PHP code can be injected to the log file.
 
  
−
So the above equation can be revised as:
+
<pre>
 +
INFO: Failed to parse val=twenty-one
  
−
''LFI(Log_injection(Code_Execution(parsing)))''
+
INFO: User logged out=badguy
 +
</pre>
  
−
== How can Log Injection be prevented? ==
+
Clearly, attackers can use this same mechanism to insert arbitrary log entries.
−
* We need to include input validation both at server and client’s end. The suspected characters can be sanitized and replaced.
 
−
* The application used to render logs has to be thoroughly scrutinized for vulnerabilities.
 
  
−
* Instead of directly passing messages via parameters, log codes could be passed. However it is still exploitable.
+
== Code Execution via Log Injection ==
−
* Don’t use API Calls to log actions, as there API’s will be visible in browser network calls.
 
−
* In case of a need, pass user ids or publicly non identifiable values as parameters in logging endpoints.
 
−
* Use proper error codes and identifiable error messages.
 
  
−
== References ==
+
PHP code can easily be added to a log file, for example:
−
* https://security.stackexchange.com/questions/197871/are-log-files-executable-files<nowiki/>(Self asked question)
+
<code><nowiki>https://www.somedomain.tld/index.php?file=</nowiki><?php echo phpinfo(); ?></code>
−
* https://medium.com/@shatabda/security-log-injection-what-how-a510cfc0f73b
+
 
−
* https://www.geeksforgeeks.org/log-injection/
+
This stage it is called '''log file poisoning'''. If the log file is staged on a public directory and can be accessed via a HTTP GET request, the embedded PHP command may execute in certain circumstances. This is a form of [[Command Injection]] via Log Injection.
−
* https://affinity-it-security.com/what-is-log-injection/
 
  
 
==References==
 
==References==
Line 70: Line 67:
 
* [1] A. Muffet. The night the log was forged. http://doc.novsu.ac.ru/oreilly/tcpip/puis/ch10_05.htm.
 
* [1] A. Muffet. The night the log was forged. http://doc.novsu.ac.ru/oreilly/tcpip/puis/ch10_05.htm.
 
* [2] G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
 
* [2] G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
 +
* https://medium.com/@shatabda/security-log-injection-what-how-a510cfc0f73b
 +
* https://www.geeksforgeeks.org/log-injection/
 +
* https://affinity-it-security.com/what-is-log-injection/
  
 
__NOTOC__
 
__NOTOC__
  
 
[[Category:Attack]]
 
[[Category:Attack]]

Latest revision as of 19:04, 12 February 2019

This is an Attack. To view all attacks, please see the Attack Category page.


Last revision (mm/dd/yy): 02/12/2019

Description

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs. This is called log injection.

Log injection vulnerabilities occur when:

  1. Data enters an application from an untrusted source.
  2. The data is written to an application or system log file.

Successful log injection attacks can cause:

  1. Injection of new/bogus log events (log forging via log injection)
  2. Injection of XSS attacks, hoping that the malicious log event is viewed in a vulnerable web application
  3. Injection of commands that parsers (like PHP parsers) could execute

Log Forging

In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1].

Log Forging Example

The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened. 

	...
	String val = request.getParameter("val");
	try {
		int value = Integer.parseInt(val);
	}
	catch (NumberFormatException) {
		log.info("Failed to parse val = " + val);
	}
	...

If a user submits the string "twenty-one" for val, the following entry is logged: 

	INFO: Failed to parse val=twenty-one

However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged: 

	INFO: Failed to parse val=twenty-one

	INFO: User logged out=badguy

Clearly, attackers can use this same mechanism to insert arbitrary log entries.

Code Execution via Log Injection

PHP code can easily be added to a log file, for example: 

https://www.somedomain.tld/index.php?file=<?php echo phpinfo(); ?>

This stage it is called log file poisoning. If the log file is staged on a public directory and can be accessed via a HTTP GET request, the embedded PHP command may execute in certain circumstances. This is a form of Command Injection via Log Injection.

References

Retrieved from "https://wiki.owasp.org/index.php?title=Log_Injection&oldid=247367"