Translated ['src/pentesting-ci-cd/argocd-security.md', 'src/pentesting-c

This commit is contained in:
Translator
2026-07-06 15:54:48 +00:00
parent b2746172c9
commit 882b57e044
2 changed files with 271 additions and 51 deletions
+219
View File
@@ -0,0 +1,219 @@
# Argo CD Security
{{#include ../banners/hacktricks-training.md}}
## Βασικές Πληροφορίες
[Argo CD](https://argo-cd.readthedocs.io/) είναι μια GitOps πλατφόρμα continuous delivery για Kubernetes. Παρακολουθεί Git repositories, αποδίδει Kubernetes manifests με εργαλεία όπως Helm, Kustomize, Jsonnet ή config management plugins, και συγχρονίζει το live cluster state με το desired state που είναι αποθηκευμένο στο Git.
Από την οπτική του attacker, αντιμετώπισε το Argo CD ως μια **deployment engine με Kubernetes credentials**. Ένας χρήσιμος compromise του Argo CD μπορεί να οδηγήσει σε:
- Πρόσβαση σε private Git repositories και repository credentials.
- Πρόσβαση σε Kubernetes cluster secrets που χρησιμοποιούνται από το Argo CD.
- Manifest generation code execution στο `argocd-repo-server`.
- Μη εξουσιοδοτημένο Kubernetes object deployment μέσω trusted Git repositories, Argo CD applications, ή cache manipulation.
## Αρχιτεκτονική & Ενδιαφέροντα Components
Συνηθισμένα Kubernetes objects και services:
```bash
kubectl get pods,svc,endpoints,ingress -A | grep -iE 'argocd|argo-cd'
kubectl get applications,appprojects,applicationsets -A 2>/dev/null
kubectl get secrets,configmaps -n argocd 2>/dev/null
kubectl get networkpolicy -n argocd 2>/dev/null
```
Ενδιαφέροντες services:
- **`argocd-server`**: public API, web UI, CLI API, authentication and authorization.
- **`argocd-application-controller`**: συγκρίνει το desired και το live state, και μετά εφαρμόζει resources στο Kubernetes.
- **`argocd-repo-server`**: κάνει clone repositories, αποθηκεύει Git data στην cache, και τρέχει Helm/Kustomize/Jsonnet/plugins για να δημιουργήσει manifests. Το default gRPC port είναι **8081**.
- **`argocd-redis`**: cache για application, manifest και Git reference data. Το default Redis port είναι **6379**.
- **`argocd-applicationset-controller`**: δημιουργεί Argo CD `Application` objects από generators όπως Git, SCM, clusters και pull requests.
Από ένα compromised pod ή internal network segment, έλεγξε το internal reachability:
```bash
nc -vz <argocd-server> 443
nc -vz <argocd-repo-server> 8081
nc -vz <argocd-redis> 6379
```
## Public API / UI Attacks
Αν έχετε Argo CD credentials ή ένα exposed instance, ξεκινήστε με το κανονικό API surface:
```bash
argocd login <argocd-server>
argocd account get-user-info
argocd account list
argocd proj list
argocd app list
argocd repo list
argocd cluster list
argocd admin settings rbac can <subject> <action> <resource> <object>
```
Χρήσιμες διαδρομές επίθεσης:
- **Application write access**: τροποποίησε `source.repoURL`, `source.path`, Helm values, Kustomize options, plugin settings ή sync options ώστε το Argo CD να κάνει deploy attacker-controlled manifests.
- **Project misconfiguration**: τα `AppProject` objects μπορούν να επιτρέπουν ευρείς `sourceRepos`, ευρείς `destinations`, μη ασφαλή `clusterResourceWhitelist`, ή αδύναμους περιορισμούς namespace.
- **Repository credential abuse**: repository secrets, GitHub App credentials, SSH keys και tokens μπορούν να επιτρέψουν push σε trusted repos ή την προσθήκη malicious dependencies.
- **Cluster credential abuse**: cluster secrets μπορεί να περιέχουν bearer tokens ή exec-provider configuration που χρησιμοποιούνται από το Argo CD για deploy στα target clusters.
- **Local admin / project tokens**: μακράς διάρκειας Argo CD tokens μπορούν να επαναχρησιμοποιηθούν μέσω του API, εκτός αν ανακληθούν ή λήξουν.
Απαρίθμησε τη διαμόρφωση από Kubernetes όταν έχεις cluster read access:
```bash
kubectl get applications.argoproj.io -A -o yaml
kubectl get appprojects.argoproj.io -A -o yaml
kubectl get applicationsets.argoproj.io -A -o yaml
kubectl get secrets -n argocd -o yaml | grep -nE 'repoURL|sshPrivateKey|password|bearerToken|githubApp|tlsClientCertData|tlsClientCertKey'
kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml
```
## Κατάχρηση Αξιόπιστου Git Repository
Αν μπορείς να κάνεις push σε ένα repository που εμπιστεύεται το Argo CD, συνήθως μπορείς να επηρεάσεις τι γίνεται deployed. Ο αντίκτυπος εξαρτάται από τα όρια του `AppProject` και τα permissions του service account που χρησιμοποιεί ο application controller.
Συνηθισμένες θέσεις για payload:
- Raw Kubernetes YAML κάτω από application path.
- Helm chart templates και `values.yaml`.
- Kustomize overlays, remote bases και generators.
- Jsonnet ή input του config management plugin.
- ApplicationSet generator files που δημιουργούν ή ενημερώνουν `Application` objects.
Έλεγξε αν το app χρησιμοποιεί automated sync, pruning, self-heal, sync windows ή manual approvals:
```bash
kubectl get applications.argoproj.io -A \
-o custom-columns='NS:.metadata.namespace,APP:.metadata.name,PROJECT:.spec.project,AUTOSYNC:.spec.syncPolicy.automated,REPO:.spec.source.repoURL,PATH:.spec.source.path,DEST:.spec.destination.server'
```
## Άμεση κατάχρηση του `argocd-repo-server`
Μην υποθέτετε ότι το δημόσιο Argo CD API είναι η μόνη επιφάνεια επίθεσης. Τα εσωτερικά components του Argo CD επικοινωνούν με το `argocd-repo-server` μέσω gRPC. Αν arbitrary pods μπορούν να φτάσουν το repo-server, τα ελεγχόμενα από τον attacker εσωτερικά requests μπορεί να παρακάμψουν ελέγχους που κανονικά επιβάλλονται από το `argocd-server`.
Practical checks:
```bash
kubectl get svc -n argocd argocd-repo-server -o yaml
kubectl get endpoints -n argocd argocd-repo-server -o wide
nc -vz <argocd-repo-server> 8081
```
Ενδιαφέροντα σημάδια:
- Το repo-server gRPC endpoint είναι προσβάσιμο από μη-Argo CD pods.
- Τα NetworkPolicies λείπουν ή επιτρέπουν μόνο allow-list egress χωρίς να αρνούνται ingress.
- Το repo-server έχει πρόσβαση σε custom config management plugins, decryption tools, ή repository content από πολλαπλούς tenants.
- Το Redis είναι προσβάσιμο από μη-Argo CD pods, επιτρέποντας cache inspection ή tampering αν τα credentials είναι διαθέσιμα ή δεν απαιτούνται.
## Unauthenticated Repo-Server RCE via Kustomize Options
Τον Ιούλιο του 2026, η Synacktiv δημοσίευσε μια unauthenticated chain εκτέλεσης κώδικα στο `repo-server` του Argo CD, όταν ένας attacker μπορεί να φτάσει την internal gRPC service. Η attack εκμεταλλεύεται direct access στο `/repository.RepoServerService/GenerateManifest` και attacker-controlled `KustomizeOptions`.
Το επικίνδυνο primitive είναι να εξαναγκαστεί το repo-server να κάνει clone attacker-controlled repository content και να τρέξει Kustomize με υποστήριξη Helm:
```bash
kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh
```
Ελάχιστο malicious Kustomize input χρειάζεται για να ενεργοποιηθεί η επεξεργασία Helm:
```yaml
helmCharts:
- name: pwn
version: 0.0.1
```
Γιατί αυτό λειτουργεί:
- Το `argocd-repo-server` κλωνοποιεί το repository πριν από το rendering.
- Το `--helm-command ./payload.sh` επιλύεται relative προς το κλωνοποιημένο repository.
- Το code execution δεν απαιτεί shell metacharacter injection αν ο attacker μπορεί να ελέγξει το rendered repository και τα Kustomize build options.
Τη στιγμή της δημοσιοποίησης της Synacktiv στις 1 Ιουλίου 2026, ανέφεραν ότι το issue δεν είχε επίσημο fix ή CVE. Αντιμετώπισέ το πρώτα ως network-exposure issue: το exploitation απαιτεί reachability προς το εσωτερικό repo-server gRPC port.
## Redis Cache Poisoning to Deploy Manifests
Μετά από code execution στο `argocd-repo-server`, ή μετά από direct access στο Redis με valid credentials, εξέτασε τα Redis-backed cache entries. Το Argo CD συνήθως αποθηκεύει gzip-compressed JSON values.
Interesting key prefixes:
```text
mfst|... # cached rendered manifests
git-refs|... # Git branch/ref to commit mappings
app|... # application resource/cache data
cluster|... # cluster cache information
```
Η επίθεση cache poisoning που περιγράφει η Synacktiv εκμεταλλεύεται δύο κομμάτια state:
1. Τροποποίησε το σχετικό `mfst|...` manifest cache entry ώστε να περιλαμβάνει ένα Kubernetes manifest που ελέγχει ο attacker.
2. Τροποποίησε το σχετικό `git-refs|...` mapping ώστε το Argo CD να πιστεύει ότι το branch μετακινήθηκε και μετά να reconciles back to το cached revision.
Επίπτωση:
- Με ενεργοποιημένο Auto Sync, το Argo CD μπορεί να εφαρμόσει αυτόματα το poisoned cached manifest.
- Χωρίς Auto Sync, το payload μπορεί να εφαρμοστεί ακόμα και όταν ένας user κάνει manual sync την application.
- Η τελική επίπτωση περιορίζεται από το destination της target application και τα Kubernetes permissions που είναι διαθέσιμα στο Argo CD.
## ApplicationSet Attacks
Το ApplicationSet είναι ιδιαίτερα ευαίσθητο επειδή δημιουργεί ή ενημερώνει `Application` objects από το generator output.
Review:
```bash
kubectl get applicationsets.argoproj.io -A -o yaml
kubectl get appprojects.argoproj.io -A -o yaml
```
Ενδιαφέροντα patterns:
- Git generators που διαβάζουν attacker-writable αρχεία που ελέγχουν app names, paths, projects ή destinations.
- Pull request generators για δημόσια repositories όπου untrusted contributors μπορούν να επηρεάσουν τα generated applications.
- Template fields που επιτρέπουν broad destination clusters/namespaces.
- AppProjects που επιτρέπουν `sourceRepos: ["*"]` ή broad `destinations`.
- Generated applications που κληρονομούν automated sync και pruning.
## Post-Exploitation
Από ένα Argo CD pod shell, δώσε προτεραιότητα στα εξής:
```bash
env
cat /proc/1/environ 2>/dev/null | tr '\0' '\n'
find /var/run/secrets /app/config -type f -maxdepth 4 2>/dev/null
mount | grep -E 'secret|token|config'
```
Χρήσιμοι στόχοι:
- Κλέψε `REDIS_PASSWORD` ή Redis TLS/client υλικό.
- Εξήγαγε repository credentials από mounted secrets ή Argo CD Kubernetes secrets.
- Εντόπισε cluster credentials που χρησιμοποιούνται από το Argo CD.
- Διάβασε generated manifests και plugin output που μπορεί να περιέχουν injected secrets.
- Έλεγξε αν custom plugins, SOPS, Helm secrets, Vault plugins ή cloud CLIs εκθέτουν decryption keys και cloud credentials.
## Detection & Hardening
Σημαντικοί έλεγχοι:
- Περιορίστε το `argocd-repo-server` port **8081** και το Redis port **6379** με NetworkPolicies ώστε μόνο τα αναμενόμενα Argo CD components να μπορούν να τα προσεγγίσουν.
- Σε Helm deployments, επαληθεύστε ότι τα network policies δημιουργούνται όντως. Τα Argo CD Helm chart values ιστορικά είχαν προεπιλογή το component network policy creation σε disabled.
- Κρατήστε το `argocd-server` ως το authenticated entry point. Εσωτερικές υπηρεσίες δεν πρέπει να είναι reachable από arbitrary workloads.
- Απενεργοποιήστε αχρησιμοποίητα config management tools και plugins.
- Περιορίστε τα `AppProject` `sourceRepos`, `destinations`, namespace permissions και cluster-scoped resources.
- Αποφύγετε την αποθήκευση broad repository credentials όπου ένας low-privileged Argo CD user μπορεί να προκαλέσει επαναχρησιμοποίησή τους.
- Παρακολουθείτε repo-server requests, Kustomize build options, plugin executions, Redis writes και απροσδόκητη πρόσβαση σε `mfst|` / `git-refs|` keys.
- Περιστρέψτε Argo CD local users, project tokens, repository credentials και cluster credentials μετά από compromise.
Χρήσιμες εντολές:
```bash
kubectl get networkpolicy -n argocd
kubectl get networkpolicy -A | grep -i argocd
kubectl describe networkpolicy -n argocd argocd-repo-server-network-policy 2>/dev/null
kubectl describe networkpolicy -n argocd argocd-redis-network-policy 2>/dev/null
```
## Σημείωση Static Analysis: Typed API Requests in CodeQL
Για Go services που χρησιμοποιούν gRPC/REST handlers, τα default CodeQL remote sources μπορεί να χάσουν flows μόλις το raw input έχει unmarshaled σε typed request objects. Ένα χρήσιμο model για Argo CD-style services είναι:
- Receiver type όπως `Server` ή `Service`.
- Πρώτο parameter είναι `context.Context`.
- Δεύτερο parameter είναι ένα typed request object.
Μοντελοποίησε αυτό το δεύτερο parameter ως remote source και πρόσθεσε custom sinks για τα `exec.Command` / `exec.CommandContext` arguments. Αυτό βοηθά να βρεθούν flows από internal API request fields προς command execution helpers.
## References
- [Synacktiv - Caught in the Octopus Trap: Unauthenticated RCE in Argo CD with CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql)
- [Argo CD docs - Security considerations](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/)
- [Argo CD docs - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/)
- [Argo CD docs - repo-server command reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/)
- [Argo CD - repo-server NetworkPolicy manifest](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml)
- [Argo CD docs - metrics](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/)
- [Argo Helm - chart values reference](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md)
- [Kustomize - Helm chart generator example](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md)
@@ -6,51 +6,51 @@
## VCS
Το VCS σημαίνει **Version Control System**, αυτά τα συστήματα επιτρέπουν στους developers να **διαχειρίζονται τον source code τους**. Το πιο συνηθισμένο είναι το **git** και συνήθως θα βρείτε εταιρείες να το χρησιμοποιούν σε μία από τις παρακάτω **platforms**:
VCS σημαίνει **Version Control System**, αυτά τα συστήματα επιτρέπουν στους developers να **διαχειρίζονται τον source code τους**. Το πιο συνηθισμένο είναι το **git** και συνήθως θα βρείτε εταιρείες να το χρησιμοποιούν σε μία από τις ακόλουθες **platforms**:
- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (προσφέρουν τις δικές τους VCS platforms)
- Cloud providers (προσφέρουν τις δικές τους πλατφόρμες VCS)
## CI/CD Pipelines
Τα CI/CD pipelines επιτρέπουν στους developers να **automatize την εκτέλεση code** για διάφορους σκοπούς, συμπεριλαμβανομένων του build, του testing και του deploying applications. Αυτά τα automated workflows **ενεργοποιούνται από συγκεκριμένες ενέργειες**, όπως code pushes, pull requests ή scheduled tasks. Είναι χρήσιμα για να απλοποιούν τη διαδικασία από το development μέχρι το production.
Τα CI/CD pipelines επιτρέπουν στους developers να **αυτοματοποιούν την εκτέλεση code** για διάφορους σκοπούς, όπως build, testing και deploy εφαρμογών. Αυτά τα automated workflows **ενεργοποιούνται από συγκεκριμένες ενέργειες**, όπως code pushes, pull requests ή scheduled tasks. Είναι χρήσιμα για να απλοποιούν τη διαδικασία από development σε production.
Ωστόσο, αυτά τα συστήματα χρειάζεται να **εκτελούνται κάπου** και συνήθως με **privileged credentials για να κάνουν deploy code ή να έχουν access σε sensitive information**.
Ωστόσο, αυτά τα συστήματα πρέπει να **εκτελούνται κάπου** και συνήθως με **privileged credentials για deploy code ή πρόσβαση σε sensitive information**.
## VCS Pentesting Methodology
> [!NOTE]
> Ακόμα κι αν ορισμένες VCS platforms επιτρέπουν τη δημιουργία pipelines, για αυτή την ενότητα θα αναλύσουμε μόνο πιθανά attacks στον έλεγχο του source code.
> Ακόμα κι αν ορισμένες VCS platforms επιτρέπουν τη δημιουργία pipelines για αυτή την ενότητα, θα αναλύσουμε μόνο πιθανές attacks στον έλεγχο του source code.
Platforms που περιέχουν τον source code του project σας περιέχουν sensitive information και οι άνθρωποι πρέπει να είναι πολύ προσεκτικοί με τα permissions που δίνονται μέσα σε αυτή την platform. Αυτά είναι μερικά συνηθισμένα προβλήματα σε VCS platforms που ένας attacker θα μπορούσε να εκμεταλλευτεί:
- **Leaks**: Αν ο code σας περιέχει leaks στα commits και ο attacker μπορεί να έχει access στο repo (επειδή είναι public ή επειδή έχει access), θα μπορούσε να ανακαλύψει τα leaks.
- **Access**: Αν ένας attacker μπορεί να **έχει access σε έναν account μέσα στην VCS platform** θα μπορούσε να αποκτήσει **περισσότερη ορατότητα και permissions**.
- **Register**: Ορισμένες platforms απλώς επιτρέπουν σε external users να δημιουργήσουν account.
- **SSO**: Ορισμένες platforms δεν επιτρέπουν στους users να κάνουν register, αλλά επιτρέπουν σε οποιονδήποτε να έχει access με έγκυρο SSO (οπότε ένας attacker θα μπορούσε να χρησιμοποιήσει τον github account του για να μπει, για παράδειγμα).
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... υπάρχουν διάφοροι τύποι tokens που ένας user θα μπορούσε να κλέψει για να έχει access με κάποιον τρόπο σε ένα repo.
- **Webhooks**: Οι VCS platforms επιτρέπουν τη δημιουργία webhooks. Αν δεν είναι **προστατευμένα** με non visible secrets, ένας **attacker θα μπορούσε να τα εκμεταλλευτεί**.
- Αν δεν υπάρχει secret, ο attacker θα μπορούσε να εκμεταλλευτεί το webhook της third party platform
- Αν το secret βρίσκεται στο URL, συμβαίνει το ίδιο και ο attacker έχει επίσης το secret
- **Code compromise:** Αν ένας malicious actor έχει κάποιο είδος **write** access στα repos, θα μπορούσε να προσπαθήσει να **inject malicious code**. Για να πετύχει ίσως χρειαστεί να **bypass branch protections**. Αυτές οι ενέργειες μπορούν να γίνουν με διαφορετικούς στόχους στο νου:
- **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 the pipeline** (δείτε την επόμενη ενότητα)
- 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 **pulls the code** από το επιλεγμένο source (π.χ. commit / branch) και **εκτελεί τις commands που ορίζονται στο CI configuration file** πάνω σε αυτό το code.
Ο πιο συνηθισμένος τρόπος να οριστεί ένα 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. Δείτε:
> Ορισμένοι hosted builders επιτρέπουν στους contributors να επιλέξουν το Docker build context και το Dockerfile path. Αν το context ελέγχεται από attacker, μπορείτε να το ορίσετε εκτός του repo (π.χ. "..") ώστε να γίνει ingest host files κατά το build και να exfiltrate secrets. Δείτε:
>
>{{#ref}}
>docker-build-context-abuse.md
@@ -58,67 +58,68 @@ Platforms που περιέχουν τον source code του project σας π
### 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. Αυτό «poisons» το CI pipeline, οδηγώντας στην εκτέλεση αυτών των malicious commands.
Το 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 πρέπει να μπορεί να:
Για να είναι επιτυχής ένας malicious actor σε μια PPE attack, χρειάζεται να μπορεί να:
- Να έχει **write access to the VCS platform**, καθώς συνήθως τα pipelines ενεργοποιούνται όταν γίνεται ένα push ή ένα pull request. (Δείτε το VCS pentesting methodology για σύνοψη τρόπων απόκτησης access).
- Σημειώστε ότι κάποιες φορές ένα **external PR count as "write access"**.
- Ακόμα κι αν έχει write permissions, πρέπει να είναι σίγουρος ότι μπορεί να **modify the CI config file or other files the config is relying on**.
- Για αυτό, ίσως χρειαστεί να μπορεί να **bypass branch protections**.
- Να έχει **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 **modifies το CI config** file που πρόκειται να εκτελεστεί.
- **I-DDE**: Ένα **Indirect PPE** attack συμβαίνει όταν ο actor **modifies** ένα **file** στο οποίο βασίζεται το CI config file που πρόκειται να εκτελεστεί **relays on** (όπως ένα make file ή ένα terraform config).
- **Public PPE or 3PE**: Σε ορισμένες περιπτώσεις τα pipelines μπορούν να **triggered by users that doesn't have write access in the repo** (και που μπορεί να μην είναι καν μέρος του org) επειδή μπορούν να στείλουν ένα PR.
- **3PE Command Injection**: Συνήθως, τα CI/CD pipelines θα **set environment variables** με **information about the PR**. Αν αυτή η τιμή μπορεί να ελεγχθεί από έναν attacker (όπως ο τίτλος του PR) και **χρησιμοποιείται** σε ένα **dangerous place** (όπως η εκτέλεση **sh commands**), ένας attacker μπορεί να **inject commands in there**.
- **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 a pipeline, ας δούμε τι θα μπορούσε να αποκτήσει ένας attacker μετά από επιτυχημένο exploitation:
Γνωρίζοντας τις 3 flavours για να poison ένα pipeline, ας δούμε τι θα μπορούσε να αποκτήσει ένας attacker μετά από επιτυχημένη exploitation:
- **Secrets**: Όπως αναφέρθηκε προηγουμένως, τα pipelines απαιτούν **privileges** για τα jobs τους (retrieve τον code, build it, deploy it...) και αυτά τα privileges συνήθως **δίνονται σε secrets**. Αυτά τα secrets είναι συνήθως προσβάσιμα μέσω **env variables ή files μέσα στο system**. Επομένως ένας attacker θα προσπαθεί πάντα να exfiltrate όσο το δυνατόν περισσότερα secrets.
- Ανάλογα με την pipeline platform ο attacker **might need to specify the secrets in the config**. Αυτό σημαίνει ότι αν ο attacker δεν μπορεί να modify το CI configuration pipeline (**I-PPE** για παράδειγμα), θα μπορούσε να **μόνο exfiltrate τα secrets που έχει εκείνο το pipeline**.
- **Computation**: Ο code εκτελείται κάπου, ανάλογα με το πού εκτελείται ένας attacker ίσως μπορέσει να pivot further.
- **On-Premises**: Αν τα pipelines εκτελούνται on premises, ένας attacker ίσως καταλήξει σε ένα **internal network με access σε περισσότερους πόρους**.
- **Cloud**: Ο attacker θα μπορούσε να έχει access σε **other machines in the cloud** αλλά επίσης θα μπορούσε να **exfiltrate** IAM roles/service accounts **tokens** από εκεί για να αποκτήσει **further access inside the cloud**.
- **Platforms machine**: Μερικές φορές τα jobs θα εκτελούνται μέσα στις **pipelines platform machines**, οι οποίες συνήθως βρίσκονται μέσα σε ένα cloud χωρίς **more access**.
- **Select it:** Μερικές φορές η **pipelines platform θα έχει ρυθμίσει several machines** και αν μπορείτε να **modify the CI configuration file** μπορείτε να **indicate where you want to run the malicious code**. Σε αυτή την κατάσταση, ένας attacker πιθανότατα θα τρέξει ένα reverse shell σε κάθε πιθανή machine για να προσπαθήσει να την εκμεταλλευτεί περαιτέρω.
- **Compromise production**: Αν βρεθείτε μέσα στο pipeline και η τελική version χτίζεται και deploys από αυτό, θα μπορούσατε να **compromise το code που πρόκειται να καταλήξει να τρέχει in production**.
- **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
Το compromising ενός CI/CD pipeline ή το stealing credentials από αυτό μπορεί να επιτρέψει σε έναν attacker να μετακινηθεί από την **pipeline execution** σε **ecosystem-wide code execution** backdooring dependencies ή release tooling:
Το compromise ενός CI/CD pipeline ή το κλέψιμο credentials από αυτό μπορεί να επιτρέψει σε έναν attacker να μετακινηθεί από την **pipeline execution** σε **ecosystem-wide code execution** backdooring dependencies ή release tooling:
- **Install-time code execution via package hooks**: publish μια package version που προσθέτει `preinstall`, `postinstall`, `prepare` ή παρόμοια hooks ώστε το payload να εκτελείται αυτόματα σε developer workstations και CI runners κατά το dependency installation.
- **Secondary execution paths**: ακόμα κι αν οι targets κάνουν install με `--ignore-scripts`, ένα malicious package μπορεί παρ όλα αυτά να καταχωρήσει ένα **common CLI name** στο `bin` field έτσι ώστε το attacker-controlled wrapper να γίνει symlinked μέσα στο `PATH` και να εκτελεστεί αργότερα όταν χρησιμοποιηθεί η command.
- **Runtime bootstrapping**: ένα μικρό installer μπορεί να κατεβάσει ένα δεύτερο runtime ή toolchain κατά την installation (για παράδειγμα 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. Αν το κάνουν, απαριθμήστε writable packages, κατεβάστε τα tarballs τους, inject ένα loader όπως `setup.mjs`, ορίστε `preinstall` ώστε να το εκτελεί, αυξήστε το patch version και republish. Αυτό μετατρέπει ένα CI compromise σε downstream auto-execution σε άλλα environments.
- **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.
- Ελέγξτε το 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.
- Αναζητήστε unexpected package-manager execution μέσα στο CI όπως `npm install` αντί για `npm ci`, unexpected Bun downloads/execution ή νέα workflow artifacts που παράγονται από transient branches.
- Αν υπάρχει υποψία για 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](argocd-security.md).
## More relevant info
### Tools & CIS Benchmark
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) είναι ένα open-source tool για auditing του software supply chain stack σας για security compliance με βάση ένα νέο [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Το auditing επικεντρώνεται σε ολόκληρη τη διαδικασία SDLC, όπου μπορεί να αποκαλύψει risks από code time έως deploy time.
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) είναι ένα open-source tool για auditing του software supply chain stack σας ως προς security compliance, με βάση ένα νέο [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Το 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/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
Δείτε αυτό το ενδιαφέρον άρθρο για τα top 10 CI/CD risks σύμφωνα με το Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
### Labs
- Σε κάθε platform που μπορείτε να τρέξετε locally θα βρείτε πώς να το launch locally ώστε να μπορείτε να το ρυθμίσετε όπως θέλετε για να το test it
- Σε κάθε platform που μπορείτε να τρέξετε locally θα βρείτε πώς να την εκκινήσετε locally ώστε να τη ρυθμίσετε όπως θέλετε για να τη δοκιμάσετε
- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
### Automatic Tools