コーダーがセキュリティを征服：シェア＆ラーニングシリーズ-CRLF インジェクション

En los blogs o artículos como éste, los signos de puntuación ayudan a los lectores. Por ejemplo, los puntos indican a los lectores dónde termina una frase, mientras que las comas separan los artículos en listas o insertan pausas duras para ayudar a separar las ideas. En un blog bien escrito (como éste), los signos de puntuación son casi invisibles, sólo forman parte del código estándar de fondo que todos aprendimos a procesar hace muchos años.

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

Sin, siquiera, cambiar, el, texto, puede, hacer 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 son las siglas de Carriage Return (Retorno de carro) y Line Feed (Avance de línea), que se utilizan de forma individual o conjunta para señalar la terminación de una línea. Si un atacante puede insertar un código CR o LF en una aplicación existente, a veces 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 provocar una inyección CRLF
• Por qué son peligrosas las inyecciones de CRLF
• Técnicas que pueden solucionar esta vulnerabilidad.

¿Cómo se activa una inyección de CRLF por parte de los atacantes?

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

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

Por ejemplo, un atacante podría introducir el código ASCII que representa un retorno de carro (%0d) seguido de ASCII para un avance de línea (%0a) al final de una cabecera HTTPS. La consulta completa tendría entonces el siguiente aspecto:

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

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

¿Por qué son peligrosas las inyecciones de CRLF?

Aunque los ataques de inyección de CRLF son menos precisos que la mayoría, pueden ser bastante peligrosos al menos en algunas ocasiones. En el extremo inferior, la adición de una línea extra puede desordenar los archivos de registro, lo que podría activar las defensas automáticas de ciberseguridad para alertar a los administradores de un no problema. Sin embargo, esto podría utilizarse para desviar recursos de una incursión real que se produzca al mismo tiempo.

Pero los ataques CRLF también pueden ser directamente perjudiciales. 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 desencadenar 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 utilizar para crear lo que se denomina un ataque de división de la respuesta, en el que los códigos de final de línea rompen una respuesta válida en varias partes. Esto puede dar a los hackers el control de la cabecera después del código CRLF, que puede ser utilizado para inyectar código adicional. También se puede utilizar para crear una apertura donde el atacante puede inyectar completamente su propio código, y probablemente desencadenar otra forma de ataque, en cualquier línea que siga a la parte rota por el ataque CRLF.

Eliminación de la vulnerabilidad de inyección CRLF

Si hay un mensaje clave que hay que sacar de esta serie, es que nunca, nunca confíes en la entrada del usuario. La mayoría de las vulnerabilidades que hemos cubierto en esta serie han involucrado áreas de entrada del usuario de una manera u otra, y la falla de inyección CRLF no es una excepción.

En cualquier punto en el que un usuario pueda introducir datos, deben aplicarse 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, es especialmente importante bloquear las cabeceras HTTP, pero tampoco hay que olvidar los parámetros GET y POST o incluso las cookies. Una buena manera de impedir específicamente que los códigos CRLF ayuden a desencadenar más inyecciones es aplicar la codificación HTML a todo lo que se envía al navegador del usuario.

Más información sobre CRLF Injections

Para más información, puedes echar un vistazo a lo que dice la OWASP sobre las inyecciones CRLF. También puedes poner a prueba tus nuevos conocimientos defensivos con la demostración gratuita de la plataforma Secure Code Warrior , que forma a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para saber más sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .