DevSecOps series No. 1 — Rompiendo el CI/CD usando repositorios Git maliciosos
Este es el primer post de una serie sobre DevSecOps. Hablaremos sobre la (in)seguridad en el proceso de DevSecOps.
Hoy veremos la seguridad en el proceso de construcción cuando necesitas GIT externo.
GIT en el proceso de CI
Clonar repositorios GIT es el pan de cada día de un pipeline de CI cuando estás construyendo artefactos. Y hay lenguajes que tiran de GIT bastante más que otros durante la construcción. En GoLang, sin ir más lejos, puedes declarar las dependencias directamente como URLs de Github:
package main
import (
"github.com/spf13/cobra"
"github.com/pkg/errors"
)
func main() {
...
}
Esto lo hace cualquier proceso de CI a diario. Nada raro hasta aquí.
Repositorios GIT maliciosos
Las bombas de software son un clásico de toda la vida en seguridad informática. Y sí, a alguien se le ocurrió llevar la idea a Git.
Desde 2017 hay una PoC pública de Git Bomb. Tienes todos los detalles en la web de la autora: https://kate.io/blog/git-bomb/
Git Bomb es, ni más ni menos, un repositorio montado a mala idea para que el clonado se atasque y no termine nunca.
Probando el ataque de Git Bomb
Si alguno de los repositorios de los que depende tu build está comprometido (o el autor es un “gracioso”), la máquina de CI se te queda tiesa en cuanto intentes clonar.
Con suerte, si la tienes bien apretada, el proceso morirá solo cuando salte el timeout.
Aquí tienes lo que pasa al clonar el repositorio de la PoC de Git Bomb:

Lo corté a los 4 minutos porque aquello no iba a ninguna parte.
Y la CPU, mientras tanto, clavada casi al 100%:

No seáis malos y no hagáis esto en casa 😜