Programadores que conquistan la seguridad: Serie de aprendizaje y difusión - Inyección CRLF

En blogs o artículos como este, los signos de puntuación ayudan a los lectores. Por ejemplo, los puntos indican dónde termina una oración, mientras que las comas separan elementos en listas o insertan pausas marcadas para ayudar a distinguir ideas. En un blog bien escrito (como este), la puntuación es casi invisible, simplemente parte del código de fondo estándar que todos aprendimos a procesar hace muchos años.

¿Pero qué sucede si un hacker entra en este artículo e inserta signos de puntuación extraños en los lugares equivocados? Como esto:

Sin,incluso! cambiar. el, texto. ¿puede? hacer. ¡que! sea? mucho. ¿más! difícil. ¿procesar! la, información!

Eso es básicamente lo que ocurre con un ataque de inyección CRLF. Las letras CRLF significan Retorno de Carro (Carriage Return) y Salto de Línea (Line Feed), que se utilizan individualmente o juntos para indicar el final de una línea. Si un atacante logra insertar un código CR o LF en una aplicación existente, a veces puede alterar su comportamiento. Los efectos son menos predecibles que en la mayoría de los ataques, pero pueden ser igual de peligrosos para la organización objetivo.

En este episodio aprenderemos:

• Cómo los atacantes pueden activar una inyección CRLF
• Por qué las inyecciones CRLF son peligrosas
• Técnicas para solucionar esta vulnerabilidad.

¿Cómo activan los atacantes una inyección CRLF?

Inyectar caracteres CRLF en código existente para producir un resultado específico es bastante difícil, aunque no imposible. Se complica porque el atacante necesitaría usar diferentes combinaciones de CRLF dependiendo del sistema operativo y otros factores del sistema objetivo. Por ejemplo, las máquinas Windows modernas requieren tanto un CR como un LF para terminar una línea, mientras que en Linux solo se necesita el código LF. Las solicitudes HTTP siempre requieren un código CRLF preciso para terminar una línea.

Pero más allá de que los ataques CRLF sean difíciles de implementar y sus resultados aún más difíciles de predecir, se inician de manera muy similar a otros ataques de inyección. Un usuario malintencionado simplemente ingresa datos en cualquier área de un sitio web o aplicación que lo permita, solo que introduce el código CRLF en lugar de, o después de, los datos de entrada normales.

Por ejemplo, un atacante podría ingresar el código ASCII que representa un retorno de carro (%0d) seguido del ASCII para un salto de línea (%0a) al final de un encabezado HTTPS. La consulta completa se vería así:

https://validsite.com/index.php?page=home%0d%0a

Si los datos no se desinfectan o filtran, el código anterior podría permitir que ocurran cosas extrañas en la aplicación o sitio web objetivo.

¿Por qué son peligrosas las inyecciones CRLF?

Aunque los ataques de inyección CRLF son menos precisos que la mayoría, pueden ser bastante peligrosos al menos en algunas ocasiones. En el nivel más básico, añadir una línea adicional puede desordenar los archivos de registro, lo que podría activar defensas automáticas de ciberseguridad para alertar a los administradores sobre un problema inexistente. Sin embargo, esto podría utilizarse para desviar recursos de una incursión real que esté ocurriendo al mismo tiempo.

Pero los ataques CRLF también pueden ser directamente dañinos. Por ejemplo, si una aplicación está diseñada para aceptar comandos y luego buscar un archivo específico, añadir un código CRLF a la consulta podría hacer que la aplicación muestre ese proceso en pantalla en lugar de mantenerlo oculto, lo que podría proporcionar información valiosa para un atacante.

Las inyecciones CRLF también pueden utilizarse para crear lo que se llama un ataque de división de respuesta (response splitting), donde los códigos de fin de línea fragmentan una respuesta válida en varias partes. Esto puede dar a los hackers control sobre el encabezado después del código CRLF, lo que puede usarse para inyectar código adicional. También puede servir para crear una apertura donde el atacante pueda inyectar completamente su propio código y, probablemente, activar otra forma de ataque en cualquier línea que siga a la parte fragmentada por el ataque CRLF.

Eliminar la vulnerabilidad de inyección CRLF

Si hay un mensaje clave que extraer de esta serie, es que nunca, bajo ninguna circunstancia, se debe confiar en la entrada del usuario. La mayoría de las vulnerabilidades que hemos cubierto en esta serie han involucrado áreas de entrada de usuario de una forma u otra, y el fallo de inyección CRLF no es una excepción.

En cualquier punto donde un usuario pueda ingresar datos, se deben aplicar filtros para evitar la inyección de código no autorizado que pueda ser malinterpretado por la aplicación o el servidor. Para los ataques CRLF, asegurar los encabezados HTTP es especialmente importante, pero tampoco se deben olvidar los parámetros GET y POST o incluso las cookies. Una excelente manera de evitar específicamente que los códigos CRLF ayuden a activar más inyecciones es aplicar codificación HTML a todo lo que se envíe de vuelta al navegador del usuario.

Más información sobre las inyecciones CRLF

Para profundizar, puedes consultar lo que dice OWASP sobre las inyecciones CRLF. También puedes poner a prueba tus nuevos conocimientos defensivos con la demo gratuita de la plataforma Secure Code Warrior, que entrena a equipos de ciberseguridad para convertirse en expertos. Para aprender más sobre cómo vencer esta vulnerabilidad y otras amenazas, visita el blog de Secure Code Warrior.