Basic Github Information

Reading time: 17 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Basic Structure

Die grundlegende Github-Umgebungsstruktur eines großen Unternehmens besteht darin, eine Enterprise zu besitzen, die mehrere Organisationen besitzt, und jede davon kann mehrere Repositories und mehrere Teams enthalten. Kleinere Firmen besitzen möglicherweise nur eine Organisation und keine Enterprise.

Aus Sicht eines Users kann ein User Mitglied verschiedener Enterprises und Organisationen sein. Innerhalb dieser kann der User verschiedene Enterprise-, Organisations- und Repository-Rollen haben.

Außerdem kann ein User Teil verschiedener Teams mit unterschiedlichen Enterprise-, Organisations- oder Repository-Rollen sein.

Und schließlich können Repositories spezielle Schutzmechanismen haben.

Privileges

Enterprise Roles

  • Enterprise owner: Personen mit dieser Rolle können Administrator*innen verwalten, Organisationen innerhalb der Enterprise verwalten, Enterprise-Einstellungen verwalten, Richtlinien über Organisationen hinweg durchsetzen. Allerdings können sie nicht auf Organisationseinstellungen oder Inhalte zugreifen, es sei denn, sie werden zum Organization owner gemacht oder erhalten direkten Zugriff auf ein organisationseigenes Repository.
  • Enterprise members: Mitglieder von Organisationen, die von deiner Enterprise verwaltet werden, sind automatisch auch Mitglieder der Enterprise.

Organization Roles

In einer Organisation können User verschiedene Rollen haben:

  • Organization owners: Organization owners haben vollständigen administrativen Zugriff auf deine Organisation. Diese Rolle sollte begrenzt sein, aber nicht auf weniger als zwei Personen in deiner Organisation reduziert werden.
  • Organization members: Die Standard-, nicht-administrative Rolle für Personen in einer Organisation ist das Organization member. Standardmäßig haben Organization members eine Reihe von Berechtigungen.
  • Billing managers: Billing managers sind User, die die Abrechnungseinstellungen deiner Organisation verwalten können, wie z. B. Zahlungsinformationen.
  • Security Managers: Das ist eine Rolle, die Organization owners einem beliebigen Team in einer Organisation zuweisen können. Wenn sie angewendet wird, erhalten alle Teammitglieder Berechtigungen, Security Alerts und Einstellungen in der gesamten Organisation zu verwalten sowie Leserechte für alle Repositories in der Organisation.
  • Wenn deine Organisation ein Security-Team hat, kannst du die Security Manager-Rolle nutzen, um den Teammitgliedern den minimal notwendigen Zugriff auf die Organisation zu geben.
  • Github App managers: Um zusätzlichen Personen zu erlauben, GitHub Apps zu verwalten, die einer Organisation gehören, kann ein Owner ihnen GitHub App manager-Berechtigungen gewähren.
  • Outside collaborators: Ein Outside collaborator ist eine Person, die Zugriff auf ein oder mehrere Organisation-Repositories hat, aber nicht explizit Mitglied der Organisation ist.

Du kannst die Berechtigungen dieser Rollen in dieser Tabelle vergleichen: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles

Members Privileges

In https://github.com/organizations/<org_name>/settings/member_privileges kannst du die Berechtigungen sehen, die User allein durch die Mitgliedschaft in der Organisation haben.

Die hier konfigurierten Einstellungen bestimmen folgende Berechtigungen der Mitglieder der Organisation:

  • Admin-, Schreib-, Lese- oder keine Berechtigung für alle Organisation-Repos.
  • Ob Mitglieder private, interne oder öffentliche Repositories erstellen können.
  • Ob Forking von Repositories möglich ist.
  • Ob das Einladen von Outside collaborators möglich ist.
  • Ob öffentliche oder private Sites veröffentlicht werden dürfen.
  • Die Berechtigungen, die Admins über die Repositories haben.
  • Ob Mitglieder neue Teams erstellen können.

Repository Roles

Standardmäßig sind folgende Repository-Rollen vorhanden:

  • Read: Empfohlen für nicht-code Contributors, die dein Projekt ansehen oder diskutieren möchten.
  • Triage: Empfohlen für Contributors, die Issues und Pull Requests proaktiv verwalten müssen, ohne Schreibzugriff.
  • Write: Empfohlen für Contributors, die aktiv in dein Projekt pushen.
  • Maintain: Empfohlen für Projektmanager*innen, die das Repository verwalten müssen, ohne Zugang zu sensiblen oder destruktiven Aktionen.
  • Admin: Empfohlen für Personen, die vollen Zugriff auf das Projekt benötigen, einschließlich sensibler und destruktiver Aktionen wie Security-Management oder Löschen eines Repositories.

