Qué es un ataque a la cadena de suministro

Un ataque a la cadena de suministro es un método de ataque que, en lugar de atacar directamente a la organización objetivo, se infiltra a través de la red de suministro de software, bibliotecas, servicios o hardware en los que la organización confía y que utiliza. Como abusa de mecanismos de actualización legítimos y de las dependencias, tiene la incómoda propiedad de colarse por delante de las defensas perimetrales y de las medidas antimalware.

En el desarrollo de software de la década de 2020, una sola aplicación depende de cientos a miles de bibliotecas de código abierto. Un atacante solo necesita inyectar código malicioso en un punto de esta cadena de dependencias para afectar a todas las organizaciones que utilizan esa biblioteca. Cuando se combina con ataques de día cero, la detección se vuelve aún más difícil.

Patrones de ataque típicos

Los ataques a la cadena de suministro tienen varios patrones típicos.

Compromiso del sistema de compilación: Infiltrarse en la infraestructura de compilación y distribución del software para incrustar malware en binarios legítimos. En el incidente de SolarWinds, divulgado en diciembre de 2020, el pipeline de compilación fue comprometido y, según la propia comunicación de la empresa, hasta 18.000 organizaciones clientes descargaron la actualización manipulada.
Contaminación de dependencias: Publicar paquetes maliciosos en registros de paquetes como npm o PyPI. Se utilizan técnicas de typosquatting (nombres similares a los de paquetes legítimos) y de confusión de dependencias (Dependency Confusion).
Secuestro de mantenedores legítimos: Comprometer la cuenta de un mantenedor, o ganar antes su confianza como colaborador, para después introducir código malicioso en una versión legítima. En la puerta trasera de xz Utils divulgada en marzo de 2024 (CVE-2024-3094), una persona que desde 2021 había dedicado más de dos años a profundizar su participación en el desarrollo colocó el mecanismo en el archivo de distribución y no en el repositorio de código fuente.
Abuso de pipelines CI/CD: Infiltrarse en entornos CI/CD como GitHub Actions o Jenkins para alterar los artefactos de compilación.

En todos los patrones el malware se propaga a través de canales de distribución legítimos, de modo que la estructura del ataque deja al receptor sin apenas posibilidad de advertir la irregularidad.

Medidas de defensa y marcos de referencia

La defensa contra los ataques a la cadena de suministro es insuficiente con una sola medida y requiere un enfoque multicapa.

Gestión de dependencias

Creación de un SBOM (Software Bill of Materials): Catalogar todos los componentes de los que depende la aplicación y usarlo como base de la gestión de vulnerabilidades.
Fijación de dependencias y verificación de hash: Fijar las versiones con un archivo de bloqueo y verificar los valores hash de los paquetes para detectar alteraciones.
Uso de registros privados: En lugar de referenciar paquetes externos directamente, pasar por un registro privado que contenga solo paquetes verificados.

Protección de la compilación y el despliegue

Compilaciones reproducibles: Garantizar que el mismo código fuente genere siempre un binario idéntico, lo que permite detectar alteraciones del entorno de compilación.
Firma y verificación: Agregar una firma digital a los artefactos de compilación y verificar esa firma en el destino de distribución. Se pueden utilizar herramientas como Sigstore.
Rigor en la seguridad de contenedores: Realizar el escaneo de las imágenes de contenedor, la gestión de las imágenes base y la verificación de las firmas de imagen.

Medidas organizativas

Aplicación de la confianza cero: No confiar en ningún componente de la cadena de suministro y verificarlos de forma continua.
Plan de respuesta a incidentes: Incluir un escenario que suponga el compromiso de la cadena de suministro y preparar el procedimiento desde la detección hasta la contención.
Aprovechamiento de SLSA (Supply-chain Levels for Software Artifacts): Un marco originado en Google cuya especificación se publica como proyecto de OpenSSF. Define en niveles escalonados hasta qué punto se puede garantizar la procedencia (provenance) de una compilación, de modo que la organización puede ir acumulando medidas mientras comprueba en qué etapa se encuentra.

Riesgos de IaC y la cadena de suministro de infraestructura

Los ataques a la cadena de suministro no se limitan al código de aplicación, sino que también se extienden al ámbito de IaC (Infrastructure as Code). Si se alteran componentes de terceros utilizados en definiciones de infraestructura, como módulos de Terraform o plantillas de CloudFormation, todo el entorno en la nube podría verse comprometido.

Para mitigar los riesgos de la cadena de suministro de IaC, las siguientes medidas son efectivas.

Fijar las versiones de los módulos de Terraform y de los charts de Helm, y verificarlas mediante hash
Realizar una revisión de código antes de adoptar un módulo de terceros
Revisar siempre por una persona las diferencias de un cambio de infraestructura (plan/changeset) antes de aplicarlo
Restringir los permisos de ejecución del pipeline de IaC al mínimo necesario basándose en el principio de privilegios mínimos

Es necesario tener preparado de antemano un sistema que verifique la confiabilidad de la cadena de suministro tanto en el software como en la infraestructura.

Para obtener más información sobre este tema, consulte Ataques a la cadena de suministro - La nueva amenaza que explota la confianza.

Conceptos erróneos comunes

El software de proveedores de confianza es seguro: Como demostró el incidente de SolarWinds, incluso el software legítimo de grandes proveedores puede contener código malicioso si el proceso de compilación es comprometido. La confiabilidad del proveedor y la seguridad del software son cuestiones separadas, y la verificación también es necesaria por parte del receptor.
El código abierto es seguro porque muchos ojos lo vigilan: Muchos proyectos de código abierto dependen de un pequeño número de mantenedores, y no todos los commits se revisan adecuadamente. En la puerta trasera de xz Utils divulgada en marzo de 2024, el atacante dedicó más de dos años desde 2021 a profundizar su participación en el desarrollo y, una vez ganada la confianza, colocó el mecanismo.

Comparación entre ataques a la cadena de suministro y ataques de día cero

Ataque a la cadena de suministro

Se infiltra a través de cadenas de suministro de confianza. Difícil de detectar al explotar canales de actualización legítimos. Amplio alcance de impacto, con posibilidad de afectar a miles de organizaciones con un solo compromiso.

Ataque de día cero

Explota directamente vulnerabilidades desconocidas. El ataque se realiza cuando no existe un parche. Los ataques dirigidos son el caso de uso más visible, pero si la falla está en un producto muy extendido el impacto también puede ser de gran escala.

Ataque a la cadena de suministro