Βασικές πληροφορίες για το Github

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Μάθετε & εξασκηθείτε στο Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks

Βασική δομή

Η βασική δομή του περιβάλλοντος του github σε μια μεγάλη company είναι να έχει ένα enterprise το οποίο κατέχει several organizations και η καθεμία από αυτές μπορεί να περιέχει several repositories και several teams.. Μικρότερες εταιρείες μπορεί να έχουν απλώς own one organization and no enterprises.

Από την πλευρά του χρήστη, ένας user μπορεί να είναι member διαφορετικών enterprises and organizations. Μέσα σε αυτές ο χρήστης μπορεί να έχει different enterprise, organization and repository roles.

Επιπλέον, ένας χρήστης μπορεί να είναι part of different teams με διαφορετικούς enterprise, organization ή repository ρόλους.

Και τέλος, repositories may have special protection mechanisms.

Προνόμια

Ρόλοι Enterprise

  • Enterprise owner: Άτομα με αυτόν τον ρόλο μπορούν να manage administrators, manage organizations within the enterprise, manage enterprise settings, enforce policy across organizations. Ωστόσο, cannot access organization settings or content εκτός αν γίνουν organization owner ή τους δοθεί άμεση πρόσβαση σε ένα repository που ανήκει στην οργάνωση.
  • Enterprise members: Τα μέλη των οργανώσεων που ανήκουν στο enterprise σας είναι automatically members of the enterprise.

Ρόλοι Organization

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

  • Organization owners: Οι organization owners έχουν complete administrative access to your organization. Αυτός ο ρόλος πρέπει να περιορίζεται, αλλά να υπάρχει σε όχι λιγότερα από δύο άτομα στην οργάνωσή σας.
  • Organization members: Ο default, μη-διοικητικός ρόλος για people in an organization είναι ο organization member. Από προεπιλογή, τα organization members have a number of permissions.
  • Billing managers: Οι billing managers είναι χρήστες που μπορούν να manage the billing settings for your organization, όπως τα στοιχεία πληρωμής.
  • Security Managers: Είναι ένας ρόλος που οι organization owners μπορούν να αναθέσουν σε οποιαδήποτε ομάδα στην οργάνωση. Όταν εφαρμοστεί, δίνει σε κάθε μέλος της ομάδας άδειες για manage security alerts and settings across your organization, as well as read permissions for all repositories στην οργάνωση.
  • Αν η οργάνωσή σας έχει security team, μπορείτε να χρησιμοποιήσετε τον ρόλο security manager για να δώσετε στα μέλη της ομάδας την ελάχιστη πρόσβαση που χρειάζονται στην οργάνωση.
  • Github App managers: Για να επιτρέψετε σε επιπλέον χρήστες να manage GitHub Apps owned by an organization, ένας owner μπορεί να τους δώσει GitHub App manager permissions.
  • Outside collaborators: Ένας outside collaborator είναι ένα άτομο που έχει access to one or more organization repositories but is not explicitly a member της οργάνωσης.

Μπορείτε να compare the permissions αυτών των ρόλων σε αυτόν τον πίνακα: 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 μπορείτε να δείτε τις permissions users will have just for being part of the organisation.

Οι ρυθμίσεις που έχουν διαμορφωθεί εδώ θα υποδεικνύουν τις ακόλουθες άδειες των μελών της οργάνωσης:

  • Να είναι admin, writer, reader ή να μην έχουν καμία άδεια σε όλα τα organisation repos.
  • Αν τα μέλη μπορούν να δημιουργούν private, internal ή public repositories.
  • Αν είναι δυνατό το forking των repositories.
  • Αν είναι δυνατό να προσκαλούνται outside collaborators.
  • Αν μπορούν να δημοσιευτούν public ή private sites.
  • Τις άδειες που έχουν οι admins πάνω στα repositories.
  • Αν τα μέλη μπορούν να δημιουργούν νέες teams.

Ρόλοι Repository

Από προεπιλογή δημιουργούνται οι εξής repository roles:

  • Read: Συνιστάται για non-code contributors που θέλουν να βλέπουν ή να σχολιάζουν το project σας
  • Triage: Συνιστάται για contributors who need to proactively manage issues and pull requests χωρίς write access
  • Write: Συνιστάται για contributors που actively push to your project
  • Maintain: Συνιστάται για project managers who need to manage the repository χωρίς πρόσβαση σε ευαίσθητες ή καταστροφικές ενέργειες
  • Admin: Συνιστάται για άτομα που χρειάζονται full access to the project, συμπεριλαμβανομένων ευαίσθητων και καταστροφικών ενεργειών όπως το manage security ή το delete a repository

