Conclusiones de Codecov: 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 admite procesos de integración continua (CI) en muchas organizaciones, destaca nuevamente la gran densidad de interdependencias que existen hoy en día y la exposición resultante a los ataques a la cadena de suministro.

Además, la fe a menudo implícita en el software proporcionado por proveedores confiables 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 como 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 comprende completamente.

¿Qué relevancia tiene esto para lo que sucedió con Codecov?

Codecov proporciona capacidades de generación de reportes 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. Estas métricas se cargan en su plataforma SaaS para la elaboración de reportes y análisis.

La carga de datos se facilita mediante scripts conocidos colectivamente como "Bash Uploaders", que se ejecutan como parte del proceso de CI. Estos scripts de carga, en caso de que sean manipulados, brindan una oportunidad para que un atacante no solo redirija la carga a un servidor de su elección, sino que también especifique qué datos desea 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 las credenciales de Google Cloud Storage disponibles a través de un error en el proceso de creación de imágenes docker de Codecov. Estas credenciales permitieron al atacante publicar una versión modificada del script Bash Uploader, que alteraron para permitirles recopilar el contenido de todas las variables de entorno disponibles para el proceso de CI en el que se ejecutó y cargarlas en su propio servidor.

Dado que este script modificado estaba disponible directamente desde el sitio de Codecov, presumiblemente los clientes confiaban en él y se descargaba e integraba con poca validación. Las variables de entorno en el proceso de CI se usan normalmente para insertar secretos relevantes en el código para acceder a los recursos que necesita en tiempo de ejecución. El script malicioso Uploader tendría acceso a estos y podría transferirlos al atacante, proporcionándole una cosecha saludable de credenciales y otra información confidencial.

Incluso sin más acceso persistente a la red, y aún no hay indicios de si la violación lo establece, estos secretos son un cofre del tesoro, dado que brindan acceso a un serial de recursos accesibles a Internet, como depósitos de almacenamiento, bases de datos y otros servicios en la nube que emplearon las aplicaciones asociadas. Es probable que estos también estén ahora comprometidos.

Como mínimo, cualquier organización que crea que puede incorporar los scripts comprometidos de Bash Uploader en su canal de CI debería, con carácter de urgencia, restablecer todos los secretos a los que tiene acceso. Esto requerirá casi definitivamente una nueva implementación de las aplicaciones afectadas para cerciorar de que tienen los secretos actualizados recibidos, pero se prefiere la sobrecarga de este método a la prolongación de la exposición de las credenciales robadas.

Más allá de la exfiltración de secretos, el persistente acceso privilegiado otorgado a la tubería de CI está listo para el abuso. Por definición, la responsabilidad de la canalización es generar nuevas compilaciones de software y publicarlas en repositorios. El compromiso de la infraestructura de la canalización en sí le brinda al atacante la capacidad de alterar el contenido, potencialmente insertando 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 estar seguro de que se eliminan todos los rastros del atacante y sus tentáculos?

A continuación, ok la pena observar el acceso a la red disponible para la infraestructura de CI. Por lo general, estos tienen atajo 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 configuración y la implementación continua. Además, con el uso intensivo de componentes de software libre, la canalización de CI a menudo necesitará acceso a Internet a repositorios públicos para extraer dependencias relevantes.

Con los densos requisitos 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 formas:

1. La microsegmentación permite proteger los activos de alto valor, lo que garantiza que su exposición hacia y desde el resto de la red sea limitada, lo que dificulta que un atacante los alcance y los explote.
2. La microsegmentación permite que cada carga de trabajo tenga su propio microperímetro basado en reglas de acceso de privilegios mínimos que la rodea. Esto garantiza que, si se ve comprometida, la superficie de ataque expuesta a ella se limite solo 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 tubería de CI es definitivamente un activo de alto valor y uno que debe estar protegido.
• Si bien puede tener un serial de dependencias internas y externas desde una perspectiva de conectividad, estas deben entender bien y definir bien.
• Con esta información, se podría crear una directiva de microsegmentación basada en listas de permitidospara garantizar que la canalización de CI solo tenga acceso a y desde estas dependencias bien entendidas.
• Si se requiere acceso a Internet, entonces debería permitir solo para una lista de repositorios aprobados y no para un acceso a Internet sin restricciones. Esto limita el acceso solo a una lista explícitamente definida de sitios de destino y es un control efectivo y, a menudo, simple para mitigar los intentos de C&C y exfiltración de datos.

Esto protege la canalización de CI para que no se acceda a través de dispositivos no autorizados o a través de puertos y protocolos no autorizados. También garantiza que, en caso de compromiso de la canalización de CI, la exposición al resto de la red sea limitada. Además, los controles de segmentación mejorados 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 con ellos al investigar posibles infracciones.

En Illumio, ayudamos a los clientes a aprovechar la microsegmentación para establecer esta contención y monitoreo. Comunicar con su equipo de cuentas para averiguar cómo podemos ayudarlo.