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
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:
File.txtrm -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.
PHP CRLF Injection Bug Lets Remote Users Execute Arbitrary FTP Commands
A remote user may be able to execute arbitrary FTP commands.
The PHP ftp function does not properly validate user-supplied input. A remote user can supply specially crafted input to inject a CR/LF character string and execute arbitrary FTP commands on the target FTP server.
A demonstration exploit URL is provided:
http://[target]/test.php?dir=loveshel l%0D%0AMKD jnc%0D%0ADELE jnc.txt%0D%0Armd test
Example of a CRLF Injection Attack
Many network protocols, including HTTP, make extensive use of the Carriage Return and Line Feed combination of commands since each line used in this protocol is separated by a CRLF. If a user is able to define an unfiltered HTTP header, it poses a risk since the user would then be able to communicate directly to the server, bypassing the application layer.
For example E-mail, News (NNTP) and HTTP headers are all based on the structure of "Key: Value" and each line is defined with a CRLF combination at the end. The "Location:" header is used in HTTP to redirect to another URL and a "Set-Cookie:" header is used for cookies. If these inputs are not properly validated, CR and LF characters can be embedded in the user input, and web scripts can be fooled to do other things than what they were originally constructed for.
If the input is not checked for CR and LF and the script constructs a redirect with the string:
Location: $url%0d%0a
We can redirect to a site while setting a cookie by setting $url (as one string) to:http://www.i-was-red...m/ Set-Cookie: Authenticated=yes%0d%0aReferer: www.somesite.com
If an attacker can save the URLs that another user will be redirected to, including cookies with important data, this can be serious.Preventing CRLF attacks
The best way to defend against CRLF attacks it to filter extensively any input that a user can give. One should "remove everything but the known good data" and filter meta characters from the user input. This will ensure that only what should be entered in the field will be submitted to the server.
Hi friends,
This is my first paper to security , and m fresher to this domain also, i learnt the top 2007 OWASP security vulnerables , not more words to say
Thanks for providing this opportunity , have a nice day ahead!!!!