Μπορείτε να compare the permissions κάθε ρόλου σε αυτόν τον πίνακα https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role

Μπορείτε επίσης να create your own roles στο https://github.com/organizations/<org_name>/settings/roles

Teams

Μπορείτε να list the teams created in an organization στο https://github.com/orgs/<org_name>/teams. Σημειώστε ότι για να δείτε τις teams που είναι children άλλων teams πρέπει να έχετε πρόσβαση σε κάθε parent team.

Users

Οι χρήστες μιας οργάνωσης μπορούν να listed στο https://github.com/orgs/<org_name>/people.

Στις πληροφορίες κάθε χρήστη μπορείτε να δείτε τις teams the user is member of, και τα repos the user has access to.

Github Authentication

Το Github προσφέρει διαφορετικούς τρόπους για να πιστοποιηθείτε στον λογαριασμό σας και να εκτελέσετε ενέργειες εξ ονόματός σας.

Web Access

Συνδεόμενοι στο github.com μπορείτε να κάνετε login χρησιμοποιώντας το username and password (και πιθανώς 2FA).

SSH Keys

Μπορείτε να ρυθμίσετε τον λογαριασμό σας με ένα ή περισσότερα public keys επιτρέποντας στο σχετικό private key να εκτελεί ενέργειες εξ ονόματός σας. https://github.com/settings/keys

GPG Keys

Δεν μπορείτε να impersonate τον χρήστη με αυτά τα keys, αλλά αν δεν τα χρησιμοποιείτε μπορεί να είναι πιθανό να get discover for sending commits without a signature. Learn more about vigilant mode here.

Personal Access Tokens

Μπορείτε να δημιουργήσετε personal access token για να give an application access to your account. Όταν δημιουργείται ένα personal access token ο user πρέπει να specify τα permissions που το token θα έχει. https://github.com/settings/tokens

Oauth Applications

Οι Oauth applications μπορεί να σας ζητήσουν άδειες to access part of your github information or to impersonate you για να εκτελέσουν κάποιες ενέργειες. Ένα κοινό παράδειγμα αυτής της λειτουργίας είναι το login with github button που μπορεί να βρείτε σε κάποιες πλατφόρμες.

Κάποιες συστάσεις ασφάλειας:

  • An OAuth App should always act as the authenticated GitHub user across all of GitHub (for example, when providing user notifications) and with access only to the specified scopes..
  • An OAuth App can be used as an identity provider by enabling a “Login with GitHub” for the authenticated user.
  • Don’t build an OAuth App if you want your application to act on a single repository. With the repo OAuth scope, OAuth Apps can act on _all_** of the authenticated user’s repositorie**s.
  • Don’t build an OAuth App to act as an application for your team or company. OAuth Apps authenticate as a single user, so if one person creates an OAuth App for a company to use, and then they leave the company, no one else will have access to it.
  • More in here.

Github Applications

Οι Github applications μπορούν να ζητήσουν άδειες για access your github information or impersonate you ώστε να εκτελέσουν συγκεκριμένες ενέργειες σε συγκεκριμένους πόρους. Στα Github Apps πρέπει να καθορίσετε τα repositories στα οποία η εφαρμογή θα έχει πρόσβαση.

  • Για να εγκαταστήσετε ένα GitHub App, πρέπει να είστε organisation owner or have admin permissions σε ένα repository.
  • Το GitHub App πρέπει να connect to a personal account or an organisation.
  • Μπορείτε να δημιουργήσετε την δική σας Github application στο https://github.com/settings/apps
  • Μπορείτε να δείτε όλες τις Github applications that has access to your account στο https://github.com/settings/apps/authorizations
  • Αυτά είναι τα API Endpoints for Github Applications https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. Ανάλογα με τα permissions του App θα έχει πρόσβαση σε κάποιο από αυτά.
  • Μπορείτε να δείτε εγκατεστημένες εφαρμογές σε μια organization στο https://github.com/organizations/<org_name>/settings/installations

