German - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Basic Github Information

Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Grundstruktur

Die grundlegende Github-Umgebungstruktur eines großen Unternehmens besteht darin, ein Unternehmen zu besitzen, das mehrere Organisationen besitzt, von denen jede mehrere Repositories und mehrere Teams enthalten kann. Kleinere Unternehmen besitzen möglicherweise nur eine Organisation und keine Unternehmen.

Aus Sicht eines Benutzers kann ein Benutzer Mitglied verschiedener Unternehmen und Organisationen sein. Innerhalb von diesen kann der Benutzer verschiedene Unternehmens-, Organisations- und Repository-Rollen haben.

Darüber hinaus kann ein Benutzer Teil verschiedener Teams mit unterschiedlichen Unternehmens-, Organisations- oder Repository-Rollen sein.

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

Berechtigungen

Unternehmensrollen

  • Unternehmenseigentümer: Personen mit dieser Rolle können Administratoren verwalten, Organisationen innerhalb des Unternehmens verwalten, Unternehmenseinstellungen verwalten, Richtlinien in Organisationen durchsetzen. Sie können jedoch nicht auf Organisationseinstellungen oder -inhalte zugreifen, es sei denn, sie werden zum Organisationseigentümer gemacht oder erhalten direkten Zugriff auf ein von der Organisation verwaltetes Repository.

  • Unternehmensmitglieder: Mitglieder von Organisationen, die Ihrem Unternehmen gehören, sind auch automatisch Mitglieder des Unternehmens.

Organisationsrollen

In einer Organisation können Benutzer verschiedene Rollen haben:

  • Organisationseigentümer: Organisationseigentümer haben vollen administrativen Zugriff auf Ihre Organisation. Diese Rolle sollte in Ihrer Organisation begrenzt sein, jedoch nicht auf weniger als zwei Personen.

  • Organisationsmitglieder: Die Standard-, nicht-administrative Rolle für Personen in einer Organisation ist das Organisationsmitglied. Standardmäßig haben Organisationsmitglieder eine Reihe von Berechtigungen.

  • Abrechnungsmanager: Abrechnungsmanager sind Benutzer, die die Abrechnungseinstellungen für Ihre Organisation verwalten können, wie z. B. Zahlungsinformationen.

  • Sicherheitsmanager: Es handelt sich um eine Rolle, die Organisationseigentümer jedem Team in einer Organisation zuweisen können. Bei Anwendung erhalten alle Mitglieder des Teams Berechtigungen, um Sicherheitswarnungen und -einstellungen in Ihrer Organisation zu verwalten sowie Leseberechtigungen für alle Repositories in der Organisation.

  • Wenn Ihre Organisation ein Sicherheitsteam hat, können Sie die Sicherheitsmanagerrolle verwenden, um den Teammitgliedern den geringsten Zugriff zu geben, den sie für die Organisation benötigen.

  • Github-App-Manager: Um zusätzlichen Benutzern zu erlauben, GitHub-Apps zu verwalten, die von einer Organisation im Besitz sind, kann ein Eigentümer ihnen Berechtigungen als GitHub-App-Manager erteilen.

  • Externe Mitarbeiter: Ein externer Mitarbeiter ist eine Person, die Zugriff auf ein oder mehrere Repositories einer Organisation hat, aber nicht explizit Mitglied der Organisation ist.

Sie können 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

Mitgliederberechtigungen

Unter https://github.com/organizations/<org_name>/settings/member_privileges können Sie die Berechtigungen sehen, die Benutzer allein durch die Zugehörigkeit zur Organisation haben.

Die hier konfigurierten Einstellungen geben die folgenden Berechtigungen der Mitglieder der Organisation an:

  • Admin, Schreiber, Leser oder keine Berechtigung für alle Organisation-Repositories.

  • Ob Mitglieder private, interne oder öffentliche Repositories erstellen können.

  • Ob das Forken von Repositories möglich ist.

  • Ob es möglich ist, externe Mitarbeiter einzuladen.

  • Ob öffentliche oder private Websites veröffentlicht werden können.

  • Die Berechtigungen, die Admins über die Repositories haben.

  • Ob Mitglieder neue Teams erstellen können.

Repository-Rollen

Standardmäßig werden Repository-Rollen erstellt:

  • Lesen: Empfohlen für Nicht-Code-Beiträger, die Ihr Projekt anzeigen oder diskutieren möchten.

  • Triage: Empfohlen für Mitwirkende, die Issues und Pull Requests proaktiv verwalten müssen, ohne Schreibzugriff zu haben.

  • Schreiben: Empfohlen für Mitwirkende, die aktiv an Ihrem Projekt arbeiten.

  • Verwalten: Empfohlen für Projektmanager, die das Repository verwalten müssen, ohne Zugriff auf sensible oder zerstörerische Aktionen zu haben.

  • Admin: Empfohlen für Personen, die vollen Zugriff auf das Projekt benötigen, einschließlich sensibler und zerstörerischer Aktionen wie das Verwalten von Sicherheit oder das Löschen eines Repositories.

Sie können 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

Sie können auch eigene Rollen in https://github.com/organizations/<org_name>/settings/roles erstellen.

Teams

Sie können die Teams, die in einer Organisation erstellt wurden, in https://github.com/orgs/<org_name>/teams auflisten. Beachten Sie, dass Sie, um die Teams zu sehen, die Unterteams anderer Teams sind, auf jedes übergeordnete Team zugreifen müssen.

Benutzer

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

In den Informationen jedes Benutzers können Sie die Teams sehen, denen der Benutzer angehört, und die Repos, auf die der Benutzer Zugriff hat.

Github-Authentifizierung

Github bietet verschiedene Möglichkeiten zur Authentifizierung bei Ihrem Konto und zur Durchführung von Aktionen in Ihrem Namen.

Webzugriff

Beim Zugriff auf github.com können Sie sich mit Ihrem Benutzernamen und Passwort (und potenziell 2FA) anmelden.

SSH-Schlüssel

Sie können Ihr Konto mit einem oder mehreren öffentlichen Schlüsseln konfigurieren, die dem entsprechenden privaten Schlüssel ermöglichen, Aktionen in Ihrem Namen auszuführen. https://github.com/settings/keys

GPG-Schlüssel

Sie können den Benutzer nicht mit diesen Schlüsseln imitieren, aber wenn Sie sie nicht verwenden, ist es möglich, dass Sie entdeckt werden, wenn Sie Commits ohne Signatur senden. Erfahren Sie mehr über den vigilanten Modus hier.

Persönliche Zugriffstoken

Sie können ein persönliches Zugriffstoken generieren, um einer Anwendung Zugriff auf Ihr Konto zu geben. Beim Erstellen eines persönlichen Zugriffstokens muss der Benutzer die Berechtigungen angeben, die das Token haben wird. https://github.com/settings/tokens

Oauth-Anwendungen

Oauth-Anwendungen können um Berechtigungen bitten, um auf einen Teil Ihrer Github-Informationen zuzugreifen oder Sie zu impersonieren, um bestimmte Aktionen auszuführen. Ein häufiges Beispiel für diese Funktionalität ist der Login mit Github-Button, den Sie auf einigen Plattformen finden können.