Du kannst die Berechtigungen jeder Rolle in dieser Tabelle vergleichen: https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role

Du kannst auch eigene Rollen erstellen in https://github.com/organizations/<org_name>/settings/roles

Teams

Du kannst die in einer Organisation erstellten Teams in https://github.com/orgs/<org_name>/teams auflisten. Beachte, dass du, um die Teams zu sehen, die Kinder anderer Teams sind, jedes Parent-Team aufrufen musst.

Users

Die User einer Organisation können in https://github.com/orgs/<org_name>/people aufgelistet werden.

In den Informationen jedes Users kannst du die Teams, denen der User angehört, und die Repos, auf die der User Zugriff hat, sehen.

Github Authentication

Github bietet verschiedene Möglichkeiten, sich bei deinem Account zu authentifizieren und Aktionen in deinem Namen durchzuführen.

Web Access

Beim Zugriff auf github.com kannst du dich mit deinem Benutzernamen und Passwort (und ggf. einer 2FA) einloggen.

SSH Keys

Du kannst deinen Account mit einem oder mehreren Public Keys konfigurieren, die es dem zugehörigen Private Key erlauben, Aktionen in deinem Namen auszuführen. https://github.com/settings/keys

GPG Keys

Mit diesen Keys kannst du den User nicht impersonifizieren, aber wenn du sie nicht nutzt, kann es passieren, dass du aufgrund von Commits ohne Signatur entdeckt wirst. Mehr zu vigilant mode hier: https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode.

Personal Access Tokens

Du kannst Personal Access Tokens erzeugen, um einer Anwendung Zugriff auf deinen Account zu geben. Beim Erstellen eines Personal Access Tokens muss der User die Berechtigungen angeben, die das Token haben wird. https://github.com/settings/tokens

Oauth Applications

Oauth Applications können dich um Berechtigungen bitten, Teil deiner Github-Informationen zuzugreifen oder dich zu impersonifizieren, um bestimmte Aktionen durchzuführen. Ein übliches Beispiel dafür ist der Login with github-Button, den du auf manchen Plattformen finden kannst.

Einige Sicherheitsempfehlungen:

  • Eine OAuth App sollte immer als der authentifizierte GitHub-User über ganz GitHub agieren (z. B. beim Versenden von User-Notifications) und nur auf die angegebenen Scopes zugreifen.
  • Eine OAuth App kann als Identity Provider genutzt werden, indem ein "Login with GitHub" für den authentifizierten User aktiviert wird.
  • Baue keine OAuth App, wenn deine Anwendung nur auf ein einzelnes Repository wirken soll. Mit dem repo OAuth-Scope können OAuth Apps auf alle Repositories des authentifizierten Users zugreifen.
  • Baue keine OAuth App, um sie als Anwendung für dein Team oder Unternehmen zu verwenden. OAuth Apps authentifizieren als einzelner User; wenn die Person, die die OAuth App erstellt hat, das Unternehmen verlässt, hat niemand sonst Zugriff darauf.
  • Mehr in hier.

Github Applications

Github Applications können Berechtigungen verlangen, um auf deine Github-Informationen zuzugreifen oder dich zu impersonifizieren, um bestimmte Aktionen auf bestimmten Ressourcen durchzuführen. Bei Github Apps musst du angeben, welche Repositories die App zugreifen darf.

Einige Sicherheitsempfehlungen:

  • Eine GitHub App sollte unabhängig von einem User handeln (es sei denn, die App verwendet ein user-to-server Token). Um user-to-server Access Tokens sicherer zu machen, kannst du Access Tokens verwenden, die nach 8 Stunden verfallen, und ein Refresh Token, das gegen ein neues Access Token ausgetauscht werden kann. Mehr dazu unter "Refreshing user-to-server access tokens."
  • Stelle sicher, dass die GitHub App mit konkreten Repositories integriert ist.
  • Die GitHub App sollte mit einem persönlichen Account oder einer Organisation verbunden sein.
  • Erwarte nicht, dass die GitHub App alles weiß und alles tun kann, was ein User tun kann.
  • Benutze keine GitHub App, wenn du nur einen "Login with GitHub"-Dienst brauchst. Eine GitHub App kann jedoch einen user identification flow nutzen, um User einzuloggen und weitere Dinge zu tun.
  • Baue keine GitHub App, wenn du nur als GitHub-User agieren und alles tun möchtest, was dieser User kann.
  • Wenn du deine App mit GitHub Actions nutzt und Workflow-Dateien ändern möchtest, musst du im Namen des Users mit einem OAuth-Token authentifizieren, das den workflow-Scope enthält. Der User muss Admin- oder Schreibrechte für das Repository haben, das die Workflow-Datei enthält. Mehr dazu unter "Understanding scopes for OAuth apps."
  • Mehr in hier.