Κάποιες συστάσεις ασφάλειας:

  • A GitHub App should take actions independent of a user (εκτός αν η εφαρμογή χρησιμοποιεί ένα user-to-server token). Για να διατηρηθούν τα user-to-server access tokens πιο ασφαλή, μπορείτε να χρησιμοποιήσετε access tokens που θα λήγουν μετά από 8 ώρες, και ένα refresh token που μπορεί να ανταλλαγεί για νέο access token. Για περισσότερες πληροφορίες, δείτε “Refreshing user-to-server access tokens.”
  • Βεβαιωθείτε ότι το GitHub App ενσωματώνεται με specific repositories.
  • Το GitHub App πρέπει να connect to a personal account or an organisation.
  • Μην περιμένετε ότι το GitHub App γνωρίζει και μπορεί να κάνει τα πάντα που μπορεί ένας χρήστης.
  • Don’t use a GitHub App if you just need a “Login with GitHub” service. But a GitHub App can use a user identification flow to log users in and do other things.
  • Μην δημιουργήσετε ένα GitHub App εάν θέλετε να ενεργείτε only ως ένας GitHub user και να κάνετε τα πάντα που ο χρήστης μπορεί να κάνει.
  • Αν χρησιμοποιείτε την εφαρμογή σας με GitHub Actions και θέλετε να τροποποιήσετε workflow files, πρέπει να πιστοποιηθείτε εξ ονόματος του χρήστη με ένα OAuth token που περιλαμβάνει το workflow scope. Ο χρήστης πρέπει να έχει admin ή write permission στο repository που περιέχει το workflow file. Για περισσότερες πληροφορίες, δείτε “Understanding scopes for OAuth apps.”
  • More in here.

Github Actions

Αυτό isn’t a way to authenticate in github, αλλά ένα malicious Github Action θα μπορούσε να αποκτήσει unauthorised access to github και depending στα privileges που έχουν δοθεί στο Action διάφορες different attacks μπορούν να πραγματοποιηθούν. Δείτε παρακάτω για περισσότερες πληροφορίες.

Git Actions

Οι Git actions επιτρέπουν την αυτοματοποίηση της execution of code when an event happen. Συνήθως ο κώδικας που εκτελείται είναι somehow related to the code of the repository (π.χ. να build ένα docker container ή να ελέγξει ότι το PR δεν περιέχει secrets).

Configuration

Στο https://github.com/organizations/<org_name>/settings/actions είναι δυνατό να ελέγξετε την configuration of the github actions για την οργάνωση.

Είναι δυνατό να απαγορευτεί η χρήση των github actions εντελώς, να allow all github actions, ή να επιτρέπονται μόνο ορισμένα actions.

Επίσης είναι δυνατό να διαμορφώσετε who needs approval to run a Github Action και τα permissions of the GITHUB_TOKEN ενός Github Action όταν εκτελείται.

Git Secrets

Τα Github Action συνήθως χρειάζονται κάποιο είδος secrets για να αλληλεπιδράσουν με το github ή third party applications. Για να avoid putting them in clear-text στο repo, το github επιτρέπει να τα αποθηκεύετε ως Secrets.

Αυτά τα secrets μπορούν να ρυθμιστούν for the repo or for all the organization. Έπειτα, για να μπορεί το Action να έχει πρόσβαση στο secret πρέπει να το δηλώσετε όπως:

steps:
- name: Hello world action
with: # Set the secret as an input
super_secret:${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret:${{ secrets.SuperSecret }}

Παράδειγμα χρήσης Bash 

steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

Warning

Secrets can only be accessed from the Github Actions που τα έχουν δηλωμένα.

Μόλις διαμορφωθούν στο repo ή στους οργανισμούς, οι χρήστες του github δεν θα μπορούν να τα προσπελάσουν ξανά, θα μπορούν μόνο να τα αλλάξουν.

Επομένως, ο μόνος τρόπος να κλέψεις github secrets είναι να έχεις πρόσβαση στη μηχανή που εκτελεί το Github Action (σε αυτό το σενάριο θα μπορέσεις να προσπελάσεις μόνο τα secrets που έχουν δηλωθεί για το Action).

Git Environments

Το Github επιτρέπει τη δημιουργία environments όπου μπορείτε να αποθηκεύσετε secrets. Στη συνέχεια, μπορείτε να δώσετε στο github action πρόσβαση στα secrets μέσα στο environment με κάτι σαν:

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

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

  • Απαιτούμενοι εγκριτές: μπλοκάρουν τα gate jobs που στοχεύουν το περιβάλλον μέχρι να εγκριθούν. Ενεργοποιήστε το Prevent self-review για να εφαρμόσετε την αρχή των τεσσάρων ματιών και στην ίδια την έγκριση.
  • Κλάδοι και tags για ανάδυση (deployment branches and tags): περιορίστε ποιοι κλάδοι/ετικέτες μπορούν να κάνουν deployment στο περιβάλλον. Προτιμήστε να επιλέγετε συγκεκριμένους κλάδους/ετικέτες και βεβαιωθείτε ότι αυτοί οι κλάδοι είναι προστατευμένοι. Σημείωση: η επιλογή “Protected branches only” εφαρμόζεται στις κλασικές προστασίες κλάδων και μπορεί να μην συμπεριφέρεται όπως αναμένεται αν χρησιμοποιείτε rulesets.
  • Wait timer: καθυστερεί τα deployments για μια παραμετροποιήσιμη περίοδο.

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

Git Action Runner

Μια Github Action μπορεί να εκτελεστεί μέσα στο github environment ή να εκτελεστεί σε υποδομή τρίτου μέρους που έχει ρυθμιστεί από τον χρήστη.

Πολλές οργανώσεις επιτρέπουν την εκτέλεση Github Actions σε υποδομή τρίτου μέρους καθώς συνήθως είναι φθηνότερο.

Μπορείτε να περιγράψετε τους self-hosted runners μιας οργάνωσης στο https://github.com/organizations/<org_name>/settings/actions/runners

Ο τρόπος να βρείτε ποιες Github Actions εκτελούνται σε μη-github υποδομή είναι να αναζητήσετε runs-on: self-hosted στο yaml της ρύθμισης της Github Action.

Δεν είναι δυνατό να τρέξετε μια Github Action μιας οργάνωσης μέσα σε ένα self-hosted box άλλης οργάνωσης επειδή παράγεται ένα μοναδικό token για τον Runner όταν τον ρυθμίζετε, ώστε να γνωρίζει σε ποια οργάνωση ανήκει.

Αν ο custom Github Runner είναι ρυθμισμένος σε μηχάνημα μέσα σε AWS ή GCP για παράδειγμα, η Action μπορεί να έχει πρόσβαση στο metadata endpoint και να κλέψει το token του service account με το οποίο τρέχει η μηχανή.

Git Action Compromise

Αν όλες οι actions (ή μια κακόβουλη action) επιτρέπονται, ένας χρήστης θα μπορούσε να χρησιμοποιήσει μια κακόβουλη Github Action που θα παραβιάσει το container όπου εκτελείται.

Caution

Μια κακόβουλη Github Action θα μπορούσε να κακοποιηθεί από τον επιτιθέμενο για να:

  • Κλέψει όλα τα secrets στα οποία η Action έχει πρόσβαση
  • Κινήσει πλαγίως (move laterally) αν η Action εκτελείται μέσα σε υποδομή τρίτου μέρους όπου το SA token που χρησιμοποιείται για τη μηχανή είναι προσβάσιμο (πιθανώς μέσω της υπηρεσίας metadata)
  • Κακοποιήσει το token που χρησιμοποιείται από το workflow για να κλέψει τον κώδικα του repo όπου η Action εκτελείται ή ακόμη και να τον τροποποιήσει.

Προστασίες Κλάδων

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

Οι προστασίες κλάδων ενός repository μπορούν να βρεθούν στο https://github.com/<orgname>/<reponame>/settings/branches

Note

Δεν είναι δυνατό να οριστεί προστασία κλάδου σε επίπεδο οργάνωσης. Έτσι όλες πρέπει να δηλωθούν σε κάθε repo.

Διαφορετικές προστασίες μπορούν να εφαρμοστούν σε έναν κλάδο (όπως π.χ. στον master):

  • Μπορείτε να απαιτήσετε ένα PR πριν το merge (ώστε να μην μπορείτε να συγχωνεύσετε απευθείας κώδικα στον κλάδο). Αν αυτό επιλεγεί, μπορούν να ισχύουν και άλλες προστασίες:
  • Απαιτήστε έναν αριθμό approvals. Είναι πολύ συνηθισμένο να απαιτούνται 1 ή 2 ακόμα άτομα για να εγκρίνουν το PR ώστε ένας μόνο χρήστης να μην μπορεί να συγχωνεύει κώδικα απευθείας.
  • Απόρριψη εγκρίσεων όταν σπρώχνονται νέα commits (Dismiss approvals when new commits are pushed). Αν δεν ενεργοποιηθεί, ένας χρήστης μπορεί να εγκρίνει νόμιμο κώδικα και μετά να προσθέσει κακόβουλο κώδικα και να τον συγχωνεύσει.
  • Απαιτήστε έγκριση του πιο πρόσφατου reviewable push. Εξασφαλίζει ότι οποιαδήποτε νέα commits μετά από μια έγκριση (συμπεριλαμβανομένων push από άλλους συνεργάτες) επανεκκινούν την αναθεώρηση ώστε ένας επιτιθέμενος να μην μπορεί να κάνει push μεταγενέστερα της έγκρισης αλλαγές και να συγχωνεύσει.
  • Απαιτήστε reviews από Code Owners. Τουλάχιστον 1 code owner του repo πρέπει να εγκρίνει το PR (ώστε “τυχαίοι” χρήστες να μην μπορούν να το εγκρίνουν).
  • Περιορίστε ποιος μπορεί να απορρίψει reviews pull request. Μπορείτε να καθορίσετε άτομα ή teams που επιτρέπεται να απορρίπτουν reviews.
  • Επιτρέψτε σε καθορισμένους actors να παρακάμπτουν τις απαιτήσεις pull request. Αυτοί οι χρήστες θα μπορούν να παρακάμπτουν τους προηγούμενους περιορισμούς.
  • Απαιτήστε να περάσουν status checks πριν το merge. Ορισμένοι έλεγχοι πρέπει να περάσουν πριν συγχωνευτεί το commit (όπως μια GitHub App που αναφέρει αποτελέσματα SAST). Συμβουλή: δεσμεύστε τα απαιτούμενα checks σε μια συγκεκριμένη GitHub App· αλλιώς οποιαδήποτε app θα μπορούσε να παραποιήσει το check μέσω του Checks API, και πολλά bots αποδέχονται skip directives (π.χ., “@bot-name skip”).
  • Απαιτήστε επίλυση συνομιλιών πριν το merge. Όλα τα σχόλια στον κώδικα πρέπει να επιλυθούν πριν το PR συγχωνευτεί.
  • Απαιτήστε signed commits. Τα commits πρέπει να είναι υπογεγραμμένα.
  • Απαιτήστε linear history. Αποτρέπει τα merge commits από το να προωθηθούν σε ταιριαστούς κλάδους.
  • Συμπερίληψη administrators. Αν αυτό δεν είναι ενεργοποιημένο, οι admins μπορούν να παρακάμπτουν τους περιορισμούς.
  • Περιορίστε ποιος μπορεί να κάνει push σε ταιριαστούς κλάδους. Περιορίστε ποιος μπορεί να στείλει PR.

Note

Όπως βλέπετε, ακόμη κι αν καταφέρετε να αποκτήσετε κάποια credentials ενός χρήστη, τα repos μπορεί να είναι προστατευμένα αποτρέποντας σας από το να σπρώξετε κώδικα στο master για παράδειγμα ώστε να παραβιάσετε το CI/CD pipeline.

Προστασίες Tags

Τα tags (όπως latest, stable) είναι μεταβλητά από προεπιλογή. Για να εφαρμόσετε μια ροή τεσσάρων ματιών στις ενημερώσεις tags, προστατεύστε τα tags και αλυσσοδέστε τις προστασίες μέσω περιβαλλόντων και κλάδων:

  1. Στον κανόνα προστασίας tag, ενεργοποιήστε το Require deployments to succeed και απαιτήστε έναν επιτυχή deployment σε ένα προστατευμένο περιβάλλον (π.χ., prod).
  2. Στο στοχευόμενο περιβάλλον, περιορίστε τα Deployment branches and tags στον release branch (π.χ., main) και προαιρετικά ρυθμίστε Required reviewers με Prevent self-review.
  3. Στον release κλάδο, ρυθμίστε τις προστασίες κλάδου για να απαιτήσετε pull request, ορίστε approvals ≥ 1, και ενεργοποιήστε τόσο το Dismiss approvals when new commits are pushed όσο και το Require approval of the most recent reviewable push.

Αυτή η αλυσίδα αποτρέπει έναν μοναδικό συνεργάτη από το να επαναεπισημάνει (retag) ή να κάνει force-publish releases επεξεργαζόμενος το workflow YAML, γιατί οι πύλες (deployment gates) επιβάλλονται έξω από τα workflows.

Αναφορές

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Μάθετε & εξασκηθείτε στο Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks