Security: Log Injection. What? How?

To maintain a history of events and record every transaction, web applications maintain logs. Logs are a source of information that can be used for debugging, data collection and performance optimizations. An ample amount of work and vital decisions are taken related to the application, based on these logs. What if these logs are manipulated? That can lead to a number of problems.

What is Log Injection?
Log Injection (or Log Forgery) is a vulnerability that arises when un-trusted and un-validated input is allowed to be printed in system log files. As a result, an attacker can insert malicious data and false entries into the logs and ultimately corrupt the file. The corrupted files can be used to cover the tracks of an hacking attempt.

Consider the following scenario:
A web application logs failed login attempts by users. The following is a sample code used by the application:

String userID = request.getParameter(“userID”);
try 
{
 int user = Integer.parseInt(username);
 ...
 log.info(“Successful Login, ID=” + value);
}
catch (NumberFormatException) 
{
 log.info(“Failed Login, ID=” + value);
}

The monitoring system triggers an alert after the limit for failed attempts is exceeded by an user. The system may be configured to alert in case of any Brute force attacks. A log is printed along with the alert, every time the limit is reached.

May 27:2018:10:43:10: Failed Login, ID=sha

The system resets if a successful login occurs before reaching the alert limit. This can be exploited by an attacker trying to brute force into the system. The attacker can forge the logs by inserting a fake record (successful login event) to ensure the system gets reset before the limit is reached. The following is a sample user input:

Sep%2011%3A2018%3A01%3A07%3A13%3A%20Successful%20Login%2C%20ID%3Dsha
which is equivalent to:
Sep 11:2018:01:07:13: Successful Login, ID=sha

In absence of any validation or sanitization of user input, the forged logs can easily neutralize the monitoring system. In this case, there will be two logs printed : one legitimate and the other fake.

Sep 11:2018:01:07:13: Failed Login, Id=sha
Sep 11:2018:01:07:13: Successful Login, Id=sha

There is also a possibility of a XSS and other attacks since the logs may be directly rendered in the browser by a cloud log application. This can expose cookies and other sensitive information of the admin user to the attacker.

How to prevent?

• 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 scrutinised for vulnerabilities.

Disclaimer: The information published in this article is only for educational purposes. The content of this article is based on my personal learning and experience. Any misuse of information will not be responsibility of the author.