Basic Github Information
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Η βασική δομή του περιβάλλοντος github μιας μεγάλης εταιρείας είναι να κατέχει μια επιχείρηση που κατέχει πολλές οργανώσεις και η κάθε μία από αυτές μπορεί να περιέχει πολλούς αποθετηρίους και πολλές ομάδες. Οι μικρότερες εταιρείες μπορεί να κατέχουν μόνο μία οργάνωση και καμία επιχείρηση.
Από την οπτική γωνία ενός χρήστη, ένας χρήστης μπορεί να είναι μέλος διαφορετικών επιχειρήσεων και οργανώσεων. Μέσα σε αυτές, ο χρήστης μπορεί να έχει διαφορετικούς ρόλους επιχείρησης, οργάνωσης και αποθετηρίου.
Επιπλέον, ένας χρήστης μπορεί να είναι μέλος διαφορετικών ομάδων με διαφορετικούς ρόλους επιχείρησης, οργάνωσης ή αποθετηρίου.
Και τέλος, οι αποθετήριοι μπορεί να έχουν ειδικούς μηχανισμούς προστασίας.
Enterprise owner: Άτομα με αυτόν τον ρόλο μπορούν να διαχειρίζονται διαχειριστές, να διαχειρίζονται οργανώσεις εντός της επιχείρησης, να διαχειρίζονται ρυθμίσεις επιχείρησης, να επιβάλλουν πολιτική σε οργανώσεις. Ωστόσο, δεν μπορούν να έχουν πρόσβαση στις ρυθμίσεις ή το περιεχόμενο της οργάνωσης εκτός αν γίνουν ιδιοκτήτες της οργάνωσης ή τους δοθεί άμεση πρόσβαση σε αποθετήριο που ανήκει στην οργάνωση.
Enterprise members: Τα μέλη των οργανώσεων που ανήκουν στην επιχείρησή σας είναι επίσης αυτόματα μέλη της επιχείρησης.
Σε μια οργάνωση, οι χρήστες μπορούν να έχουν διαφορετικούς ρόλους:
Organization owners: Οι ιδιοκτήτες οργανώσεων έχουν πλήρη διοικητική πρόσβαση στην οργάνωσή σας. Αυτός ο ρόλος θα πρέπει να είναι περιορισμένος, αλλά όχι λιγότεροι από δύο άτομα, στην οργάνωσή σας.
Organization members: Ο προεπιλεγμένος, μη διοικητικός ρόλος για άτομα σε μια οργάνωση είναι το μέλος της οργάνωσης. Από προεπιλογή, τα μέλη της οργάνωσης έχουν έναν αριθμό δικαιωμάτων.
Billing managers: Οι διαχειριστές χρέωσης είναι χρήστες που μπορούν να διαχειρίζονται τις ρυθμίσεις χρέωσης για την οργάνωσή σας, όπως πληροφορίες πληρωμής.
Security Managers: Είναι ένας ρόλος που οι ιδιοκτήτες οργανώσεων μπορούν να αναθέσουν σε οποιαδήποτε ομάδα σε μια οργάνωση. Όταν εφαρμοστεί, δίνει σε κάθε μέλος της ομάδας δικαιώματα να διαχειρίζεται τις ειδοποιήσεις και τις ρυθμίσεις ασφαλείας σε όλη την οργάνωσή σας, καθώς και δικαιώματα ανάγνωσης για όλους τους αποθετηρίους στην οργάνωση.
Αν η οργάνωσή σας έχει μια ομάδα ασφαλείας, μπορείτε να χρησιμοποιήσετε τον ρόλο του διαχειριστή ασφαλείας για να δώσετε στα μέλη της ομάδας την ελάχιστη πρόσβαση που χρειάζονται στην οργάνωση.
Github App managers: Για να επιτρέψετε σε επιπλέον χρήστες να διαχειρίζονται τις εφαρμογές GitHub που ανήκουν σε μια οργάνωση, ένας ιδιοκτήτης μπορεί να τους χορηγήσει δικαιώματα διαχειριστή εφαρμογών GitHub.
Outside collaborators: Ένας εξωτερικός συνεργάτης είναι ένα άτομο που έχει πρόσβαση σε έναν ή περισσότερους αποθετηρίους οργανώσεων αλλά δεν είναι ρητά μέλος της οργάνωσης.
Μπορείτε να συγκρίνετε τα δικαιώματα αυτών των ρόλων σε αυτόν τον πίνακα: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles
Στο https://github.com/organizations/<org_name>/settings/member_privileges μπορείτε να δείτε τα δικαιώματα που θα έχουν οι χρήστες απλώς και μόνο επειδή είναι μέλη της οργάνωσης.
Οι ρυθμίσεις που έχουν ρυθμιστεί εδώ θα υποδεικνύουν τα εξής δικαιώματα των μελών της οργάνωσης:
Να είναι διαχειριστής, συγγραφέας, αναγνώστης ή χωρίς δικαιώματα σε όλους τους αποθετηρίους της οργάνωσης.
Αν τα μέλη μπορούν να δημιουργούν ιδιωτικούς, εσωτερικούς ή δημόσιους αποθετηρίους.
Αν είναι δυνατή η δημιουργία fork αποθετηρίων.
Αν είναι δυνατή η πρόσκληση εξωτερικών συνεργατών.
Αν μπορούν να δημοσιευτούν δημόσιες ή ιδιωτικές τοποθεσίες.
Τα δικαιώματα που έχουν οι διαχειριστές στους αποθετηρίους.
Αν τα μέλη μπορούν να δημιουργούν νέες ομάδες.
Από προεπιλογή, οι ρόλοι αποθετηρίου δημιουργούνται:
Read: Συνιστάται για μη κωδικοποιητές που θέλουν να δουν ή να συζητήσουν το έργο σας.
Triage: Συνιστάται για συνεργάτες που χρειάζονται να διαχειρίζονται ενεργά ζητήματα και αιτήματα έλξης χωρίς δικαιώματα εγγραφής.
Write: Συνιστάται για συνεργάτες που σπρώχνουν ενεργά στο έργο σας.
Maintain: Συνιστάται για διαχειριστές έργων που χρειάζονται να διαχειρίζονται το αποθετήριο χωρίς πρόσβαση σε ευαίσθητες ή καταστροφικές ενέργειες.
Admin: Συνιστάται για άτομα που χρειάζονται πλήρη πρόσβαση στο έργο, συμπεριλαμβανομένων ευαίσθητων και καταστροφικών ενεργειών όπως η διαχείριση ασφαλείας ή η διαγραφή ενός αποθετηρίου.
Μπορείτε να συγκρίνετε τα δικαιώματα κάθε ρόλου σε αυτόν τον πίνακα https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role
Μπορείτε επίσης να δημιουργήσετε τους δικούς σας ρόλους στο https://github.com/organizations/<org_name>/settings/roles
Μπορείτε να καταγράψετε τις ομάδες που έχουν δημιουργηθεί σε μια οργάνωση στο https://github.com/orgs/<org_name>/teams. Σημειώστε ότι για να δείτε τις ομάδες που είναι παιδιά άλλων ομάδων, πρέπει να αποκτήσετε πρόσβαση σε κάθε γονική ομάδα.
Οι χρήστες μιας οργάνωσης μπορούν να καταγραφούν στο https://github.com/orgs/<org_name>/people.
Στις πληροφορίες κάθε χρήστη μπορείτε να δείτε τις ομάδες στις οποίες είναι μέλος ο χρήστης, και τους αποθετηρίους στους οποίους έχει πρόσβαση ο χρήστης.
Το Github προσφέρει διαφορετικούς τρόπους για να αυθεντικοποιηθείτε στον λογαριασμό σας και να εκτελέσετε ενέργειες εκ μέρους σας.
Αποκτώντας πρόσβαση στο github.com, μπορείτε να συνδεθείτε χρησιμοποιώντας το όνομα χρήστη και τον κωδικό πρόσβασης (και μια 2FA ενδεχομένως).
Μπορείτε να ρυθμίσετε τον λογαριασμό σας με ένα ή περισσότερα δημόσια κλειδιά που επιτρέπουν στο σχετικό ιδιωτικό κλειδί να εκτελεί ενέργειες εκ μέρους σας. https://github.com/settings/keys
Δεν μπορείτε να προσποιηθείτε τον χρήστη με αυτά τα κλειδιά, αλλά αν δεν τα χρησιμοποιείτε, μπορεί να είναι δυνατό να ανακαλυφθείτε στέλνοντας commits χωρίς υπογραφή. Μάθετε περισσότερα για την προσεκτική λειτουργία εδώ.
Μπορείτε να δημιουργήσετε προσωπικό διακριτικό πρόσβασης για να δώσετε σε μια εφαρμογή πρόσβαση στον λογαριασμό σας. Όταν δημιουργείτε ένα προσωπικό διακριτικό πρόσβασης, ο χρήστης πρέπει να καθορίσει τα δικαιώματα που θα έχει το διακριτικό. https://github.com/settings/tokens
Οι εφαρμογές Oauth μπορεί να σας ζητήσουν δικαιώματα για να αποκτήσουν πρόσβαση σε μέρος των πληροφοριών σας στο github ή να σας προσποιηθούν για να εκτελέσουν ορισμένες ενέργειες. Ένα κοινό παράδειγμα αυτής της λειτουργικότητας είναι το κουμπί σύνδεσης με το github που μπορεί να βρείτε σε ορισμένες πλατφόρμες.
Μπορείτε να δημιουργήσετε τις δικές σας εφαρμογές Oauth στο https://github.com/settings/developers
Μπορείτε να δείτε όλες τις εφαρμογές Oauth που έχουν πρόσβαση στον λογαριασμό σας στο https://github.com/settings/applications
Μπορείτε να δείτε τις σκοπούς που μπορούν να ζητήσουν οι εφαρμογές Oauth στο https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps
Μπορείτε να δείτε την πρόσβαση τρίτων εφαρμογών σε μια οργάνωση στο https://github.com/organizations/<org_name>/settings/oauth_application_policy
Ορισμένες συστάσεις ασφαλείας:
Μια Εφαρμογή OAuth θα πρέπει πάντα να ενεργεί ως ο αυθεντικοποιημένος χρήστης GitHub σε όλο το GitHub (για παράδειγμα, όταν παρέχει ειδοποιήσεις χρηστών) και με πρόσβαση μόνο στους καθορισμένους σκοπούς.
Μια Εφαρμογή OAuth μπορεί να χρησιμοποιηθεί ως πάροχος ταυτότητας ενεργοποιώντας μια "Σύνδεση με το GitHub" για τον αυθεντικοποιημένο χρήστη.
Μην δημιουργείτε μια Εφαρμογή OAuth αν θέλετε η εφαρμογή σας να ενεργεί σε ένα μόνο αποθετήριο. Με το repo OAuth scope, οι Εφαρμογές OAuth μπορούν να ενεργούν σε όλα** τα αποθετήρια του αυθεντικοποιημένου χρήστη**.
Μην δημιουργείτε μια Εφαρμογή OAuth για να ενεργεί ως εφαρμογή για την ομάδα ή την εταιρεία σας. Οι Εφαρμογές OAuth αυθεντικοποιούνται ως ένας μόνο χρήστης, οπότε αν ένα άτομο δημιουργήσει μια Εφαρμογή OAuth για να τη χρησιμοποιήσει μια εταιρεία και στη συνέχεια φύγει από την εταιρεία, κανείς άλλος δεν θα έχει πρόσβαση σε αυτήν.
Περισσότερα εδώ here.
Οι εφαρμογές Github μπορούν να ζητήσουν δικαιώματα για να αποκτήσουν πρόσβαση στις πληροφορίες σας στο github ή να σας προσποιηθούν για να εκτελέσουν συγκεκριμένες ενέργειες σε συγκεκριμένους πόρους. Στις Εφαρμογές Github πρέπει να καθορίσετε τους αποθετηρίους στους οποίους θα έχει πρόσβαση η εφαρμογή.
Για να εγκαταστήσετε μια Εφαρμογή GitHub, πρέπει να είστε ιδιοκτήτης οργάνωσης ή να έχετε δικαιώματα διαχειριστή σε ένα αποθετήριο.
Η Εφαρμογή GitHub θα πρέπει να συνδεθεί με έναν προσωπικό λογαριασμό ή μια οργάνωση.
Μπορείτε να δημιουργήσετε τη δική σας εφαρμογή Github στο https://github.com/settings/apps
Μπορείτε να δείτε όλες τις εφαρμογές Github που έχουν πρόσβαση στον λογαριασμό σας στο https://github.com/settings/apps/authorizations
Αυτές είναι οι API Endpoints για τις Εφαρμογές Github https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. Ανάλογα με τα δικαιώματα της Εφαρμογής, θα μπορεί να έχει πρόσβαση σε ορισμένες από αυτές.
Μπορείτε να δείτε τις εγκατεστημένες εφαρμογές σε μια οργάνωση στο https://github.com/organizations/<org_name>/settings/installations
Ορισμένες συστάσεις ασφαλείας:
Μια Εφαρμογή GitHub θα πρέπει να λαμβάνει ενέργειες ανεξάρτητα από έναν χρήστη (εκτός αν η εφαρμογή χρησιμοποιεί ένα token χρήστη προς διακομιστή). Για να διατηρήσετε τα tokens πρόσβασης χρήστη προς διακομιστή πιο ασφαλή, μπορείτε να χρησιμοποιήσετε tokens πρόσβασης που θα λήγουν μετά από 8 ώρες και ένα refresh token που μπορεί να ανταλλαγεί για ένα νέο token πρόσβασης. Για περισσότερες πληροφορίες, δείτε "Ανανέωση tokens πρόσβασης χρήστη προς διακομιστή."
Βεβαιωθείτε ότι η Εφαρμογή GitHub ενσωματώνεται με συγκεκριμένους αποθετηρίους.
Η Εφαρμογή GitHub θα πρέπει να συνδεθεί με έναν προσωπικό λογαριασμό ή μια οργάνωση.
Μην περιμένετε από την Εφαρμογή GitHub να γνωρίζει και να κάνει τα πάντα που μπορεί να κάνει ένας χρήστης.
Μην χρησιμοποιείτε μια Εφαρμογή GitHub αν χρειάζεστε απλώς μια υπηρεσία "Σύνδεση με το GitHub". Αλλά μια Εφαρμογή GitHub μπορεί να χρησιμοποιήσει μια ροή ταυτοποίησης χρήστη για να συνδέσει τους χρήστες και να κάνει άλλες ενέργειες.
Μην δημιουργείτε μια Εφαρμογή GitHub αν μόνο θέλετε να ενεργείτε ως χρήστης GitHub και να κάνετε τα πάντα που μπορεί να κάνει αυτός ο χρήστης.
Εάν χρησιμοποιείτε την εφαρμογή σας με τις GitHub Actions και θέλετε να τροποποιήσετε τα αρχεία ροής εργασίας, πρέπει να αυθεντικοποιηθείτε εκ μέρους του χρήστη με ένα token OAuth που περιλαμβάνει το workflow scope. Ο χρήστης πρέπει να έχει δικαιώματα διαχειριστή ή εγγραφής στο αποθετήριο που περιέχει το αρχείο ροής εργασίας. Για περισσότερες πληροφορίες, δείτε "Κατανόηση των σκοπών για τις εφαρμογές OAuth."
Περισσότερα εδώ here.
Αυτό δεν είναι τρόπος αυθεντικοποίησης στο github, αλλά μια κακόβουλη ενέργεια Github θα μπορούσε να αποκτήσει μη εξουσιοδοτημένη πρόσβαση στο github και ανάλογα με τα δικαιώματα που δίνονται στην ενέργεια, θα μπορούσαν να γίνουν αρκετές διαφορετικές επιθέσεις. Δείτε παρακάτω για περισσότερες πληροφορίες.
Οι ενέργειες Git επιτρέπουν την αυτοματοποίηση της εκτέλεσης κώδικα όταν συμβαίνει ένα γεγονός. Συνήθως, ο εκτελούμενος κώδικας είναι κάπως σχετικός με τον κώδικα του αποθετηρίου (ίσως να δημιουργήσει ένα κοντέινερ docker ή να ελέγξει ότι το PR δεν περιέχει μυστικά).
Στο https://github.com/organizations/<org_name>/settings/actions είναι δυνατό να ελέγξετε τη ρύθμιση των ενεργειών github για την οργάνωση.
Είναι δυνατό να απαγορευτεί η χρήση των ενεργειών github εντελώς, να επιτραπούν όλες οι ενέργειες github, ή να επιτραπούν μόνο ορισμένες ενέργειες.
Είναι επίσης δυνατό να ρυθμίσετε ποιος χρειάζεται έγκριση για να εκτελέσει μια Ενέργεια Github και τα δικαιώματα του GITHUB_TOKEN μιας Ενέργειας Github όταν εκτελείται.
Οι Ενέργειες Github συνήθως χρειάζονται κάποιο είδος μυστικών για να αλληλεπιδράσουν με το github ή τρίτες εφαρμογές. Για να αποφύγετε να τα βάλετε σε καθαρό κείμενο στο αποθετήριο, το github επιτρέπει να τα βάλετε ως Μυστικά.
Αυτά τα μυστικά μπορούν να ρυθμιστούν για το αποθετήριο ή για όλη την οργάνωση. Στη συνέχεια, προκειμένου η Ενέργεια να μπορεί να έχει πρόσβαση στο μυστικό, πρέπει να το δηλώσετε ως εξής:
Τα μυστικά μπορούν να προσπελαστούν μόνο από τις Github Actions που τα έχουν δηλωμένα.
Μόλις ρυθμιστούν στο repo ή στις οργανώσεις, οι χρήστες του github δεν θα μπορούν να τα προσπελάσουν ξανά, θα μπορούν μόνο να τα αλλάξουν.
Επομένως, ο μόνος τρόπος να κλέψετε τα μυστικά του github είναι να μπορείτε να έχετε πρόσβαση στη μηχανή που εκτελεί την Github Action (σε αυτή την περίπτωση θα μπορείτε να έχετε πρόσβαση μόνο στα μυστικά που έχουν δηλωθεί για την Action).
Το Github επιτρέπει τη δημιουργία περιβαλλόντων όπου μπορείτε να αποθηκεύσετε μυστικά. Στη συνέχεια, μπορείτε να δώσετε στην github action πρόσβαση στα μυστικά μέσα στο περιβάλλον με κάτι σαν:
You can configure an environment to be accessed by όλα τα branches (default), μόνο προστατευμένα branches or specify which branches can access it. It can also set a number of required reviews before executing an action using an environment or wait some time before allowing deployments to proceed.
A Github Action can be executed inside the github environment or can be executed in a third party infrastructure configured by the user.
Several organizations will allow to run Github Actions in a third party infrastructure as it use to be φθηνότερο.
You can list the self-hosted runners of an organization in https://github.com/organizations/<org_name>/settings/actions/runners
The way to find which Github Actions are being executed in non-github infrastructure is to search for runs-on: self-hosted in the Github Action configuration yaml.
It's not possible to run a Github Action of an organization inside a self hosted box of a different organization because a unique token is generated for the Runner when configuring it to know where the runner belongs.
If the custom Github Runner is configured in a machine inside AWS or GCP for example, the Action could have access to the metadata endpoint and steal the token of the service account the machine is running with.
If all actions (or a malicious action) are allowed a user could use a Github action that is malicious and will compromise the container where it's being executed.
A malicious Github Action run could be abused by the attacker to:
Steal all the secrets the Action has access to
Move laterally if the Action is executed inside a third party infrastructure where the SA token used to run the machine can be accessed (probably via the metadata service)
Abuse the token used by the workflow to steal the code of the repo where the Action is executed or even modify it.
Branch protections are designed to not give complete control of a repository to the users. The goal is to put several protection methods before being able to write code inside some branch.
The branch protections of a repository can be found in https://github.com/<orgname>/<reponame>/settings/branches
It's not possible to set a branch protection at organization level. So all of them must be declared on each repo.
Different protections can be applied to a branch (like to master):
You can require a PR before merging (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
Require a number of approvals. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
Dismiss approvals when new commits are pushed. If not, a user may approve legit code and then the user could add malicious code and merge it.
Require reviews from Code Owners. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
Restrict who can dismiss pull request reviews. You can specify people or teams allowed to dismiss pull request reviews.
Allow specified actors to bypass pull request requirements. These users will be able to bypass previous restrictions.
Require status checks to pass before merging. Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret).
Require conversation resolution before merging. All comments on the code needs to be resolved before the PR can be merged.
Require signed commits. The commits need to be signed.
Require linear history. Prevent merge commits from being pushed to matching branches.
Include administrators. If this isn't set, admins can bypass the restrictions.
Restrict who can push to matching branches. Restrict who can send a PR.
As you can see, even if you managed to obtain some credentials of a user, repos might be protected avoiding you to pushing code to master for example to compromise the CI/CD pipeline.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
