Carriage Return (\r) Line Feed (\n) is commonly known to note the end of a line. But, based on different platforms and HTTP protocols these are used. So, how does this affect the application? When services tend to respond to the command. These are denoted as commands in operating platforms. They will act the moment the command is submitted. We can’t complain to them like it’s the platform’s fault. It’s our responsibility to ensure that we don’t pass those characters (ASCII 13, \r and ASCII 10, \n) in the requests from clients.
How can this be used in an attack?
An attacker can submit a CRLF injection by modifying the HTTP parameter or URL parameter. As said above, if this is submitted successfully to the server. Then various attacks based on this injection can be performed.
HTTP Response splitting
HTTP Response splitting is an attack exploited by submitting a request to the webserver along with modified data. If the request is submitted like a usual request, it will fail. The web server can’t understand it. But, to make the server understand attacker will modify and add the malicious data by injecting CRLF. Now, the server will respond to the client with data in the HTTP response header. Based, on the header value web browser will carry the instructions. With this attack, various other attacks can be carried on like cross-site scripting, header injections which poise cache, poisoning client browsers.
CAPEC-34: HTTP Response Splitting
Logs are used for various needs in an application. There are many log types some known are debug logs, access logs, error-based logs, user logs, systems logs. In fact, today’s data world revolves around quality logs. We can see websites requesting to access cookies for better information. Likewise, many application stores log to give users the best experience. Now, we know the uses of logs.
What if the quality of log is not up to standard? What happens when there is an inconsistent log? How can SOC analysts or Threat hunters can work on an attack with inadequate logs?
Log injection is a weakness/vulnerability in an application when data that is untrusted and input without validation is printed on the log file.
Why someone would do that? What’s the gain for them with that?
We need to raise these questions to know the real fact in playing with log systems files.
The attacker will call an attack successful when the tracks are covered. Yes, modifying and corrupting the original log with a duplicate one leave no trace to track the attacker. Even alerting system will fail when there is no exact limit reached to alert the user/admin on the number of unsuccessful attempts until the attacker figures out the way to get in.
Worst case if the logs file is rendered in the browser, it can lead to XSS and other injection type attacks based on attackers’ malicious data in it.
CAPEC-93: Log Injection-Tampering-Forging
- Never trust client supplied data and process them.
- If the data is to be sent as part of response, sanitize the output and send.
- If the data is to be logged, remove the CRLF before logging.
- Disable unused headers in the web servers.
- Patch the system up to date. As most of the systems are fixed for these vulnerabilities.
- Create SIEM use cases to alert when these are found as part of submitted request to monitor and respond.