Einige Sicherheitsempfehlungen:

  • Eine OAuth-App sollte immer als der authentifizierte GitHub-Benutzer überall auf GitHub agieren (zum Beispiel bei der Bereitstellung von Benachrichtigungen für Benutzer) und nur Zugriff auf die angegebenen Bereiche haben.

  • Eine OAuth-App kann als Identitätsanbieter fungieren, indem sie ein "Login mit GitHub" für den authentifizierten Benutzer ermöglicht.

  • Erstellen Sie keine OAuth-App, wenn Ihre Anwendung auf einem einzigen Repository agieren soll. Mit dem repo-OAuth-Bereich können OAuth-Apps auf _alle_** Repositorien des authentifizierten Benutzers zugreifen**.

  • Erstellen Sie keine OAuth-App, um als Anwendung für Ihr Team oder Unternehmen zu agieren. OAuth-Apps authentifizieren sich als einziger Benutzer, daher hat, wenn eine Person eine OAuth-App für ein Unternehmen erstellt und dann das Unternehmen verlässt, niemand sonst Zugriff darauf.

  • Mehr dazu hier.

Github-Anwendungen

Github-Anwendungen können um Berechtigungen bitten, um auf Ihre Github-Informationen zuzugreifen oder Sie zu impersonieren, um spezifische Aktionen über spezifische Ressourcen auszuführen. Bei Github-Apps müssen Sie die Repositories angeben, auf die die App zugreifen darf.

  • Um eine GitHub-App zu installieren, müssen Sie ein Organisationseigentümer oder Administratorberechtigungen in einem Repository sein.

  • Die GitHub-App sollte mit einem persönlichen Konto oder einer Organisation verbinden.

  • Sie können Ihre eigene Github-Anwendung unter https://github.com/settings/apps erstellen.

  • Sie können alle Github-Anwendungen, die Zugriff auf Ihr Konto haben, unter https://github.com/settings/apps/authorizations einsehen.

  • Dies sind die API-Endpunkte für Github-Anwendungen https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. Abhängig von den Berechtigungen der App kann sie auf einige von ihnen zugreifen.

  • Sie können installierte Apps in einer Organisation unter https://github.com/organizations/<org_name>/settings/installations einsehen.

Einige Sicherheitsempfehlungen:

  • Eine GitHub-App sollte Aktionen unabhängig von einem Benutzer ausführen (sofern die App kein Benutzer-zu-Server-Token verwendet). Um Benutzer-zu-Server-Zugriffstoken sicherer zu halten, können Sie Zugriffstoken verwenden, die nach 8 Stunden ablaufen, und ein Aktualisierungstoken, das gegen ein neues Zugriffstoken eingetauscht werden kann. Weitere Informationen finden Sie unter "Aktualisieren von Benutzer-zu-Server-Zugriffstoken."

  • Stellen Sie sicher, dass die GitHub-App mit spezifischen Repositories integriert ist.

  • Die GitHub-App sollte mit einem persönlichen Konto oder einer Organisation verbinden.

  • Erwarten Sie nicht, dass die GitHub-App alles weiß und tut, was ein Benutzer kann.

  • Verwenden Sie keine GitHub-App, wenn Sie nur einen "Login mit GitHub"-Dienst benötigen. Aber eine GitHub-App kann einen Benutzeridentifikationsfluss verwenden, um Benutzer einzuloggen und andere Dinge zu tun.

  • Erstellen Sie keine GitHub-App, wenn Sie nur als GitHub-Benutzer agieren und alles tun möchten, was dieser Benutzer tun kann.

  • Wenn Sie Ihre App mit GitHub Actions verwenden und Workflow-Dateien ändern möchten, müssen Sie sich im Namen des Benutzers mit einem OAuth-Token authentifizieren, das den workflow-Bereich enthält. Der Benutzer muss Administrator- oder Schreibberechtigungen für das Repository haben, das die Workflow-Datei enthält. Weitere Informationen finden Sie unter "Verständnis der Bereiche für OAuth-Apps."

  • Mehr dazu hier.

Github Actions

Dies ist keine Möglichkeit zur Authentifizierung in Github, aber eine bösartige Github-Action könnte unbefugten Zugriff auf Github erhalten und je nach den bereitgestellten Berechtigungen der Aktion könnten verschiedene Angriffe durchgeführt werden. Weitere Informationen finden Sie unten.

Git Actions

