Log Injection

Log Injection is a very simple to carry out attack aimed at web applications. For the attacker its very simple to perform the attack. However, for the target web application or its administrator its very difficult to identify the scope of the attack performed and its impact. Web applications or any applications for the case, store huge amount of logs in the backend. They may be

1. Crash logs : Information about when the application got crashed, reason behind the crash, affected users etc.,
4. Error/Exception logs : Details like exception thrown from code, Stacktrace of the thrown exception.
7. Access logs : Access logs hold information about different end points accessed by a user in the system with time details.
10. GC logs : Usually stored by Java to keep track of Garbage collection.
13. Monitoring logs : Its useful when a user tries to do a suspicious activity on your site, you could detect it and send a mail to yourself to get notified or log it for future records.
16. Apart from these, there are many categories of application logs. These logs are very useful and absolutely necessary to debug application issues, audit and control, application performance monitoring, troubleshooting etc., These generated logs might be written to a disk, raised as an alert mail, pushed to a third party storage service or simply written to a set of files based on the criticalness of the generated log data and/or based on the volume of data that is generated. When not handled properly, even logs could be manipulated in the web application. Let’s say you have an endpoint like below,

17. https://www.testsite.com/logDOSAttemptByUser?userName=user1
    
    

18. This API will log the user names of users who are trying a DOS Attack in your site. And in the backend, you have something like,

19. List suspiciousAccountsLogged = new ArrayList();
    suspiciousAccountsLogged = parseUserNamesFromLogs();
    if(suspiciousAccountsLogged.size > 0)
    {
      for(String userName : suspiciousAccountsLogged)
       {
          doBlockUserForDOSAttempt(userName);
       }
    }
    
    

20. The idea is to block users who are trying to perform a DOS Attack on your site. You may find this based on the number of requests your servers have received from the particular user in a unit of time. Like above, there may be an automated way to process logs after sometime and flush data. Since the endpoint
21. /logDOSAttemptByUser
22. might be visible to the external world, it has the possibility of getting exploited. An attacker could modify the userName parameter of the request like below,

23. https://www.testsite.com/logDOSAttemptByUser?userName=user2
    
    

24. and the system could block an credible user
25. (user2)
26. who haven’t tried any DOS Attempt on your site, but since the logs have been injected, the system will block the user. Even if the logs are processed manually, it will be very cumbersome to differentiate valid logs from the injected ones and may be impossible at some cases. Log details being untrustworthy will result in serious problems. It is also possible to confuse the administrator with modified log messages like below.,

27. https://www.testsite.com/logUsageLimitReached?msg=UsageReached
    
    

28. This could be modified as,

29. https://www.testsite.com/logUsageLimitReached?msg=UsageReached+"\n INFO : Looks like problem with our calculation"
    
    

30. and logs would be generated as,

31. INFO : UsageReached
    INFO : Looks like problem with our calculation.
    
    

32. Solutions
33. • Instead of directly passing messages via parameters, log codes could be passed. However it is still exploitable.
    • 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.