Los codificadores conquistan la seguridad: serie Share & Learn - CRLF Injection

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

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

¡Sin, incluso! cambiando. el, texto. eso? ¡puedo hacerlo! ¿mucho? más difícil. ¿también? ¡proceso! ¡la, información!

Eso es básicamente lo que ocurre con un ataque de inyección de CRLF. Las letras CRLF significan Carriage Return y Line Feed, que se utilizan de forma individual o conjunta para indicar el final de una línea. Si un atacante puede insertar un código CR o LF en una aplicación existente, en ocasiones puede cambiar su comportamiento. Los efectos son menos fáciles de predecir en comparación con la mayoría de los ataques, pero no pueden ser menos peligrosos para la organización objetivo.

En este episodio aprenderemos:

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

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

Inyectar caracteres CRLF en el código existente e intentar producir un resultado específico es bastante difícil, aunque no imposible. Esto resulta aún más difícil porque un atacante tendría que utilizar diferentes combinaciones de CRLF en función del sistema operativo y de 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 finalizar una línea.

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

Por ejemplo, un atacante podría introducir el código ASCII que representa la devolución de un carro (%0d) seguido de ASCII para una alimentación de línea (%0a) al final de un encabezado HTTPS. En ese caso, toda la consulta tendría el siguiente aspecto:

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

Si los datos no se limpian o filtran, el código anterior puede permitir que ocurran cosas extrañas en la aplicación o el sitio web de destino.

¿Por qué son peligrosas las inyecciones de CRLF?

Si bien los ataques con inyección de CRLF son menos precisos que la mayoría, pueden ser bastante peligrosos al menos una parte del tiempo. En el extremo inferior, añadir una línea adicional puede estropear los archivos de registro, lo que podría activar defensas automáticas de ciberseguridad para alertar a los administradores si no hay ningún problema. Sin embargo, esto podría usarse para desviar recursos de una incursión real que se produzca al mismo tiempo.

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

Las inyecciones de CRLF también se pueden usar para crear lo que se denomina un ataque de división de respuestas, en el que los códigos de final de línea dividen una respuesta válida en varias partes. Esto permite a los piratas informáticos controlar el encabezado que sigue al código CRLF, que puede usarse para inyectar código adicional. También se puede usar para crear una apertura en la que el atacante pueda inyectar completamente su propio código y, probablemente, desencadenar otro tipo de ataque, en cualquier línea que siga a la parte interrumpida por el ataque del CRLF.

Eliminación de la vulnerabilidad de inyección de CRLF

Si hay un mensaje clave que sacar de esta serie, es que nunca, nunca hay que confiar en las opiniones de los usuarios. La mayoría de las vulnerabilidades que hemos tratado en esta serie tienen que ver con las áreas de entrada de los usuarios de una forma u otra, y la falla de inyección del CRLF no es una excepción.

En cualquier punto en el que un usuario pueda introducir datos, se deben aplicar filtros para evitar la inyección de código no autorizado que la aplicación o el servidor puedan malinterpretar. En el caso de los ataques con CRLF, es especialmente importante bloquear los encabezados HTTP, pero tampoco hay que olvidar los parámetros GET y POST ni siquiera las cookies. Una forma excelente de impedir específicamente que los códigos CRLF ayuden a activar nuevas inyecciones es aplicar la codificación HTML a todo lo que se devuelva al navegador del usuario.

Más información sobre las inyecciones de CRLF

Para leer más, puede echar un vistazo a lo que dice OWASP sobre Inyecciones de CRLF. También puedes poner a prueba tus nuevos conocimientos defensivos con el demo gratuita de la plataforma Secure Code Warrior, que forma a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para obtener más información sobre cómo derrotar esta vulnerabilidad y la galería de otras amenazas de los delincuentes, visita la Blog de Secure Code Warrior.