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 de ataques llevados a cabo en la etapa de escritura de código, prueba, ensamblaje y distribución de un producto.
Los procesos de desarrollo son cada vez más complejos y dependientes de herramientas de terceros, lo que crea condiciones favorables para el avance de ataques relacionados no con identificar y explotar vulnerabilidades en el producto final, sino con comprometer el proceso de desarrollo en sí (ataques a la cadena de suministro, generalmente dirigidos a introducción de cambios maliciosos en el proceso de escritura de código, sustitución de componentes distribuidos y dependencias).
El marco tiene en cuenta 8 tipos de ataques relacionados con la amenaza de realizar cambios maliciosos en la etapa de desarrollo, ensamblaje, prueba y distribución del código del producto.
- R. Incluyendo cambios en el código fuente que contienen puertas traseras o errores ocultos que conducen a vulnerabilidades.
Ejemplo de ataque: "Commitciones hipócritas": un intento de promover parches con vulnerabilidades en el kernel de Linux.
Método de seguridad sugerido: revisión independiente de cada cambio por parte de dos desarrolladores.
- B. Compromiso de la plataforma de control del código fuente.
Ejemplo de ataque: inyección de confirmaciones maliciosas con una puerta trasera en el repositorio Git de un proyecto PHP después de que se filtraran las contraseñas de los desarrolladores.
Método de protección sugerido: Mayor 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 iniciar sesión con contraseña sin verificar la clave SSH, a pesar de el hecho de que se utilizó MD5 no confiable para codificar contraseñas).
- C. Realizar cambios en la etapa de transferencia de código al sistema de compilación o integración continua (se compila el código que no coincide con el código del repositorio).
Ejemplo de ataque: inyectar una puerta trasera en Webmin realizando cambios en la infraestructura de compilación, lo que da como resultado el uso de archivos de código que difieren de los archivos del repositorio.
Método de protección propuesto: comprobar la integridad e identificar la fuente del código en el servidor de ensamblaje.
- D. Compromiso de la plataforma de montaje.
Ejemplo de ataque: el ataque a SolarWinds, durante el cual se aseguró la instalación de una puerta trasera en el producto SolarWinds Orion durante la etapa de montaje.
Método de protección propuesto: implementación de medidas de seguridad avanzadas para la plataforma de montaje.
- E. Promoción de código malicioso a través de dependencias de baja calidad.
Un ejemplo de ataque: la introducción de una puerta trasera en la popular biblioteca de flujo de eventos agregando una dependencia inofensiva y luego incluyendo código malicioso en una de las actualizaciones de esta dependencia (el cambio malicioso no se reflejó en el repositorio de git, pero se presente sólo en el paquete MNP terminado).
Método de protección sugerido: aplicar recursivamente los requisitos de SLSA a todas las dependencias (en el caso del flujo de eventos, la verificación revelaría el ensamblaje de código que no corresponde al contenido del repositorio principal de Git).
- F. Cargar artefactos no creados en el sistema CI/CD.
Ejemplo de ataque: agregar código malicioso al script CodeCov, lo que permitió a los atacantes extraer información almacenada en los entornos del sistema de integración continua del cliente.
Método de protección propuesto: control sobre el origen y la integridad de los artefactos (en el caso de CodeCov, se podría revelar que el script Bash Uploader enviado desde el sitio web codecov.io no corresponde al código del repositorio del proyecto).
- G. Compromiso del repositorio de paquetes.
Ejemplo de ataque: los investigadores pudieron implementar réplicas de algunos repositorios de paquetes populares para distribuir paquetes maliciosos a través de ellos.
Método de protección sugerido: Verificación de que los artefactos distribuidos estén compilados a partir de los códigos fuente declarados.
- H. Confundir al usuario para que instale el paquete incorrecto.
Ejemplo de ataque: uso de typosquatting (NPM, RubyGems, PyPI) para colocar paquetes en repositorios que son similares en escritura a aplicaciones populares (por ejemplo, coffe-script en lugar de coffee-script).
Para bloquear las amenazas marcadas, SLSA ofrece un conjunto de recomendaciones, así como herramientas para automatizar la creación de metadatos de auditoría. SLSA resume los métodos de ataque comunes e introduce el concepto de capas de seguridad. Cada nivel impone ciertos requisitos de infraestructura para garantizar la integridad de los artefactos utilizados en el desarrollo. Cuanto mayor sea el nivel SLSA admitido, más protecciones se implementarán y mejor estará protegida la infraestructura contra ataques comunes.
- SLSA 1 requiere que el proceso de compilación esté completamente automatizado y genere metadatos (“procedencia”) sobre cómo se construyen los artefactos, incluida información sobre fuentes, dependencias y el proceso de compilación (se proporciona un generador de metadatos de ejemplo para auditoría para GitHub Actions). SLSA 1 no incluye elementos de protección contra modificaciones maliciosas, sino que simplemente identifica 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 al requerir el uso de control de versiones y servicios de ensamblaje que generan metadatos autenticados. El uso de SLSA 2 le permite rastrear el origen del código y evita cambios no autorizados en el código en el caso de servicios de compilación confiables.
- SLSA 3: confirma que el código fuente y la plataforma de compilación cumplen con los requisitos de los estándares que garantizan la capacidad de auditar el código y garantizar la integridad de los metadatos proporcionados. Se supone que los auditores pueden certificar plataformas según los requisitos de las normas.
- SLSA 4 es el nivel más alto, complementando los niveles anteriores con los siguientes requisitos:
- Revisión obligatoria de todos los cambios por parte de dos desarrolladores diferentes.
- Todos los pasos de compilación, el código y las dependencias deben declararse en su totalidad, todas las dependencias deben extraerse y verificarse por separado y el proceso de compilación debe realizarse sin conexión.
- El uso de un proceso de compilación repetible le permite repetir el proceso de compilación usted mismo y asegurarse de que el ejecutable se genere a partir del código fuente proporcionado.
Fuente: opennet.ru