Demostración en vídeo del post:
En el post anterior que puedes leer aquí. Se han explicado los primeros cinco puntos de la guía Top 10 CI/CD Security Risk en donde se describen las principales amenazas en los entornos de CI/CD y la importancia de conocer estos problemas cuando se implementa un modelo de trabajo basado en DevSecOps.
A continuación, se describen los 5 puntos restantes de la guía.
Es común encontrar ficheros del tipo IaC tales como ficheros Dockerfile, ficheros YAML para Kubernetes o pipelines para alguna plataforma de CI/CD. En ocasiones en dichos elementos se encuentran «secrets» que pueden suponer un riesgo para el entorno completo, tales como usuarios y contraseñas, tokens o claves privadas. Este punto de la guía se refiere precisamente a que la gestión de secretos debe realizarse en el sistema de CI/CD utilizado en lugar introducir estos valores en texto plano en ficheros de configuración. Un atacante con acceso a la plataforma de CI/CD o al SCM podrá acceder a estos valores sensibles si se introducen en ficheros de configuración como los mencionados anteriormente o directamente en el código fuente de la aplicación. Plataformas como Jenkins, Github Actions, Circle-CI entre muchas otras, cuentan con herramientas para la gestión de información sensible y evidentemente se recomienda su uso.
Este tipo de vulnerabilidad se refiere a configuraciones inseguras que se pueden presentar en cualquiera de las herramientas o componentes utilizados durante el ciclo de vida del desarrollo. Desde IDEs con configuraciones inseguras que permiten la subida de ficheros con información sensible en el SCM, software desactualizado, gestión insegura de permisos, hasta mecanismos inexistentes o insuficientes para el registro de eventos relacionados con la seguridad. Todos estos detalles se tienen en cuenta en éste punto de la guía y tienen el potencial de afectar severamente el entorno de CI/CD.
La superficie de ataque en los entornos de CI/CD no solamente se define por los SCM, plataformas de gestión y otros componentes que integran dicho entorno, en este punto también hay que considerar el uso de programas, librerías, frameworks, herramientas y plataformas de terceros que no se están gestionando correctamente. El problema en este punto radica en que con bastante frecuencia estos componentes tienen acceso a recursos sensibles del entorno, extendiendo la superficie de ataque y en ocasiones, sin que la organización sea plenamente consciente de ello. En este punto de la guía se hace hincapié en que este tipo de vulnerabilidades se pueden mitigar con una correcta gestión de cambios y políticas de seguridad que incluyan la revisión periódica de los activos que hacen parte del entorno.
Los procesos de CI/CD normalmente están compuestos por múltiples pasos y el objetivo en última instancia consiste en convertir el código que crean los desarrolladores en una aplicación plenamente funcional en un entorno de producción. En este proceso se llevan a cabo varias labores en las que se mezclan recursos y artefactos internos y externos, componentes que se obtienen de sitios remotos y todo tipo de interacciones con sistemas externos. El hecho de que la aplicación dependa de múltiples fuentes, las cuales la van «alimentando» en cada paso del proceso, también crea múltiples puntos a través de los cuales un atacante puede envenenar entradas y manipular el resultado final. Si un recurso del que depende la aplicación se puede alterar, manipular o cambiar por un atacante en alguno de los pasos, lo más probable es que continúe fluyendo por todo el proceso de CI/CD hasta llegar a producción sin que nadie sepa que esta situación se ha producido ya que en apariencia, se trata de un recurso legítimo.
La recomendación consiste en utilizar técnicas de validación de la integridad, como por ejemplo el uso de hashes y firmas digitales que permitan saber que los componentes de los que depende la aplicación son confiables y no han sufrido alteraciones.
Este punto guarda cierta similitud con el OWASP Top 10 y la categoría «Security Logging and Monitoring Failures» ya que habla de los problemas que se pueden producir por una falta de control sobre los sistemas de logs y seguimiento en los eventos producidos. Cuando no existen mecanismos de registro o no se presta atención a los eventos de seguridad, existe la posibilidad de que un atacante pueda llevar a cabo actividades maliciosas sin que sean detectadas por parte del equipo y esto es especialmente critico en un entorno de CI/CD dada la cantidad de componentes e integraciones con terceros que se suelen producir.
En este sentido, las recomendaciones generales coinciden con las medidas de seguridad clásicas cuando se pretende implementar medidas de seguridad perimetral y bastionado, entre las que se incluyen el mapeo completo del entorno, gestión de activos y riesgos, detectar y habilitar las fuentes de logs, centralizar todos los eventos producidos en un servidor de syslog o mejor aún en un SIEM.
Como se puede comprobar, la guía es muy completa e incluye aquellas amenazas que afectan a los entornos de CI/CD, sin duda es un recurso muy útil si se desea implementar el modelo de DevSecOps en el ciclo de vida del desarrollo de software.
Un saludo y Happy Hack!
Adastra.