Git-Actions ermöglichen es, die Ausführung von Code zu automatisieren, wenn ein Ereignis eintritt. Normalerweise ist der ausgeführte Code irgendwie mit dem Code des Repositories verbunden (zum Beispiel das Erstellen eines Docker-Containers oder das Überprüfen, ob der PR keine Geheimnisse enthält).

Konfiguration

Unter https://github.com/organizations/<org_name>/settings/actions können Sie die Konfiguration der Github-Actions für die Organisation überprüfen.

Es ist möglich, die Verwendung von Github-Actions vollständig zu untersagen, alle Github-Actions zuzulassen oder nur bestimmte Aktionen zuzulassen.

Es ist auch möglich, festzulegen, wer die Genehmigung zum Ausführen einer Github-Action benötigt und die Berechtigungen des GITHUB_TOKEN einer Github-Action beim Ausführen zu konfigurieren.

Git Secrets

Github-Actions benötigen in der Regel bestimmte Secrets, um mit Github oder Anwendungen von Drittanbietern zu interagieren. Um zu verhindern, dass sie im Klartext im Repository stehen, erlaubt Github, sie als Secrets zu speichern.

Diese Secrets können für das Repository oder für die gesamte Organisation konfiguriert werden. Um sicherzustellen, dass die Action auf das Secret zugreifen kann, müssen Sie es wie folgt deklarieren:

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

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

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

Sobald sie im Repository oder in den Organisationen konfiguriert sind, können Benutzer von Github nicht mehr darauf zugreifen, sie können sie nur ändern.

Daher ist der einzige Weg, um Github-Geheimnisse zu stehlen, der Zugriff auf die Maschine, die die Github-Action ausführt (in diesem Szenario können Sie nur auf die für die Action deklarierten Geheimnisse zugreifen).

Git-Umgebungen

Github ermöglicht es, Umgebungen zu erstellen, in denen Sie Geheimnisse speichern können. Anschließend können Sie der Github-Action den Zugriff auf die Geheimnisse in der Umgebung mit etwas wie:

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

Sie können eine Umgebung so konfigurieren, dass sie von allen Branches (Standard), nur von geschützten Branches oder von spezifischen Branches darauf zugreifen kann. Es kann auch eine Anzahl erforderlicher Reviews vor der Ausführung einer Aktion unter Verwendung einer Umgebung festlegen oder eine Wartezeit festlegen, bevor Bereitstellungen fortgesetzt werden dürfen.

Git Action Runner

Eine Github-Action kann in der Github-Umgebung ausgeführt oder in einer vom Benutzer konfigurierten Drittanbieterinfrastruktur ausgeführt werden.

Viele Organisationen erlauben das Ausführen von Github-Actions in einer Drittanbieterinfrastruktur, da es in der Regel kostengünstiger ist.

Sie können die selbstgehosteten Runner einer Organisation unter https://github.com/organizations/<org_name>/settings/actions/runners auflisten.

Um herauszufinden, welche Github-Actions in einer nicht-github-Infrastruktur ausgeführt werden, suchen Sie nach runs-on: self-hosted in der Konfigurations-YAML der Github-Action.

Es ist nicht möglich, eine Github-Action einer Organisation in einer selbstgehosteten Box einer anderen Organisation auszuführen, da beim Konfigurieren ein eindeutiges Token für den Runner generiert wird, um zu wissen, wohin der Runner gehört.

Wenn der benutzerdefinierte Github Runner in einer Maschine innerhalb von AWS oder GCP konfiguriert ist, könnte die Aktion auf den Metadaten-Endpunkt zugreifen und das Token des Dienstkontos stehlen, mit dem die Maschine ausgeführt wird.

Git Action Kompromittierung

Wenn alle Aktionen (oder eine bösartige Aktion) erlaubt sind, könnte ein Benutzer eine bösartige Github-Action verwenden, die den Container kompromittiert, in dem sie ausgeführt wird.

Eine bösartige Github-Action könnte vom Angreifer missbraucht werden, um:

  • Alle Geheimnisse zu stehlen, auf die die Aktion Zugriff hat

  • Laterale Bewegungen durchzuführen, wenn die Aktion in einer Drittanbieterinfrastruktur ausgeführt wird, in der das SA-Token, das zum Ausführen der Maschine verwendet wird, abgerufen werden kann (wahrscheinlich über den Metadatendienst)

  • Das vom Workflow verwendete Token zu missbrauchen, um den Code des Repos zu stehlen, in dem die Aktion ausgeführt wird, oder ihn sogar zu ändern.

Branch-Schutz

Branch-Schutzmechanismen sollen den Benutzern keine vollständige Kontrolle über ein Repository geben. Das Ziel ist es, mehrere Schutzmethoden zu implementieren, bevor Code in einen bestimmten Branch geschrieben werden kann.

Die Branch-Schutzmechanismen eines Repositories finden Sie unter https://github.com/<orgname>/<reponame>/settings/branches

Es ist nicht möglich, einen Branch-Schutz auf Organisationsebene festzulegen. Daher müssen alle auf jedem Repo deklariert werden.

Es können verschiedene Schutzmaßnahmen auf einen Branch angewendet werden (z. B. auf master):

  • Sie können eine PR vor dem Zusammenführen erfordern (so dass Sie Code nicht direkt über den Branch zusammenführen können). Wenn dies ausgewählt ist, können verschiedene andere Schutzmaßnahmen implementiert werden:

  • Eine Anzahl von Genehmigungen erforderlich machen. Es ist sehr üblich, dass 1 oder 2 weitere Personen Ihre PR genehmigen müssen, damit ein einzelner Benutzer nicht in der Lage ist, Code direkt zusammenzuführen.

  • Genehmigungen abweisen, wenn neue Commits gepusht werden. Andernfalls könnte ein Benutzer legitimen Code genehmigen und dann bösartigen Code hinzufügen und zusammenführen.

  • Reviews von Code-Besitzern erforderlich machen. Mindestens 1 Code-Besitzer des Repos muss die PR genehmigen (damit "zufällige" Benutzer sie nicht genehmigen können)

  • Einschränken, wer Pull-Request-Reviews ablehnen kann. Sie können Personen oder Teams angeben, die berechtigt sind, Pull-Request-Reviews abzulehnen.

  • Bestimmten Akteuren das Umgehen von Pull-Request-Anforderungen ermöglichen. Diese Benutzer können die vorherigen Einschränkungen umgehen.

  • Das Bestehen von Statusprüfungen vor dem Zusammenführen erforderlich machen. Einige Prüfungen müssen bestanden werden, bevor der Commit zusammengeführt werden kann (z. B. eine Github-Action, die prüft, ob keine Klartextgeheimnisse vorhanden sind).

  • Die Auflösung von Konversationen vor dem Zusammenführen erforderlich machen. Alle Kommentare im Code müssen aufgelöst werden, bevor die PR zusammengeführt werden kann.

  • Signierte Commits erforderlich machen. Die Commits müssen signiert sein.

  • Eine lineare Historie erforderlich machen. Verhindern, dass Merge-Commits in übereinstimmende Branches gepusht werden.

  • Administratoren einschließen. Wenn dies nicht festgelegt ist, können Admins die Einschränkungen umgehen.

  • Einschränken, wer in übereinstimmende Branches pushen kann. Einschränken, wer einen PR senden kann.

Wie Sie sehen können, selbst wenn es Ihnen gelingt, die Anmeldeinformationen eines Benutzers zu erhalten, können Repos geschützt sein und verhindern, dass Sie Code in den master-Branch beispielsweise einfügen, um die CI/CD-Pipeline zu kompromittieren.

Referenzen

Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

PreviousGh Actions - Context Script InjectionsNextGitea Security

Last updated