Los programadores conquistan la infraestructura de seguridad como series de códigos, utilizando componentes de fuentes no confiables

Nos acercamos al final de nuestra serie Infrastructure as Code, pero ha sido fantástico ayudar a desarrolladores como tú en su viaje hacia la seguridad en iAC.

¿Has estado jugando a los desafíos? ¿Cuál es tu puntuación hasta ahora? Antes de empezar, veamos cuánto sabes sobre los inconvenientes de usar componentes de fuentes que no son de confianza:

¿Aún tienes trabajo por hacer? Sigue leyendo:

El comportamiento que induce a la vulnerabilidad en el que nos centraremos hoy es el uso de código de fuentes no confiables, una práctica aparentemente benigna que está causando grandes problemas. El uso de código y recursos de código abierto tiene muchas ventajas. En general, permite a los expertos aportar sus ideas, trabajos e incluso código terminado a repositorios como GitHub para que lo utilicen otras personas que tienen dificultades para hacer que un programa o una aplicación funcione correctamente. El uso de código completo para controlar las funciones del programa evita que los desarrolladores tengan que reinventar la rueda cada vez que necesitan crear una nueva aplicación.

Sin embargo, el uso de fragmentos de código de fuentes poco fiables, no investigadas o incluso potencialmente peligrosas conlleva un gran riesgo. De hecho, el uso de código de fuentes que no son de confianza es una de las formas más comunes en las que las vulnerabilidades de seguridad, tanto mayores como menores, se infiltran en aplicaciones que, por lo demás, serían seguras. En ocasiones, esas vulnerabilidades son inducidas accidentalmente por sus creadores. También ha habido casos en los que posibles atacantes escribieron código malicioso. Luego, el código se comparte con la esperanza de atrapar a las víctimas para que lo incluyan en sus aplicaciones.

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

Supongamos que un desarrollador tiene prisa y necesita configurar una aplicación que está desarrollando. Este puede ser un proceso complicado. Entonces, en lugar de perder mucho tiempo intentando resolver todas las configuraciones posibles, hacen una búsqueda en Google y encuentran 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 usando dos líneas:

EJECUTE 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 comprueba que está bien 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 autor original o un atacante podría modificar el archivo y poner en peligro el repositorio de código. De repente, el archivo de configuración compartido puede indicar a la aplicación que funcione de forma muy diferente a la prevista, lo que puede dar acceso a usuarios no autorizados o incluso robar datos directamente y filtrarlos.

Una forma mejor de usar los recursos compartidos

Si su organización permite el uso de código de fuentes externas, se deben implementar procesos para garantizar que se haga de manera segura. Al evaluar el código externo para su posible uso, asegúrese de adquirir componentes de fuentes oficiales únicamente mediante enlaces seguros. Y aun así, nunca debes vincular a una fuente externa para obtener ese código, ya que eso eliminaría el control del proceso. En su lugar, el código aprobado debe guardarse en una biblioteca segura y utilizarse únicamente desde esa ubicación protegida. Por lo tanto, en un entorno de Docker, el código tendría este aspecto:

COPIA 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 esos archivos. Esto evitará que se realicen cambios inesperados o malintencionados.

Además de usar una biblioteca de códigos segura, se debe implementar un proceso de administración de parches para monitorear continuamente los componentes durante todo el ciclo de vida del software. También se deben comprobar todos los componentes del lado del cliente y del servidor para detectar alertas de seguridad mediante herramientas como NVD o CVE. Por último, elimina todas las dependencias y funciones innecesarias o no utilizadas que puedan venir acompañadas del código externo.

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

Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de los desafíos de IaC en la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.