Codecov Takeaways — Lo que sabemos hasta ahora

No es que nadie necesitara recordárselo tan pronto, pero la violación recientemente anunciada del conjunto de herramientas de Codecov, que soporta procesos de Integración Continua (CI) en muchas organizaciones, vuelve a resaltar la gran densidad de interdependencias que existen hoy en día y la exposición resultante a los ataques de la cadena de suministro.

Además, la fe a menudo implícita en el software proporcionado por proveedores de confianza significa que los clientes no prueban adecuadamente lo que está haciendo una actualización, tanto en términos de lo que está haciendo localmente en el host, sino también en términos de conectividad de red y transferencia de datos. Todo esto significa que, la mayoría de las veces, el software que se ejecuta en las organizaciones no se entiende completamente.

¿De qué manera esto es relevante para lo que pasó con Codecov?

Codecov proporciona capacidades de reporting que se pueden integrar en las canalizaciones de CI de los clientes; específicamente, sus herramientas informan sobre la cantidad de código que se ejecuta como parte de las pruebas, lo que ayuda a identificar brechas en el proceso de validación. Luego, estas métricas se cargan en su plataforma SaaS para informes y análisis.

La carga de datos es facilitada por scripts conocidos colectivamente como “Bash Uploaders”, que se ejecutan como parte del proceso de CI. Estos scripts de Uploader, en caso de ser manipulados, brindan una oportunidad para que un atacante no solo redirija la carga a un servidor de su elección, sino también para especificar qué datos quiere que se incluyan, haciendo que cualquier cosa disponible para el proceso de CI sea potencialmente accesible.

En el caso de Codecov, el compromiso inicial fue a través de una filtración de credenciales de Google Cloud Storage puestas a disposición a través de un error en el proceso de creación de imágenes de Docker de Codecov. Estas credenciales permitieron al atacante publicar una versión modificada del script de Bash Uploader, que alteraron para permitirle cosechar los contenidos de todas las variables de entorno disponibles para el proceso de CI en el que se ejecutaba y cargarlas en su propio servidor.

Dado que este script modificado estaba disponible directamente desde el sitio de Codecov, presumiblemente fue confiado por los clientes y descargado e integrado con poca validación. Las variables de entorno en el proceso de CI generalmente se utilizan para insertar secretos relevantes en el código para acceder a los recursos que necesita en tiempo de ejecución. El script malicioso de Uploader tendría así acceso a estos y podría transferirlos al atacante, proporcionándoles una cosecha saludable de credenciales y otra información sensible.

Incluso sin un mayor acceso persistente a la red, y aún no hay indicios de si la violación establece esto, estos secretos son un tesoro, dado que proporcionan acceso a una serie de recursos accesibles por Internet, como cubos de almacenamiento de información, bases de datos y otros servicios en la nube que utilizaron las aplicaciones asociadas. Éstos también están ahora probablemente comprometidos.

Como mínimo, cualquier organización que crea que puede haber incorporado los scripts de Bash Uploader comprometidos en su canalización de CI debería, con urgencia, ir y restablecer todos los secretos a los que esto tiene acceso. Esto requerirá casi definitivamente una redistribución de las aplicaciones afectadas para garantizar que tengan los secretos actualizados recibidos, pero se prefiere la sobrecarga de este método a prolongar la exposición de credenciales robadas.

Más allá de la exfiltración de secretos, el persistente acceso privilegiado que se brinda a la tubería de CI está maduro para el abuso. Por definición, la responsabilidad del pipeline es generar nuevas compilaciones de software y publicarlas en repositorios. El compromiso de la infraestructura de canalización en sí brinda al atacante la capacidad de alterar el contenido, insertando potencialmente puertas traseras para su uso posterior, ya sea en sistemas posteriores o dentro de artefactos generados. Entonces, ¿cuánta reconstrucción se necesita hacer para tener la confianza de que se eliminen todos los rastros del atacante y sus tentáculos?

A continuación, vale la pena observar el acceso a la red disponible para la infraestructura de CI. Por lo general, estos tienen acceso directo a otros componentes clave, incluidos, entre otros, el sistema de control de versiones, la infraestructura de monitoreo, las pruebas automatizadas, el proceso de compilación, la administración de la configuración y la implementación continua. Además, con el uso intensivo de componentes FOSS, la canalización de CI a menudo necesitará acceso a Internet a repositorios públicos para extraer las dependencias relevantes.

Con los densos requerimientos de conectividad que exige la canalización de CI, ¿puede la segmentación seguir sirviendo como un valioso control de seguridad?

Al considerar el valor de microsegmentación, se puede presentar de dos maneras:

1. La microsegmentación permite cercar activos de alto valor, asegurando que su exposición hacia y desde el resto de la red sea limitada, lo que dificulta que un atacante los alcance y explote.
2. La microsegmentación permite que cada carga de trabajo tenga su propio microperímetro basado en reglas de acceso con menos privilegios que la rodea. Esto asegura que, si se ve comprometido, superficie de ataque expuesto a él se limita solo a aquello a lo que está autorizado a conectarse, lo que en última instancia limita lo que un atacante podría hacer a continuación.

Un enfoque para hacer que esto sea relevante para la canalización de CI se ve así:

• La canalización de CI es definitivamente un activo de alto valor y uno que debe ser vallado por anillo.
• Si bien puede tener una serie de dependencias internas y externas desde una perspectiva de conectividad, éstas deben ser bien entendidas y bien definidas.
• Usando esta información, un lista de permitidospodría construirse una política de microsegmentación basada en base a fin de garantizar que la canalización de CI sólo tenga acceso a y desde estas dependencias bien entendidas.
• Si se requiere acceso a Internet, entonces se debe permitir solo para una lista de repositorios aprobados y no acceso a Internet sin restricciones. Esto limita el acceso a sólo una lista explícitamente definida de sitios de destino y es un control eficaz y a menudo simple para mitigar los intentos de C&C y de exfiltración de datos.

Esto protege a la canalización de CI de ser accedida por dispositivos no autorizados o a través de puertos y protocolos no autorizados. También asegura que, en el caso de compromiso de la canalización de CI, la exposición al resto de la red sea limitada. Por otra parte, se mejoró segmentación los controles a menudo van de la mano con una visibilidad significativamente mejor de las interacciones del sistema, proporcionando datos más ricos para que los equipos de detección y respuesta de incidentes trabajen al investigar posibles brechas.

En Illumio, ayudamos a los clientes a aprovechar microsegmentación para establecer esta contención y monitoreo. Puedes comunicarte con tu equipo de cuentas para saber cómo podemos apoyarte.