<summary><strong>Aprende a hackear en AWS de cero a héroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si quieres ver a tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF**, consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de github de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
Si estás interesado en una **carrera de hacking** y hackear lo inhackeable - **¡estamos contratando!** (_se requiere polaco fluido escrito y hablado_).
Cuando un navegador envía una solicitud a un servidor web, el servidor 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 salto 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 termina otro. El CRLF también puede indicarle a una aplicación web o a un usuario que una nueva línea comienza en un archivo o en un bloque de texto. Los caracteres CRLF son un mensaje estándar HTTP/1.1, por lo que es utilizado por cualquier tipo de servidor web, incluyendo Apache, Microsoft IIS y todos los demás.\
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, la aplicación web o al usuario haciéndoles creer que un objeto ha terminado y otro ha comenzado. Como tales, las secuencias de CRLF no son caracteres maliciosos, sin embargo, pueden ser utilizados con intenciones maliciosas, para la división de respuestas HTTP, etc.
En 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 de aplicación web de impacto directo. De hecho, un ataque de inyección de CRLF puede tener repercusiones muy serias en una aplicación web, aunque nunca haya sido listado en el Top 10 de OWASP. Por ejemplo, también es posible manipular archivos de registro en un panel de administración como se explica en el siguiente ejemplo.
Si un atacante puede inyectar los caracteres CRLF en la solicitud HTTP, puede cambiar el flujo de salida y falsificar las entradas del registro. Puede cambiar la respuesta de la aplicación web a algo como lo siguiente:
Los %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 muestre:
Por lo tanto, al explotar una vulnerabilidad de inyección CRLF, el atacante puede falsificar entradas en el archivo de registro para ofuscar sus propias acciones maliciosas. El atacante está literalmente realizando secuestro de página y modificando la respuesta. Por ejemplo, imagina un escenario donde el atacante tiene la contraseña de administrador y ejecutó 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, dado que 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 parámetro. Después de eso hay otro & con el parámetro restricted action que será interpretado por el servidor como otro parámetro. Efectivamente, esta sería la misma consulta que:
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 le indicará al navegador que el encabezado termina y el cuerpo comienza. Eso significa que ahora es capaz de 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.
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 indicarle al navegador que comienza el cuerpo de la solicitud. De esa manera, puede insertar datos como XSS payload, por ejemplo:
Al explotar una inyección CRLF, un atacante también puede insertar encabezados HTTP que podrían utilizarse para derrotar mecanismos de seguridad como el filtro XSS de un navegador o la política de mismo origen. Esto permite al atacante obtener información sensible como tokens CSRF. También puede configurar cookies que podrían ser explotadas al iniciar sesión de la víctima en la cuenta del atacante o al explotar vulnerabilidades de [cross-site scripting (XSS)](https://www.netsparker.com/blog/web-security/cross-site-scripting-xss/) que de otro modo no serían explotables.
Si un atacante puede inyectar los encabezados HTTP que activan CORS (Cross Origin Resource Sharing), puede usar javascript para acceder a recursos que de otro modo estarían protegidos por SOP (Same Origin Policy), que impide que sitios de diferentes orígenes accedan entre sí.
Abusando de la inyección CRLF puedes **crear una nueva solicitud HTTP e inyectarla**.\
Un buen ejemplo se puede realizar utilizando el gadget de deserialización `SoapClient` en PHP. Esta clase es **vulnerable a CRLF** dentro del parámetro `user_agent` permitiendo **insertar nuevos encabezados y contenido del cuerpo**. Sin embargo, incluso podrías ser capaz de abusar de esta vulnerabilidad para **inyectar una nueva solicitud HTTP:**
Entonces, **especifique una segunda solicitud**. Aquí tiene un **clásico** [**request smuggling**](http-request-smuggling/) con **encabezados/cuerpo extra** añadidos por el servidor después de la inyección.
Para más información sobre esta técnica y problemas potenciales [**consulte la fuente original**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
Si una plataforma está tomando **datos de una solicitud HTTP y usándolos sin desinfectar** para realizar **solicitudes** a un servidor de **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 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 la IP y los puertos de los atacantes a usuarios cuyo correo electrónico no conocía el atacante:
El impacto de las inyecciones CRLF varía e incluye todos los impactos del Cross-site Scripting hasta la divulgación de información. También puede desactivar ciertas restricciones de seguridad como los Filtros XSS y la Política del Mismo Origen en los navegadores de las víctimas, dejándolos susceptibles a ataques maliciosos.
La mejor técnica de prevención es no usar directamente la entrada de los usuarios 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 en aplicaciones web es actualizar su lenguaje de programación a una versión que no permita que se inyecten CR y LF dentro de funciones que establecen encabezados HTTP.
Si estás interesado en una **carrera en hacking** y hackear lo inhackeable - **¡estamos contratando!** (_se requiere polaco fluido escrito y hablado_).
<summary><strong>Aprende hacking en AWS de cero a héroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si quieres ver a tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** revisa los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de github de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
