Google presentó el marco SLSA (Niveles de Cadena de Suministro para Artefactos de Software), que resume la experiencia existente en la protección de la infraestructura de desarrollo contra ataques que ocurren en la etapa de escritura de código, pruebas, compilación y distribución del producto.
Los procesos de desarrollo se están volviendo cada vez más complejos y dependientes de herramientas externas, lo que crea condiciones favorables para las amenazas que no se centran en identificar y explotar vulnerabilidades en el producto final, sino en comprometer el propio proceso de desarrollo (los ataques de 'cadena de suministro', que generalmente están dirigidos a la introducción de cambios maliciosos durante la escritura de código, el reemplazo de componentes distribuidos y dependencias).
El marco considera 8 tipos de ataques relacionados con las amenazas de introducir cambios maliciosos en las etapas de desarrollo de código, compilación, pruebas y distribución del producto.
- A. Inclusión en el código fuente de cambios que contengan puertas traseras o errores ocultos que conducen a vulnerabilidades.
Ejemplo de ataque: ‘Hypocrite Commits’ — intento de promover parches con vulnerabilidades en el núcleo de Linux.
Método de defensa propuesto: revisión independiente de cada cambio por dos desarrolladores.
- B. Compromiso de la plataforma de gestión de código fuente.
Ejemplo de ataque: introducción de commits maliciosos con puerta trasera en el repositorio Git del proyecto PHP tras la filtración de contraseñas de los desarrolladores.
Método de defensa propuesto: aumentar la seguridad de la plataforma de gestión de código (en el caso de PHP, el ataque se realizó a través de una interfaz HTTPS poco utilizada, que permitía enviar cambios al acceder con una contraseña sin verificación de clave SSH, mientras que se utilizaba MD5 poco confiable para el hash de contraseñas).
- C. Introducción de cambios en la etapa de transferencia de código al sistema de compilación o integración continua (se compila código que no corresponde al código del repositorio).
Ejemplo de ataque: introducción de una puerta trasera en Webmin mediante cambios en la infraestructura de compilación, que llevaron al uso de archivos con código diferente a los archivos en el repositorio.
Método de defensa propuesto: verificación de la integridad e identificación del origen del código en la compilación. servidor.
- D. Compromiso de la plataforma de compilación.
Ejemplo de ataque: el ataque de SolarWinds, en el que se logró la implementación de un backdoor en el producto SolarWinds Orion durante la fase de construcción.
Método de protección propuesto: implementación de medidas de seguridad avanzadas en la plataforma de construcción.
- E. Promoción de código malicioso a través de dependencias de baja calidad.
Ejemplo de ataque: implementación de un backdoor en la popular biblioteca event-stream, a través de la adición de una dependencia inocua que posteriormente incluyó código malicioso en una de las actualizaciones de esta dependencia (el cambio malicioso no se reflejó en el repositorio git y solo estaba presente en el paquete MNP listo).
Método de protección propuesto: aplicación recursiva de los requisitos de SLSA a todas las dependencias (en el caso de event-stream, la verificación habría identificado la construcción del código que no correspondía al contenido del repositorio git principal).
- F. Carga de artefactos que no fueron creados en el sistema CI/CD.
Ejemplo de ataque: incorporación de código malicioso en el script CodeCov, permitiendo a los atacantes extraer información almacenada en los entornos de los sistemas de integración continua de los clientes.
Método de protección propuesto: control de la fuente y la integridad de los artefactos (en el caso de CodeCov, se podría haber identificado que el script Bash Uploader entregado desde el sitio codecov.io no coincidía con el código del repositorio del proyecto).
- G. Compromiso del repositorio de paquetes.
Ejemplo de ataque: los investigadores lograron desplegar espejos de algunos repositorios de paquetes populares con el fin de distribuir paquetes maliciosos a través de ellos.
Método de protección propuesto: Verificación de que los artefactos distribuidos provienen de los códigos fuente declarados.
- H. Confusión del usuario para instalar el paquete incorrecto.
Ejemplo de ataque: uso de typosquatting (NPM, RubyGems, PyPI) para crear en los repositorios paquetes que son similares en escritura a aplicaciones populares (por ejemplo, coffe-script en lugar de coffee-script).
Para bloquear las amenazas identificadas, SLSA ofrece un conjunto de recomendaciones, así como herramientas para automatizar la creación de metadatos para auditoría. SLSA resume los métodos típicos de ataque e introduce el concepto de niveles de protección. Cada nivel tiene requisitos específicos para la infraestructura, lo que permite garantizar la integridad de los artefactos utilizados durante el desarrollo. Cuanto mayor sea el nivel SLSA mantenido, más medidas de protección se implementan y mejor está protegida la infraestructura contra ataques típicos.
- SLSA 1 — requiere que el proceso de construcción esté completamente automatizado y genere metadatos ('provenance') sobre cómo se construyen los artefactos, incluyendo información sobre el código fuente, dependencias y el proceso de construcción (se propone un ejemplo de generador de metadatos para auditoría para GitHub Actions). SLSA 1 no incluye elementos de protección contra modificaciones maliciosas, sino que simplemente identifica de manera básica el código y proporciona metadatos para la gestión de vulnerabilidades y el análisis de riesgos.
- SLSA 2 — amplía el primer nivel con el requisito de usar un sistema de control de versiones y servicios de construcción que generen metadatos autentificados. La aplicación de SLSA 2 permite rastrear el origen del código y previene modificaciones no autorizadas en el código, siempre que se utilicen servicios de construcción de confianza.
- SLSA 3 — confirma que los códigos fuente y la plataforma de construcción cumplen con los requisitos de estándares que garantizan la posibilidad de auditar el código y asegurar la integridad de los metadatos proporcionados. Se espera que los auditores puedan certificar plataformas para verificar su cumplimiento con los requisitos de los estándares.
- SLSA 4 — el nivel más alto, complementando los niveles anteriores con los siguientes requisitos:
- Revisión obligatoria de todos los cambios por dos desarrolladores diferentes.
- Todos los pasos de construcción, código y dependencias deben ser completamente declarados, todas las dependencias deben ser extraídas y verificadas por separado, y el proceso de construcción debe llevarse a cabo sin acceso a la red.
- Aplicación del proceso de construcción repetible — la capacidad de repetir el proceso de construcción por cuenta propia y asegurarse de que el archivo ejecutable está construido a partir de los códigos fuente proporcionados.
Fuente: opennet.ru
