En un mundo DevOps donde la automatización reina dentro de las cadenas de integración continua (CI pipelines), están surgiendo nuevos riesgos cibernéticos que es fundamental abordar lo antes posible.
A medida que el mundo del desarrollo de computadoras continúa creando nuevos procesos para crear software, los delincuentes continúan desarrollando sus propias técnicas para explotar las fallas en estos procesos. DevOps es la última tendencia en desarrollo de software y se caracteriza por altos niveles de automatización. Cada vez más partes del proceso de desarrollo de software pueden tener lugar sin intervención humana, lo que acelera el desarrollo. Sin embargo, esto no está exento de inconvenientes.
Menos intervención humana significa menos monitoreo de principio a fin, y eso también significa más tecnología para explotar o potencialmente abusar. La mayoría de los riesgos están relacionados con el uso de información confidencial en la automatización, lo que permite robar secretos de muchas maneras. También debe preocuparse por cosas como la manipulación del código. Para garantizar la seguridad del código y los secretos asociados*, se deben agregar las siguientes prácticas de seguridad a la canalización de CI.
Niveles de flujos de trabajo
El ataque de Codecov demuestra el impacto que un solo flujo de trabajo puede tener en la seguridad de toda la infraestructura crítica. Los ataques a la cadena de suministro van en aumento, y el riesgo asociado con estos ataques es un tema completo en sí mismo.
En este momento, es más importante que nuncaprestar especial atención a los elementos a los que están expuestos el código y la infraestructura.
Es común usar flujos de trabajo de terceros en una canalización de CI, pero comprenda que esto significa confiar el código y los secretos potencialmente asociados a ese tercero. Si es posible, revise el código fuente de las imágenes y los flujos de trabajo que se están considerando en la canalización de CI. Si se realiza un seguimiento del flujo de trabajo mediante el control de versiones, también puede revisar periódicamente los cambios para asegurarse de que no se haya deslizado nada sospechoso.
Por razones de tiempo o disponibilidad del código fuente, esto no siempre es posible. Sin embargo, debe sopesar los pros y los contras de aceptar el riesgo de confiar ciegamente en un flujo de trabajo de terceros. Como mínimo, uno debe buscar flujos de trabajo que sean publicados por una parte confiable o populares y confiables para otros. Siempre habrá algún riesgo en confiar en un tercero, lo que reafirma la importancia de tomar medidas que limiten el daño que se puede hacer.
Control de acceso
Lo siguiente a considerar para asegurar la canalización de CI es el control de acceso. Con los sistemas de gestión de claves, es posible utilizar funciones como el control de acceso basado en roles para determinar quién puede usar qué secretos. Siga siempre el principio de privilegio mínimo para determinar quién debe tener acceso a los secretos. Es muy importante ajustar el acceso al nivel del sistema de gestión de claves; sin embargo, este no es el único punto de riesgo en el ciclo de vida de un secreto.
Considere el siguiente escenario: un desarrollador mantiene un repositorio de software gratuito muy popular en GitHub y recibe regularmente solicitudes de cambio. Para ahorrar tiempo en la evaluación del código enviado, ejecuta pruebas automáticas cuando alguien envía una nueva solicitud de extracción.
Si alguien alguna vez envió un código malicioso en una solicitud de extracción que tomó variables de entorno y las envió al servidor del autor. También agregó una prueba para asegurarse de que su código se ejecutaría al ejecutar la canalización de CI. Tan pronto como envía la solicitud de extracción, se inicia la canalización y se roban todas las variables de entorno de su entorno de CI…
El ejemplo anterior ni siquiera es el peor de los casos. Hay escenarios similares como el descrito por este blog. En este caso, el atacante pudo salir del entorno de prueba y robar información aún más valiosa.
Lo último que desea es que una parte que no sea de confianza pueda ejecutar código arbitrario en el entorno de compilación.. No basta con que los secretos estén protegidos por un sistema de gestión de claves. También debe asegurarse de que confía en el código que utilizará estos secretos. Especialmente para los mantenedores de software libre, para quienes no debe ejecutar ningún flujo de trabajo en las solicitudes de extracción antes de leer el código.
Hashing/firma de compilación
El hashing de compilación es más importante para la seguridad del usuario que la seguridad del código, pero llevar el concepto un paso más allá también puede ser beneficioso en algunos aspectos. Como ejemplo, veamos uno de los ciberataques más grandes de 2020: el ataque a la cadena de suministro de SolarWinds.
SolarWinds es un proveedor líder de herramientas de administración y monitoreo de redes que utilizan muchas organizaciones. Como parte de una campaña a largo plazo, un adversario infectó los servidores de compilación de SolarWinds con un malware personalizado llamado Sunspot. Sunspot es un malware muy avanzado que supervisa los procesos que se ejecutan en los servidores de desarrollo, buscando específicamente los procesos involucrados en la creación del producto Orion de SolarWinds.
Cuando Sunspot vio que Orion se estaba compilando en el servidor de compilación, inyectó un código adicional, más tarde llamado «Sunburst», en el software compilado. Sunburst era una puerta trasera que los atacantes usaban para obtener acceso a todas las organizaciones que usaban Orion.
Entonces, ¿qué debemos sacar de todo esto? Debido a que la compilación en sí estaba infectada, fue firmada por SolarWinds y en realidad era parte del producto que estaban lanzando. Para detectar un ataque de este tipo en el futuro, SolarWinds dijo que está investigando formas de validar compilaciones simultáneas entre sí. Esto podría ser un desafío dada la sensibilidad de los algoritmos hash, pero aún es algo que explorar para poder detectar inyecciones de compilación.
Protección de su entorno de construcción
El ataque a SolarWinds muestra claramente que el entorno de desarrollo no es solo una caja de arena para los desarrolladores, eses un ingrediente activo extremadamente sensible que hay que proteger. Es posible que Sunspot haya permanecido en los servidores de desarrollo de SolarWinds durante mucho tiempo, pero algunos IOC (indicadores de compromiso) podrían haber revelado la presencia de los atacantes.
Sin profundizar demasiado en el tema de la defensa de la computadora y la red, hay algunas mejores prácticas generales para proteger los servidores de compilación. En primer lugar, asegúrese de que se haya habilitado el registro adecuado en los servidores de compilación y que se envíen a un SIEM o agregador de registros. En segundo lugar, se debe considerar implementar un agente EDR en los servidores de compilación para obtener telemetría y alertas adicionales cuando sucede algo sospechoso. En tercer lugar, use herramientas de prevención y detección de redes y trate los servidores de desarrollo con cuidado.
Hay demasiadas capas potenciales para proteger las computadoras como para enumerarlas todas, así que nos detendremos ahí. Si no tiene mucha experiencia con la seguridad informática y la defensa de la red, hable con expertos que puedan brindarle asistencia o asesoramiento adicional.
Gestión de secretos
Es probable que los desarrolladores experimentados o los profesionales de la seguridad hayan oído hablar de filtraciones de claves API en repositorios de códigos públicos. Es posible que incluso hayan visto sus propios secretos filtrados antes después de pasarlos accidentalmente a un proyecto de código abierto. Según el tipo de secreto que se haya filtrado, el error puede resultar costoso. Como recordatorio, la «secretos », en el contexto del desarrollo de software, generalmente se refieren a sistemas de autenticación digital que brindan acceso a sistemas o datos. Suelen ser claves de API, nombres de usuario y contraseñas, o certificados de seguridad.
La mejor manera de proteger los secretos es practicar una buena gestión de secretos. Utilice herramientas de administración de secretos como Azure Key Vault o Amazon KWS que brindan almacenamiento seguro y acceso basado en la identidad. El uso del administrador de secretos incorporado de GitHub también funciona bien según el caso de uso, pero no tiene tantas funciones como un verdadero servicio de administración de claves.
Otra herramienta imprescindible para la gestión de secretos es una herramienta que pueda indicar de inmediato si un secreto se libera accidentalmente en la base de código. Saber cuándo los secretos se exponen accidentalmente es crucial, como lo ilustra el caso reciente de Codecov. La imagen de Docker de Codecov se modificó discretamente para filtrar los secretos de todos los que la usaron en su tubería de CI para realizar pruebas. Esto ha impactado a decenas de miles de sus clientes/usuarios.
Aunque es muy difícil prevenir un ataque como el de Codecov, su impacto en una organización puede ser limitado. Si es posible, use secretos en producción que sean diferentes de los que se usan en la canalización de CI. De esa manera, si algo como el flujo de trabajo comprometido de Codecov da acceso a las claves, no afectará el entorno de producción.
Desafortunadamente, los ciberatacantes están en constante evolución en sus técnicas, y protegerse contra nuevos ataques siempre será un desafío. La tubería de CI se encuentra entre los activos seleccionados más recientemente, y las oportunidades son abundantes debido a la falta de participación humana. Seguir todas estas prácticas de seguridad mejoraría en gran medida la seguridad de la canalización de CI, pero también se debe asegurarse de estar siempre al día con las nuevas tendencias en las técnicas de los atacantes.
___________________
Par CJ mayoDesarrollador y profesional de la seguridad apasionado y experto en GitGuardian
Lea también:
Seguridad de aplicaciones: el nuevo segmento de detección de secretos.
¿Cómo asegurar el acceso y el código del desarrollador?
Proteja las aplicaciones contra ataques modernos y complejos
DevOps: un cambio cultural para prepararse bien.
[
