hacktricks-cloud/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

Μεθοδολογία Pentesting CI/CD

{{#include ../banners/hacktricks-training.md}}

VCS

VCS σημαίνει Version Control System, αυτά τα συστήματα επιτρέπουν στους developers να διαχειρίζονται τον source code τους. Το πιο συνηθισμένο είναι το git και συνήθως θα βρείτε εταιρείες να το χρησιμοποιούν σε μία από τις ακόλουθες platforms:

• Github
• Gitlab
• Bitbucket
• Gitea
• Gitblit
• Cloud providers (προσφέρουν τις δικές τους πλατφόρμες VCS)

CI/CD Pipelines

Τα CI/CD pipelines επιτρέπουν στους developers να αυτοματοποιούν την εκτέλεση code για διάφορους σκοπούς, όπως build, testing και deploy εφαρμογών. Αυτά τα automated workflows ενεργοποιούνται από συγκεκριμένες ενέργειες, όπως code pushes, pull requests ή scheduled tasks. Είναι χρήσιμα για να απλοποιούν τη διαδικασία από development σε production.

Ωστόσο, αυτά τα συστήματα πρέπει να εκτελούνται κάπου και συνήθως με privileged credentials για deploy code ή πρόσβαση σε sensitive information.

VCS Pentesting Methodology

Note

Ακόμα κι αν ορισμένες VCS platforms επιτρέπουν τη δημιουργία pipelines για αυτή την ενότητα, θα αναλύσουμε μόνο πιθανές attacks στον έλεγχο του source code.

Platforms που περιέχουν τον source code του project σας περιέχουν sensitive information και οι άνθρωποι πρέπει να είναι πολύ προσεκτικοί με τα permissions που δίνονται μέσα σε αυτή την platform. Αυτά είναι μερικά συνηθισμένα προβλήματα σε VCS platforms που ένας attacker θα μπορούσε να εκμεταλλευτεί:

• Leaks: Αν ο code σας περιέχει leaks στα commits και ο attacker μπορεί να αποκτήσει πρόσβαση στο repo (επειδή είναι public ή επειδή έχει πρόσβαση), θα μπορούσε να ανακαλύψει τα leaks.
• Access: Αν ένας attacker μπορεί να αποκτήσει πρόσβαση σε ένα account μέσα στην VCS platform, θα μπορούσε να αποκτήσει περισσότερη ορατότητα και permissions.
• Register: Ορισμένες platforms θα επιτρέπουν απλώς σε external users να δημιουργήσουν account.
• SSO: Ορισμένες platforms δεν θα επιτρέπουν σε users να κάνουν register, αλλά θα επιτρέπουν σε οποιονδήποτε να αποκτά πρόσβαση με έγκυρο SSO (οπότε ένας attacker θα μπορούσε για παράδειγμα να χρησιμοποιήσει το github account του για να μπει).
• Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... υπάρχουν αρκετοί τύποι tokens που ένας user θα μπορούσε να κλέψει για να αποκτήσει με κάποιον τρόπο πρόσβαση σε ένα repo.
• Webhooks: Οι VCS platforms επιτρέπουν τη δημιουργία webhooks. Αν δεν είναι προστατευμένα με μη ορατά secrets, ένας attacker θα μπορούσε να τα εκμεταλλευτεί.
• Αν δεν υπάρχει secret, ο attacker μπορεί να εκμεταλλευτεί το webhook της τρίτης πλευράς platform
• Αν το secret είναι στο URL, συμβαίνει το ίδιο και ο attacker έχει επίσης το secret
• Code compromise: Αν ένας malicious actor έχει κάποιο είδος write access στα repos, θα μπορούσε να προσπαθήσει να εισάγει malicious code. Για να είναι επιτυχής μπορεί να χρειάζεται να παρακάμψει branch protections. Αυτές οι ενέργειες μπορούν να εκτελεστούν με διαφορετικούς στόχους στο μυαλό:
• Compromise το main branch για να compromise production.
• Compromise το main (ή άλλα branches) για να compromise developer machines (καθώς συνήθως εκτελούν test, terraform ή άλλα πράγματα μέσα από το repo στα μηχανήματά τους).
• Compromise το pipeline (δείτε την επόμενη ενότητα)

Pipelines Pentesting Methodology

Ο πιο συνηθισμένος τρόπος να οριστεί ένα pipeline είναι με τη χρήση ενός CI configuration file hosted in the repository που χτίζει το pipeline. Αυτό το αρχείο περιγράφει τη σειρά των jobs που εκτελούνται, συνθήκες που επηρεάζουν τη ροή και ρυθμίσεις του build environment.
Αυτά τα αρχεία συνήθως έχουν σταθερό όνομα και format, για παράδειγμα — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), και τα GitHub Actions YAML files που βρίσκονται κάτω από .github/workflows. Όταν ενεργοποιηθεί, το pipeline job κατεβάζει τον code από την επιλεγμένη source (π.χ. commit / branch), και εκτελεί τις commands που ορίζονται στο CI configuration file πάνω σε αυτόν τον code.

Επομένως, ο τελικός στόχος του attacker είναι με κάποιον τρόπο να compromise αυτά τα configuration files ή τις commands που εκτελούν.

Tip

Ορισμένοι hosted builders επιτρέπουν στους contributors να επιλέξουν το Docker build context και το Dockerfile path. Αν το context ελέγχεται από attacker, μπορείτε να το ορίσετε εκτός του repo (π.χ. "..") ώστε να γίνει ingest host files κατά το build και να exfiltrate secrets. Δείτε:

{{#ref}} docker-build-context-abuse.md {{#endref}}

PPE - Poisoned Pipeline Execution

Το Poisoned Pipeline Execution (PPE) path εκμεταλλεύεται permissions σε ένα SCM repository για να χειριστεί ένα CI pipeline και να εκτελέσει harmful commands. Users με τα απαραίτητα permissions μπορούν να τροποποιήσουν CI configuration files ή άλλα files που χρησιμοποιεί το pipeline job ώστε να περιλάβουν malicious commands. Αυτό «δηλητηριάζει» το CI pipeline, οδηγώντας στην εκτέλεση αυτών των malicious commands.

Για να είναι επιτυχής ένας malicious actor σε μια PPE attack, χρειάζεται να μπορεί να:

• Να έχει write access στην VCS platform, καθώς συνήθως τα pipelines ενεργοποιούνται όταν γίνεται push ή pull request. (Δείτε τη VCS pentesting methodology για σύνοψη των τρόπων απόκτησης πρόσβασης).
• Σημειώστε ότι μερικές φορές ένα external PR μετρά ως "write access".
• Ακόμα κι αν έχει write permissions, πρέπει να είναι βέβαιος ότι μπορεί να τροποποιήσει το CI config file ή άλλα files στα οποία βασίζεται το config.
• Για αυτό, μπορεί να χρειάζεται να μπορεί να παρακάμψει branch protections.

Υπάρχουν 3 PPE flavours:

• D-PPE: Μια Direct PPE attack συμβαίνει όταν ο actor τροποποιεί το CI config file που πρόκειται να εκτελεστεί.
• I-DDE: Μια Indirect PPE attack συμβαίνει όταν ο actor τροποποιεί ένα file στο οποίο βασίζεται το CI config file που πρόκειται να εκτελεστεί (relays on) (όπως ένα make file ή ένα terraform config).
• Public PPE or 3PE: Σε ορισμένες περιπτώσεις τα pipelines μπορούν να ενεργοποιηθούν από users που δεν έχουν write access στο repo (και μπορεί να μην ανήκουν καν στο org) επειδή μπορούν να στείλουν PR.
• 3PE Command Injection: Συνήθως, τα CI/CD pipelines θα ορίζουν environment variables με πληροφορίες για το PR. Αν αυτή η τιμή μπορεί να ελεγχθεί από attacker (όπως ο τίτλος του PR) και χρησιμοποιείται σε επικίνδυνο σημείο (όπως η εκτέλεση sh commands), ένας attacker μπορεί να inject commands εκεί μέσα.

Exploitation Benefits

Γνωρίζοντας τις 3 flavours για να poison ένα pipeline, ας δούμε τι θα μπορούσε να αποκτήσει ένας attacker μετά από επιτυχημένη exploitation:

• Secrets: Όπως αναφέρθηκε προηγουμένως, τα pipelines απαιτούν privileges για τα jobs τους (ανάκτηση του code, build, deploy...) και αυτά τα privileges συνήθως δίνονται σε secrets. Αυτά τα secrets είναι συνήθως προσβάσιμα μέσω env variables ή files μέσα στο system. Επομένως ένας attacker θα προσπαθεί πάντα να exfiltrate όσο το δυνατόν περισσότερα secrets.
• Ανάλογα με την platform του pipeline, ο attacker ίσως χρειάζεται να καθορίσει τα secrets στο config. Αυτό σημαίνει ότι αν ο attacker δεν μπορεί να τροποποιήσει το CI configuration pipeline (I-PPE για παράδειγμα), θα μπορούσε να exfiltrate μόνο τα secrets που έχει αυτό το pipeline.
• Computation: Ο code εκτελείται κάπου, ανάλογα με το πού εκτελείται ένας attacker μπορεί να μπορέσει να pivot further.
• On-Premises: Αν τα pipelines εκτελούνται on premises, ένας attacker μπορεί να καταλήξει σε internal network με πρόσβαση σε περισσότερους resources.
• Cloud: Ο attacker θα μπορούσε να αποκτήσει πρόσβαση σε άλλα machines στο cloud αλλά και να exfiltrate IAM roles/service accounts tokens από εκεί για να αποκτήσει περαιτέρω πρόσβαση μέσα στο cloud.
• Platforms machine: Μερικές φορές τα jobs θα εκτελούνται μέσα στα machines της pipelines platform, τα οποία συνήθως βρίσκονται μέσα σε ένα cloud με no more access.
• Select it: Μερικές φορές η pipelines platform θα έχει ρυθμίσει several machines και αν μπορείτε να τροποποιήσετε το CI configuration file μπορείτε να υποδείξετε πού θέλετε να εκτελεστεί ο malicious code. Σε αυτή την κατάσταση, ένας attacker πιθανότατα θα τρέξει ένα reverse shell σε κάθε πιθανό machine για να προσπαθήσει να το εκμεταλλευτεί περαιτέρω.
• Compromise production: Αν είστε μέσα στο pipeline και η τελική έκδοση χτίζεται και γίνεται deploy από αυτό, θα μπορούσατε να compromise τον code που πρόκειται να καταλήξει να εκτελείται σε production.

Dependency & Registry Supply-Chain Abuse

Το compromise ενός CI/CD pipeline ή το κλέψιμο credentials από αυτό μπορεί να επιτρέψει σε έναν attacker να μετακινηθεί από την pipeline execution σε ecosystem-wide code execution backdooring dependencies ή release tooling:

• Install-time code execution via package hooks: δημοσιεύστε μια package version που προσθέτει preinstall, postinstall, prepare, ή παρόμοια hooks ώστε το payload να εκτελείται αυτόματα σε developer workstations και CI runners κατά την εγκατάσταση dependencies.
• Secondary execution paths: ακόμα κι αν οι στόχοι εγκαθιστούν με --ignore-scripts, ένα malicious package μπορεί παρ' όλα αυτά να καταχωρήσει ένα common CLI name στο bin field ώστε το attacker-controlled wrapper να γίνει symlink στο PATH και να εκτελεστεί αργότερα όταν χρησιμοποιηθεί η command.
• Runtime bootstrapping: ένα μικρό installer μπορεί να κατεβάσει ένα δεύτερο runtime ή toolchain κατά την εγκατάσταση (για παράδειγμα Bun ή έναν packed interpreter) και μετά να εκκινήσει το main payload με αυτό, αποφεύγοντας τοπικές dependency requirements.
• Credential harvesting from build environments: μόλις ο code εκτελεστεί μέσα στο CI, ελέγξτε environment variables, ~/.npmrc, ~/.git-credentials, SSH keys, cloud CLI configs και local tooling όπως gh auth token. Στο GitHub Actions, κοιτάξτε επίσης για runner-specific secrets και artifacts.
• Workflow injection with stolen GitHub tokens: ένα token με repo + workflow permissions είναι αρκετό για να δημιουργήσει ένα branch, να κάνει commit ένα malicious file μέσα στο .github/workflows/, να το ενεργοποιήσει, να συλλέξει τα παραγόμενα artifacts/logs και μετά να διαγράψει το προσωρινό branch/workflow run για να μειώσει τα traces.
• Wormable registry propagation: τα stolen npm tokens πρέπει να επαληθεύονται για permissions publish και αν παρακάμπτουν 2FA. Αν το κάνουν, enumerate writable packages, κατεβάστε τα tarballs τους, inject ένα loader όπως setup.mjs, ορίστε preinstall για να το εκτελεί, αυξήστε το patch version και republish. Αυτό μετατρέπει ένα CI compromise σε downstream auto-execution σε άλλα environments.

Practical checks during an assessment

• Ελέγξτε το release automation για package-manager hooks που προστέθηκαν στο package.json, unexpected bin entries ή version bumps που τροποποιούν μόνο το release artifact.
• Ελέγξτε αν το CI αποθηκεύει long-lived registry credentials σε plaintext files όπως ~/.npmrc αντί να χρησιμοποιεί short-lived OIDC ή trusted publishing.
• Επαληθεύστε αν τα GitHub tokens που είναι διαθέσιμα στο CI μπορούν να γράψουν workflow files ή να δημιουργήσουν branches/tags.
• Αν υπάρχει υποψία για compromised package, επιθεωρήστε το published tarball και όχι μόνο το Git repository, γιατί ο malicious loader/runtime μπορεί να υπάρχει μόνο στο published artifact.
• Αναζητήστε απρόσμενη package-manager execution μέσα στο CI, όπως npm install αντί για npm ci, απρόσμενα Bun downloads/execution ή νέα workflow artifacts που παράγονται από transient branches.
• Εξετάστε τα GitOps deployment engines και ως CI/CD targets επίσης. Η Argo CD-specific enumeration, το repo-server abuse και τα Redis cache poisoning attacks καλύπτονται στο Argo CD Security.

More relevant info

Tools & CIS Benchmark

• Chain-bench είναι ένα open-source tool για auditing του software supply chain stack σας ως προς security compliance, με βάση ένα νέο CIS Software Supply Chain benchmark. Το auditing εστιάζει σε όλη τη διαδικασία SDLC, όπου μπορεί να αποκαλύψει risks από code time έως deploy time.

Top 10 CI/CD Security Risk

Δείτε αυτό το ενδιαφέρον άρθρο για τα top 10 CI/CD risks σύμφωνα με το Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

• Σε κάθε platform που μπορείτε να τρέξετε locally θα βρείτε πώς να την εκκινήσετε locally ώστε να τη ρυθμίσετε όπως θέλετε για να τη δοκιμάσετε
• Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat

Automatic Tools

• Checkov: Το Checkov είναι ένα static code analysis tool για infrastructure-as-code.

References

• https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422
• The npm Threat Landscape: Attack Surface and Mitigations
• Checkmarx Security Update: April 22, 2026

{{#include ../banners/hacktricks-training.md}}