14 KiB
Pentesting CI/CD Μεθοδολογία
{{#include ../banners/hacktricks-training.md}}
VCS
VCS σημαίνει Version Control System, αυτό το σύστημα επιτρέπει στους προγραμματιστές να διαχειρίζονται τον πηγαίο κώδικά τους. Το πιο διαδεδομένο είναι το git και συνήθως οι εταιρείες το χρησιμοποιούν σε μία από τις παρακάτω πλατφόρμες:
- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (they offer their own VCS platforms)
CI/CD Pipelines
Τα CI/CD pipelines επιτρέπουν στους προγραμματιστές να αυτοματοποιούν την εκτέλεση κώδικα για διάφορους σκοπούς, όπως build, testing και deployment εφαρμογών. Αυτά τα αυτοματοποιημένα workflows προκαλούνται από συγκεκριμένες ενέργειες, όπως pushes, pull requests ή προγραμματισμένες εργασίες. Βοηθούν στο να γίνει πιο ομαλή η διαδικασία από το development έως το production.
Ωστόσο, αυτά τα συστήματα πρέπει να τρέξουν κάπου και συνήθως χρειάζονται privileged credentials για να αναπτυχθεί κώδικας ή να αποκτηθούν ευαίσθητες πληροφορίες.
VCS Pentesting Methodology
Note
Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
Πλατφόρμες που περιέχουν τον πηγαίο κώδικα του project σας φιλοξενούν ευαίσθητες πληροφορίες και πρέπει να δοθεί μεγάλη προσοχή στα permissions που χορηγούνται εντός της πλατφόρμας. Αυτά είναι μερικά κοινά προβλήματα σε VCS πλατφόρμες που ένας attacker θα μπορούσε να εκμεταλλευτεί:
- Leaks: Αν ο κώδικάς σας περιέχει leaks στα commits και ο attacker έχει πρόσβαση στο repo (επειδή είναι public ή επειδή έχει πρόσβαση), μπορεί να ανακαλύψει τα leaks.
- Access: Αν ένας attacker μπορεί να έχει access σε λογαριασμό μέσα στην VCS πλατφόρμα μπορεί να αποκτήσει μεγαλύτερη ορατότητα και δικαιώματα.
- Register: Κάποιες πλατφόρμες επιτρέπουν απλά σε εξωτερικούς χρήστες να δημιουργήσουν account.
- SSO: Κάποιες πλατφόρμες δεν επιτρέπουν εγγραφή, αλλά επιτρέπουν σε οποιονδήποτε να συνδεθεί με έγκυρο SSO (οπότε ένας attacker θα μπορούσε να χρησιμοποιήσει π.χ. το github account του για να μπει).
- Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... υπάρχουν διαφορετικοί τύποι tokens που ένας χρήστης μπορεί να κλέψει για να αποκτήσει πρόσβαση σε ένα repo.
- Webhooks: Οι VCS πλατφόρμες επιτρέπουν τη δημιουργία webhooks. Αν δεν είναι protected με μη ορατά secrets, ένας attacker θα μπορούσε να τα εκμεταλλευτεί.
- Αν δεν υπάρχει secret, ο attacker μπορεί να εκμεταλλευτεί το webhook της τρίτης πλατφόρμας
- Αν το secret βρίσκεται στο URL, συμβαίνει το ίδιο και ο attacker αποκτά και το secret
- Code compromise: Αν ένας malicious actor έχει κάποιο είδος write access στα repos, μπορεί να προσπαθήσει να ενσωματώσει malicious code. Για να το πετύχει ίσως χρειαστεί να bypass branch protections. Αυτές οι ενέργειες μπορούν να γίνουν με διαφορετικούς στόχους:
- Compromise το main branch για compromise production.
- Compromise το main (ή άλλα branches) για να compromise τα machines των developers (εφόσον αυτοί συνήθως εκτελούν tests, terraform ή άλλα πράγματα μέσα στο repo στα μηχανήματά τους).
- Compromise the pipeline (βλέπε επόμενη ενότητα)
Pipelines Pentesting Methodology
Ο πιο κοινός τρόπος να οριστεί ένα pipeline είναι με χρήση ενός CI configuration file που φιλοξενείται στο repository που κάνει build. Αυτό το αρχείο περιγράφει τη σειρά των jobs που θα εκτελεστούν, τις συνθήκες που επηρεάζουν τη ροή και τις ρυθμίσεις του build environment.
Αυτά τα αρχεία έχουν τυπικά ένα σταθερό όνομα και format, για παράδειγμα — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), και τα GitHub Actions YAML αρχεία κάτω από .github/workflows. Όταν ενεργοποιείται, το pipeline job τραβάει τον κώδικα από την επιλεγμένη πηγή (π.χ. commit / branch) και τρέχει τις εντολές που καθορίζονται στο CI configuration file πάνω σε αυτόν τον κώδικα.
Άρα ο τελικός στόχος του attacker είναι να με κάποιο τρόπο compromise αυτά τα configuration files ή τις εντολές που εκτελούν.
Tip
Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See:
{{#ref}} docker-build-context-abuse.md {{#endref}}
PPE - Poisoned Pipeline Execution
Η Poisoned Pipeline Execution (PPE) διαδρομή εκμεταλλεύεται permissions σε ένα SCM repository για να χειραγωγήσει ένα CI pipeline και να εκτελέσει επιβλαβείς εντολές. Χρήστες με τα απαραίτητα permissions μπορούν να τροποποιήσουν CI configuration files ή άλλα αρχεία που χρησιμοποιεί το pipeline job ώστε να συμπεριλάβουν malicious commands. Αυτό "δηλητηριάζει" το CI pipeline, οδηγώντας στην εκτέλεση αυτών των malicious εντολών.
Για να είναι επιτυχημένος ένας malicious actor σε ένα PPE attack πρέπει να μπορεί να:
- Έχει write access στην VCS πλατφόρμα, καθώς συνήθως τα pipelines ενεργοποιούνται όταν γίνεται push ή pull request. (Δείτε την VCS pentesting methodology για περίληψη τρόπων απόκτησης access).
- Σημειώστε ότι μερικές φορές ένα external PR μετράει ως "write access".
- Ακόμα κι αν έχει write permissions, πρέπει να είναι σίγουρος ότι μπορεί να τροποποιήσει το CI config file ή άλλα αρχεία στα οποία βασίζεται το config.
- Για αυτό μπορεί να χρειαστεί να bypass branch protections.
Υπάρχουν 3 flavours του PPE:
- D-PPE: Μια Direct PPE επίθεση συμβαίνει όταν ο actor τροποποιεί το CI config αρχείο που πρόκειται να εκτελεστεί.
- I-DDE: Μια Indirect PPE επίθεση συμβαίνει όταν ο actor τροποποιεί ένα file που το CI config που πρόκειται να εκτελεστεί εξαρτάται από (όπως ένα make file ή ένα terraform config).
- Public PPE or 3PE: Σε κάποιες περιπτώσεις τα pipelines μπορούν να προκαλούνται από χρήστες που δεν έχουν write access στο repo (και που μπορεί να μην είναι καν μέρος της org) επειδή μπορούν να στείλουν ένα PR.
- 3PE Command Injection: Συνήθως, CI/CD pipelines θα ορίσουν environment variables με πληροφορίες για το PR. Αν αυτή η τιμή μπορεί να ελεγχθεί από attacker (όπως ο τίτλος του PR) και χρησιμοποιείται σε επικίνδυνη θέση (όπως εκτέλεση sh commands), ένας attacker μπορεί να ενθέσει εντολές εκεί.
Οφέλη Εκμετάλλευσης
Γνωρίζοντας τις 3 flavour για να δηλητηριάσει κανείς ένα pipeline, ας δούμε τι μπορεί να αποκτήσει ένας attacker μετά από επιτυχή εκμετάλλευση:
- Secrets: Όπως αναφέρθηκε προηγουμένως, τα pipelines χρειάζονται privileges για τα jobs τους (να πάρουν τον κώδικα, να τον buildάρουν, να τον αναπτύξουν...) και αυτά τα privileges συνήθως παρέχονται ως secrets. Αυτά τα secrets είναι συνήθως προσβάσιμα μέσω env variables ή αρχείων μέσα στο σύστημα. Επομένως ένας attacker θα προσπαθήσει πάντα να εξάγει όσο το δυνατόν περισσότερα secrets.
- Ανάλογα με την πλατφόρμα pipeline, ο attacker μπορεί να χρειαστεί να δηλώσει τα secrets στο config. Αυτό σημαίνει ότι αν ο attacker δεν μπορεί να τροποποιήσει το CI configuration pipeline (I-PPE για παράδειγμα), μπορεί να εξάγει μόνο τα secrets που ήδη έχει το pipeline.
- Computation: Ο κώδικας εκτελείται κάπου· ανάλογα με το που εκτελείται, ένας attacker μπορεί να καταφέρει pivot περαιτέρω.
- On-Premises: Αν τα pipelines εκτελούνται on-premises, ένας attacker μπορεί να βρεθεί στο εσωτερικό δίκτυο με πρόσβαση σε περισσότερους πόρους.
- Cloud: Ο attacker θα μπορούσε να αποκτήσει πρόσβαση σε άλλες μηχανές στο cloud αλλά και να εξάγει IAM roles/service accounts tokens για να αποκτήσει περαιτέρω πρόσβαση μέσα στο cloud.
- Platforms machine: Κάποιες φορές τα jobs θα εκτελούνται μέσα στις μηχανές της πλατφόρμας pipelines, που συνήθως βρίσκονται σε ένα cloud χωρίς επιπλέον access.
- Select it: Μερικές φορές η πλατφόρμα pipelines έχει διαμορφώσει πολλές μηχανές και αν μπορείτε να τροποποιήσετε το CI configuration file μπορείτε να υποδείξετε που θέλετε να τρέξει ο malicious κώδικας. Σε αυτή την περίπτωση, ένας attacker πιθανόν θα τρέξει έναν reverse shell σε κάθε πιθανή μηχανή για να προσπαθήσει να την εκμεταλλευτεί περαιτέρω.
- Compromise production: Αν βρίσκεστε μέσα στο pipeline και η τελική έκδοση χτίζεται και αναπτύσσεται από αυτό, μπορείτε να compromise τον κώδικα που θα τρέξει σε production.
More relevant info
Tools & CIS Benchmark
- Chain-bench είναι ένα open-source εργαλείο για auditing του software supply chain stack σας για security compliance βασισμένο σε έναν νέο CIS Software Supply Chain benchmark. Το auditing εστιάζει στην ολόκληρη διαδικασία SDLC, όπου μπορεί να αποκαλύψει κινδύνους από το code έως το deploy time.
Top 10 CI/CD Security Risk
Δείτε αυτό το ενδιαφέρον άρθρο για τα top 10 CI/CD risks σύμφωνα με την Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/
Labs
- Σε κάθε πλατφόρμα που μπορείτε να τρέξετε τοπικά θα βρείτε πώς να το ξεκινήσετε τοπικά ώστε να το ρυθμίσετε όπως θέλετε για να το δοκιμάσετε
- Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat
Automatic Tools
- Checkov: Checkov είναι ένα static code analysis tool για infrastructure-as-code.
References
{{#include ../banners/hacktricks-training.md}}