Github Actions

Das ist keine Methode, sich bei github zu authentifizieren, aber eine malicious Github Action könnte unauthorised Zugriff auf github erlangen und je nach den der Action gegebenen Privilegien könnten verschiedene Angriffe durchgeführt werden. Siehe unten für mehr Informationen.

Git Actions

Git Actions ermöglichen die Automatisierung der Ausführung von Code, wenn ein Event eintritt. Üblicherweise ist der ausgeführte Code irgendwie mit dem Code des Repositories verbunden (z. B. ein Docker-Container bauen oder prüfen, dass der PR keine Secrets enthält).

Configuration

In https://github.com/organizations/<org_name>/settings/actions ist es möglich, die Konfiguration der Github Actions für die Organisation zu überprüfen.

Es ist möglich, die Nutzung von Github Actions komplett zu verbieten, alle Github Actions zu erlauben oder nur bestimmte Actions zuzulassen.

Es ist außerdem möglich zu konfigurieren, wer die Ausführung einer Github Action genehmigen muss und welche Berechtigungen das GITHUB_TOKEN einer Github Action bei Ausführung hat.

Git Secrets

Github Actions benötigen in der Regel irgendwelche Secrets, um mit Github oder Drittanbieter-Anwendungen zu interagieren. Um zu vermeiden, dass diese im Klartext im Repo stehen, erlaubt Github, sie als Secrets zu speichern.

Diese Secrets können für das Repo oder für die gesamte Organisation konfiguriert werden. Dann, damit die Action auf das Secret zugreifen kann, musst du es folgendermaßen deklarieren:

yaml
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 }}

Beispiel mit Bash

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

warning

Secrets können nur von den Github Actions abgerufen werden, die sie deklariert haben.

Sobald sie im repo oder in der organization konfiguriert sind, können Benutzer von github danach nicht mehr auf sie zugreifen, sie können sie nur ändern.

Deshalb ist der einzige Weg, github secrets zu stehlen, Zugriff auf die Maschine zu haben, die die Github Action ausführt (in diesem Szenario kannst du nur auf die für die Action deklarierten secrets zugreifen).

Git Environments

Github erlaubt das Erstellen von environments, in denen du secrets speichern kannst. Dann kannst du der github action Zugriff auf die secrets innerhalb der environment geben mit etwas wie:

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

You can configure an environment to be accessed by all branches (default), only protected branches or specify which branches can access it.
Additionally, environment protections include:

  • Required reviewers: gate jobs targeting the environment until approved. Enable Prevent self-review to enforce a proper four‑eyes principle on the approval itself.
  • Deployment branches and tags: restrict which branches/tags may deploy to the environment. Prefer selecting specific branches/tags and ensure those branches are protected. Note: the "Protected branches only" option applies to classic branch protections and may not behave as expected if using rulesets.
  • Wait timer: delay deployments for a configurable period.

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.

Git Action Runner

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 cheaper.

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.

Git Action Compromise

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.

caution

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

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

note

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 approval of the most recent reviewable push. Ensures that any new commits after an approval (including pushes by other collaborators) re-trigger review so an attacker cannot push post-approval changes and merge.
  • 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 need to pass before being able to merge the commit (like a GitHub App reporting SAST results). Tip: bind required checks to a specific GitHub App; otherwise any app could spoof the check via the Checks API, and many bots accept skip directives (e.g., "@bot-name skip").
  • 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.

note

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.

Tag Protections

Tags (like latest, stable) are mutable by default. To enforce a four‑eyes flow on tag updates, protect tags and chain protections through environments and branches:

  1. On the tag protection rule, enable Require deployments to succeed and require a successful deployment to a protected environment (e.g., prod).
  2. In the target environment, restrict Deployment branches and tags to the release branch (e.g., main) and optionally configure Required reviewers with Prevent self-review.
  3. On the release branch, configure branch protections to Require a pull request, set approvals ≥ 1, and enable both Dismiss approvals when new commits are pushed and Require approval of the most recent reviewable push.

This chain prevents a single collaborator from retagging or force-publishing releases by editing workflow YAML, since deployment gates are enforced outside of workflows.

References

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks