Incidentes y vulnerabilidades
Filtración de Codecov (2021) — cuando una «herramienta de confianza» del CI fue secuestrada y se filtraron secretos
En 2021, el Bash Uploader de Codecov (un script curl|bash ejecutado en CI) fue alterado en origen y filtró durante ~2 meses los secretos del CI de sus clientes; una verificación de checksum lo detectó. La cadena como mapa de defensa, más las soluciones.
Leemos incidentes públicos reales no como repeticiones de noticias, sino a través de «cómo te defenderías de esto». Este artículo se basa en registros públicos (el post-mortem oficial, CISA, análisis de proveedores de seguridad), citados al final.
- Objetivo
- Codecov (herramienta de cobertura de código) y el CI de sus clientes
- Divulgado
- 15 de abril de 2021 (alteración desde el 31 de enero / detectado el 1 de abril)
- Clase
- Ataque a la cadena de suministro (alteración en origen de un artefacto de confianza) + robo de secretos del CI
- Escala
- muchos clientes de Codecov (hasta ~29.000). Impactos aguas abajo en HashiCorp, Twilio, Rapid7
- Causa raíz
- el CI ejecutó un artefacto descargado sin verificar + el manejo de claves del proveedor + secretos del CI sobreexpuestos
- Solución real
- verificar los artefactos descargados, secretos del CI de mínimo privilegio, rotación, monitorización de salida
Qué ocurrió (en lenguaje llano)
Muchos equipos descargan y ejecutan herramientas externas tal cual en su CI, como curl … | bash. El Bash Uploader de Codecov era uno de esos scripts.
El atacante explotó una debilidad en la distribución de Codecov para reescribir el propio script distribuido, de modo que, al ejecutarse en CI, enviaba las variables de ese entorno (secretos) a un servidor externo. Para un cliente, simplemente habían invocado la herramienta de confianza como siempre. Como no cambió ni una línea de tu código, casi no hay señal de que algo vaya mal.
Unos dos meses después, un cliente comparó el checksum (SHA256) del script con el valor oficial y encontró una discrepancia: ahí salió a la luz la alteración. La información que podía filtrarse incluía claves de la nube, claves de despliegue, claves de API y tokens, y desde ahí el ataque se encadenó con filtraciones aguas abajo en empresas como HashiCorp y Twilio.
Da miedo precisamente porque «tu código está intacto»
Los ataques a la cadena de suministro no apuntan al código que escribiste, sino a las cosas en las que confías e incorporas. Por eso la revisión de código y los registros rara vez los detectan. «Confiamos en ello» = «no lo verificamos» se convierte en el agujero.
La cadena también es un mapa de defensa
Lo que importa es que esto fue una cadena de cuatro saltos, y que cada salto tenía un punto donde detenerlo. Léela como «dónde se pudo haber cortado», no como una receta de ataque.
① Ejecutar una herramienta de confianza vía curl | bash (contenido sin verificar)
⊘ parada: fijar versión + verificar checksum del artefacto descargado / vendorizar
② El artefacto se intercambia «en origen»
Tu código está intacto, así que no puedes darte cuenta.
⊘ parada: comparar contra un hash conocido como bueno; usar una versión fijada
③ Las variables de entorno del CI (secretos, claves, tokens) salen hacia fuera
⊘ parada: secretos del CI de mínimo privilegio, por paso (no pasar todo el entorno)
④ Las claves robadas se encadenan a producción y a otros servicios
⊘ parada: rotación periódica de claves + monitorización de salida (tráfico saliente)
Cronología divulgada
2021-01-31
Comienza la alteración del Bash Uploader (de forma intermitente a partir de entonces).2021-03–
Durante semanas salen secretos del CI de los clientes, sin que nadie lo note.2021-04-01
Un cliente encuentra una discrepancia de checksum y la reporta.2021-04-15
Codecov lo divulga públicamente; aconseja a los clientes rotar todos los secretos.2021-04–
Surge el impacto aguas abajo en HashiCorp, Twilio, Rapid7. Codecov retira más tarde el Bash Uploader.
La causa raíz no es un solo error
Atribúyelo a «culpa de Codecov» y se repetirá. El lado del cliente también tenía capas cediendo.
Como estaba (en su momento)
- El CI ejecutaba un artefacto descargado sin verificar (confiando en
curl | bash) - Secretos del CI sobreexpuestos (cada paso ve cada variable de entorno)
- Los secretos rara vez se rotaban (las claves robadas siguen válidas mucho tiempo)
- El tráfico saliente del CI sin monitorizar
Como debería ser (prevención)
- Fijar versión + verificar checksum de los artefactos descargados, o vendorizarlos
- Pasar los secretos del CI con mínimo privilegio, solo a los pasos que los necesitan
- Rotar los secretos con regularidad (vida corta aunque se filtren)
- Monitorizar la salida del CI y detectar envíos a destinos desconocidos
La «confianza» viene emparejada con la verificación
Los ataques a la cadena de suministro apuntan a las cosas en las que confías e incorporas: librerías de dependencias, herramientas de CI, imágenes de compilación. El caso de XZ Utils tenía la misma forma. Minimiza la confianza y verifica la integridad de lo que incorporas, de forma automática.
Cómo prevenirlo en tu entorno
Soluciones ordenadas por prioridad que funcionan a cualquier escala. Inventaría una vez «qué confía y ejecuta tu CI» y se vuelve algo personal.
Verifica los artefactos descargados (no confíes ciegamente en curl|bash)
Si el CI descarga un script o binario externo, exige una versión fijada (tag/commit) + verificación de checksum (SHA256). Donde sea posible, vendorízalo en tu propio repositorio. Esta filtración se detectó exactamente con esta comprobación.
Limita los secretos del CI al mínimo privilegio
No pases cada variable de entorno a cada paso. Pasa solo el secreto necesario al job/paso necesario. Usa tokens de vida corta (p. ej., OIDC) para reducir las claves de larga vida en reposo.
Rota los secretos con regularidad
Si se roban, una vida corta limita el daño. Haz de la rotación una rutina y rota de inmediato cuando se reporte un incidente de cadena de suministro.
Monitoriza la salida del CI (tráfico saliente)
Sé capaz de detectar envíos a destinos desconocidos desde el CI. Aunque la entrada no se detenga, mantén una capa que advierta la exfiltración.
La postura de este sitio: minimiza la confianza, verifica
Este sitio diseña la incorporación de dependencias y de la compilación para que sea verificada por máquina. Lo que muestran Codecov y XZ Utils es lo mismo: «confiamos en ello» tiende a convertirse en «no lo verificamos», y esa es la puerta para los ataques a la cadena de suministro. Reduce la confianza y confirma mecánicamente la integridad de lo que incorporas.
Fuentes (registros públicos)
Los hechos aquí se basan en la siguiente información pública, centrada en las lecciones defensivas, no en pasos de reproducción ni en el código alterado.
- Codecov, "Post-Mortem / Root Cause Analysis (April 2021)" — about.codecov.io
- Codecov, "Bash Uploader Security Update" — about.codecov.io
- CISA, "Codecov Releases New Detections for Supply Chain Compromise" (2021) — cisa.gov
- Rapid7, "Analysis of the Codecov Supply Chain Compromise" (2021) — rapid7.com
Lee a continuación
FAQ
Q¿Cuál fue la causa raíz del incidente de Codecov?
No un fallo en tu código, sino una herramienta externa de confianza que ejecutas en CI (el Bash Uploader de Codecov) alterada en su origen (upstream). El CI descargaba el script vía curl y lo ejecutaba sin verificar su contenido, así que se ejecutó la versión alterada y las variables de entorno del CI (secretos) salieron hacia fuera.
Q¿Por qué pasó ~2 meses inadvertido?
Porque lo alterado era la herramienta de otra persona: tu propio repositorio y tu código quedaron intactos, y no hay una anomalía llamativa en los registros. Finalmente se detectó cuando un cliente comparó el checksum (SHA256) del script con el valor oficial y encontró una discrepancia.
Q¿Esto importa para proyectos pequeños?
Sí. Meter herramientas en el CI vía «curl … | bash» es común incluso en solitario, y si eso se secuestra, tus secretos del CI se llevan de un solo golpe. Las defensas de aquí (fijar versión + verificar checksum de los artefactos descargados, secretos del CI de mínimo privilegio, rotación periódica) funcionan a cualquier escala.