Serie de Infraestructura como Código de Coders Conquer Security: Uso de componentes de fuentes no confiables

Estamos llegando al final de nuestra serie sobre Infraestructura como Código (IaC), y ha sido un placer ayudar a desarrolladores como tú en su camino hacia la seguridad en IaC.

¿Has estado participando en los desafíos? ¿Cuál es tu puntuación hasta ahora? Antes de empezar, veamos cuánto sabes ya sobre los riesgos de utilizar componentes de fuentes no confiables:

¿Aún te falta un poco? Sigue leyendo:

El comportamiento que genera vulnerabilidades en el que nos centraremos hoy es el uso de código de fuentes no confiables, una práctica aparentemente inofensiva que está causando grandes problemas. El uso de código y recursos de código abierto tiene muchas ventajas. Por lo general, permite que los expertos contribuyan con sus ideas, trabajo e incluso código terminado a repositorios como GitHub para que otros, que tienen dificultades para lograr que un programa o aplicación funcione correctamente, puedan utilizarlos. Usar código terminado para gestionar funciones de programas evita que los desarrolladores tengan que reinventar la rueda cada vez que necesitan crear una nueva aplicación.

Sin embargo, utilizar fragmentos de código de fuentes poco fiables, no verificadas o incluso potencialmente peligrosas conlleva muchos riesgos. De hecho, el uso de código de fuentes no confiables es una de las formas más comunes en que las vulnerabilidades de seguridad, tanto importantes como menores, se infiltran en aplicaciones que, de otro modo, serían seguras. A veces, esas vulnerabilidades son inducidas accidentalmente por sus creadores. También ha habido casos en los que atacantes potenciales han escrito código malicioso. Luego, el código se comparte con la esperanza de atrapar a víctimas que lo incluirán en sus aplicaciones.

¿Por qué es peligroso utilizar código de fuentes no confiables?

Supongamos que un desarrollador tiene prisa y necesita configurar una aplicación que está creando. Ese puede ser un proceso complicado. Así que, en lugar de dedicar mucho tiempo a intentar resolver todas las configuraciones posibles, hace una búsqueda en Google y encuentra a alguien que ya ha completado un archivo de configuración aparentemente perfecto. Aunque el desarrollador no sabe nada sobre la persona que escribió el código, añadirlo a una nueva aplicación es relativamente fácil. Se puede hacer en el entorno Docker con dos líneas:

RUN cd /etc/apache2/sites-available/ && \
   wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
   9d372cfa8855a6be74bcca86efadfbbf/raw/\
   fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf

Ahora, la imagen de Docker extraerá dinámicamente el archivo de configuración de terceros. E incluso si el archivo se prueba y se considera correcto en ese momento, el hecho de que el puntero esté ahora incrustado en el código de la nueva aplicación significa que existe una dependencia permanente. Días, semanas o meses después, el archivo podría ser alterado por el autor original o por un atacante que haya comprometido el repositorio de código. De repente, el archivo de configuración compartido puede indicar a la aplicación que se comporte de forma muy distinta a la prevista, lo que podría dar acceso a usuarios no autorizados o incluso robar datos directamente y exfiltrarlos.

Una mejor manera de utilizar recursos compartidos

Si tu organización permite el uso de código de fuentes externas, se deben establecer procesos para garantizar que se haga de forma segura. Al evaluar código externo para su posible uso, asegúrate de adquirir componentes únicamente de fuentes oficiales utilizando enlaces seguros. E incluso entonces, nunca deberías enlazar a una fuente externa para extraer ese código, ya que eso elimina el proceso de tu control. En su lugar, el código aprobado debe llevarse a una biblioteca segura y utilizarse únicamente desde esa ubicación protegida. Por lo tanto, en un entorno Docker, el código se vería así:

COPY src/config/default-ssl.conf /etc/apache2/sites-available/

En lugar de depender de archivos de configuración remotos de terceros, esto dependería de una copia local de dichos archivos. Esto evitará que se realicen cambios inesperados o maliciosos.

Además de utilizar una biblioteca de código segura, se debe implementar un proceso de gestión de parches para supervisar continuamente los componentes a lo largo del ciclo de vida del software. Todos los componentes del lado del cliente y del servidor también deben comprobarse en busca de alertas de seguridad utilizando herramientas como NVD o CVE. Por último, elimina cualquier dependencia o función innecesaria o no utilizada que pueda venir incluida con el código externo.

Al seguir estos pasos, los desarrolladores pueden hacer un uso más seguro de los recursos externos sin introducir accidentalmente vulnerabilidades en sus aplicaciones y código.

Consulta las páginas del blog de Secure Code Warrior para obtener más información sobre esta vulnerabilidad y cómo proteger a tu organización y a tus clientes de los estragos de otros fallos de seguridad. También puedes probar una demostración de los desafíos de IaC en la plataforma de formación de Secure Code Warrior para mantener todas tus habilidades de ciberseguridad perfeccionadas y actualizadas.