Last updated
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Die grundlegende Github-Umgebungsstruktur eines großen Unternehmens besteht darin, ein Unternehmen zu besitzen, das mehrere Organisationen besitzt, und jede von ihnen kann mehrere Repositories und mehrere Teams enthalten. Kleinere Unternehmen besitzen möglicherweise nur eine Organisation und keine Unternehmen.
Aus der Sicht eines Benutzers kann ein Benutzer ein Mitglied von verschiedenen Unternehmen und Organisationen sein. Innerhalb dieser kann der Benutzer verschiedene Rollen in Unternehmen, Organisationen und Repositories haben.
Darüber hinaus kann ein Benutzer Teil verschiedener Teams mit unterschiedlichen Rollen in Unternehmen, Organisationen oder Repositories sein.
Und schließlich können Repositories spezielle Schutzmechanismen haben.
Unternehmensinhaber: 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 die Einstellungen oder Inhalte der Organisation zugreifen, es sei denn, sie werden zum Organisationsinhaber ernannt oder erhalten direkten Zugriff auf ein von der Organisation besessenes Repository.
Unternehmensmitglieder: Mitglieder von Organisationen, die Ihrem Unternehmen gehören, sind ebenfalls automatisch Mitglieder des Unternehmens.
In einer Organisation können Benutzer verschiedene Rollen haben:
Organisationsinhaber: Organisationsinhaber haben vollständigen administrativen Zugriff auf Ihre Organisation. Diese Rolle sollte begrenzt sein, jedoch auf nicht weniger als zwei Personen in Ihrer Organisation.
Organisationsmitglieder: Die Standard-Nicht-Administratorenrolle 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 ist eine Rolle, die Organisationsinhaber einem Team in einer Organisation zuweisen können. Wenn sie angewendet wird, gibt sie jedem Mitglied des Teams Berechtigungen, um Sicherheitswarnungen und -einstellungen in Ihrer Organisation zu verwalten sowie Lesezugriff auf alle Repositories in der Organisation zu haben.
Wenn Ihre Organisation ein Sicherheitsteam hat, können Sie die Rolle des Sicherheitsmanagers verwenden, um den Mitgliedern des Teams den minimalen Zugriff zu gewähren, den sie für die Organisation benötigen.
Github App-Manager: Um zusätzlichen Benutzern zu ermöglichen, GitHub-Apps zu verwalten, die einer Organisation gehören, kann ein Eigentümer ihnen Berechtigungen als GitHub App-Manager gewähren.
Externe Mitarbeiter: Ein externer Mitarbeiter ist eine Person, die Zugriff auf eines oder mehrere Repositories der Organisation hat, aber nicht ausdrücklich 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
In https://github.com/organizations/<org_name>/settings/member_privileges können Sie die Berechtigungen sehen, die Benutzer nur durch ihre Mitgliedschaft in der Organisation haben.
Die hier konfigurierten Einstellungen geben die folgenden Berechtigungen der Mitglieder der Organisation an:
Admin, Writer, Reader oder keine Berechtigung über alle Repositories der Organisation sein.
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 Seiten veröffentlicht werden können.
Die Berechtigungen, die Administratoren über die Repositories haben.
Ob Mitglieder neue Teams erstellen können.
Standardmäßig werden Repository-Rollen erstellt:
Lesen: Empfohlen für Nicht-Code-Beitragende, die Ihr Projekt ansehen oder diskutieren möchten.
Triage: Empfohlen für Beitragende, die Probleme und Pull-Requests proaktiv verwalten müssen, ohne Schreibzugriff zu haben.
Schreiben: Empfohlen für Beitragende, die aktiv zu Ihrem Projekt beitragen.
Verwalten: Empfohlen für Projektmanager, die das Repository verwalten müssen, ohne Zugriff auf sensible oder destruktive Aktionen zu haben.
Admin: Empfohlen für Personen, die vollständigen Zugriff auf das Projekt benötigen, einschließlich sensibler und destruktiver 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 Ihre eigenen Rollen erstellen in https://github.com/organizations/<org_name>/settings/roles
Sie können die in einer Organisation erstellten Teams auflisten in https://github.com/orgs/<org_name>/teams. Beachten Sie, dass Sie, um die Teams zu sehen, die Kinder anderer Teams sind, auf jedes übergeordnete Team zugreifen müssen.
Die Benutzer einer Organisation können in https://github.com/orgs/<org_name>/people aufgelistet werden.
In den Informationen zu jedem Benutzer können Sie die Teams sehen, in denen der Benutzer Mitglied ist, und die Repos, auf die der Benutzer Zugriff hat.
Github bietet verschiedene Möglichkeiten, sich bei Ihrem Konto zu authentifizieren und Aktionen in Ihrem Namen auszuführen.
Durch den Zugriff auf github.com können Sie sich mit Ihrem Benutzernamen und Passwort (und möglicherweise einer 2FA) anmelden.
Sie können Ihr Konto mit einem oder mehreren öffentlichen Schlüsseln konfigurieren, die es dem zugehörigen privaten Schlüssel ermöglichen, Aktionen in Ihrem Namen auszuführen. https://github.com/settings/keys
Sie können den Benutzer mit diesen Schlüsseln nicht impersonifizieren, aber wenn Sie ihn nicht verwenden, könnte es möglich sein, dass Sie entdeckt werden, weil Sie Commits ohne eine Signatur senden. Erfahren Sie mehr über den wachsamen Modus hier.
Sie können persönliche Zugriffstoken generieren, um einer Anwendung Zugriff auf Ihr Konto zu gewähren. Bei der Erstellung eines persönlichen Zugriffstokens muss der Benutzer die Berechtigungen angeben, die das Token haben wird. https://github.com/settings/tokens
Oauth-Anwendungen können Sie um Berechtigungen bitten, um auf Teile Ihrer Github-Informationen zuzugreifen oder Sie zu impersonifizieren, um einige Aktionen auszuführen. Ein häufiges Beispiel für diese Funktionalität ist die Login mit Github-Schaltfläche, die Sie möglicherweise auf einigen Plattformen finden.
Sie können Ihre eigenen Oauth-Anwendungen in https://github.com/settings/developers erstellen.
Sie können alle Oauth-Anwendungen sehen, die Zugriff auf Ihr Konto haben in https://github.com/settings/applications.
Sie können die Scopes sehen, die Oauth-Apps anfordern können in https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps.
Sie können den Zugriff von Drittanwendungen in einer Organisation in https://github.com/organizations/<org_name>/settings/oauth_application_policy sehen.
Einige Sicherheitsempfehlungen:
Eine OAuth-App sollte immer als authentifizierter GitHub-Benutzer über das gesamte GitHub hinweg agieren (zum Beispiel, wenn Benutzerbenachrichtigungen bereitgestellt werden) und nur Zugriff auf die angegebenen Scopes haben.
Eine OAuth-App kann als Identitätsanbieter verwendet werden, indem ein "Login mit GitHub" für den authentifizierten Benutzer aktiviert wird.
Bauen Sie keine OAuth-App, wenn Sie möchten, dass Ihre Anwendung auf ein einzelnes Repository zugreift. Mit dem repo OAuth-Scope können OAuth-Apps auf _allen_** Repositories des authentifizierten Benutzers zugreifen**.
Bauen Sie keine OAuth-App, um als Anwendung für Ihr Team oder Unternehmen zu fungieren. OAuth-Apps authentifizieren sich als einzelner Benutzer, sodass, wenn eine Person eine OAuth-App für ein Unternehmen erstellt, und dann das Unternehmen verlässt, niemand sonst Zugriff darauf hat.
Mehr dazu hier.
Github-Anwendungen können um Berechtigungen bitten, um auf Ihre Github-Informationen zuzugreifen oder Sie zu impersonifizieren, um spezifische Aktionen über spezifische Ressourcen auszuführen. In Github-Apps müssen Sie die Repositories angeben, auf die die App Zugriff haben wird.
Um eine GitHub-App zu installieren, müssen Sie Organisationsinhaber oder über Administratorberechtigungen in einem Repository verfügen.
Die GitHub-App sollte mit einem persönlichen Konto oder einer Organisation verbunden sein.
Sie können Ihre eigene Github-Anwendung in https://github.com/settings/apps erstellen.
Sie können alle Github-Anwendungen sehen, die Zugriff auf Ihr Konto haben in https://github.com/settings/apps/authorizations.
Dies sind die API-Endpunkte für Github-Anwendungen https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. Je nach Berechtigungen der App kann sie auf einige von ihnen zugreifen.
Sie können installierte Apps in einer Organisation in https://github.com/organizations/<org_name>/settings/installations sehen.
Einige Sicherheitsempfehlungen:
Eine GitHub-App sollte unabhängig von einem Benutzer handeln (es sei denn, die App verwendet ein User-to-Server Token). Um User-to-Server-Zugriffstoken sicherer zu machen, können Sie Zugriffstoken verwenden, die nach 8 Stunden ablaufen, und ein Refresh-Token, das gegen ein neues Zugriffstoken eingetauscht werden kann. Weitere Informationen finden Sie unter "Aktualisieren von User-to-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 verbunden sein.
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.
Bauen 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-Scope enthält. Der Benutzer muss über Administrator- oder Schreibberechtigungen für das Repository verfügen, das die Workflow-Datei enthält. Weitere Informationen finden Sie unter "Verstehen von Scopes für OAuth-Apps."
Mehr dazu hier.
Dies ist kein Weg, um sich bei Github zu authentifizieren, aber eine bösartige Github Action könnte unbefugten Zugriff auf Github erhalten und je nach den Berechtigungen, die der Action gegeben werden, könnten mehrere verschiedene Angriffe durchgeführt werden. Siehe unten für weitere Informationen.
Git-Aktionen ermöglichen es, die Ausführung von Code zu automatisieren, wenn ein Ereignis eintritt. In der Regel ist der ausgeführte Code irgendwie mit dem Code des Repositories verbunden (vielleicht einen Docker-Container bauen oder überprüfen, ob der PR keine Geheimnisse enthält).
In https://github.com/organizations/<org_name>/settings/actions ist es möglich, die Konfiguration der Github-Aktionen für die Organisation zu überprüfen.
Es ist möglich, die Verwendung von Github-Aktionen vollständig zu verbieten, alle Github-Aktionen zuzulassen oder nur bestimmte Aktionen zuzulassen.
Es ist auch möglich zu konfigurieren, wer die Genehmigung benötigt, um eine Github-Aktion auszuführen, und die Berechtigungen des GITHUB_TOKEN einer Github-Aktion, wenn sie ausgeführt wird.
Github-Aktionen benötigen normalerweise eine Art von Geheimnissen, um mit Github oder Drittanbieteranwendungen zu interagieren. Um zu vermeiden, sie im Klartext im Repo zu speichern, erlaubt Github, sie als Geheimnisse zu speichern.
Diese Geheimnisse können für das Repo oder für die gesamte Organisation konfiguriert werden. Dann, damit die Aktion auf das Geheimnis zugreifen kann, müssen Sie es wie folgt deklarieren:
Secrets können nur von den Github Actions abgerufen werden, die sie deklariert haben.
Sobald sie im Repo oder in den Organisationen konfiguriert sind, können die Nutzer von Github nicht mehr darauf zugreifen, sie können sie nur ändern.
Daher ist der einzige Weg, Github-Secrets zu stehlen, Zugriff auf die Maschine zu haben, die die Github Action ausführt (in diesem Szenario können Sie nur auf die für die Action deklarierten Secrets zugreifen).
Github ermöglicht es, Umgebungen zu erstellen, in denen Sie Secrets speichern können. Dann können Sie der Github Action Zugriff auf die Secrets innerhalb der Umgebung gewähren, indem Sie etwas wie Folgendes verwenden:
You can configure an environment to be accessed by all branches (default), only protected branches or specify which branches can access it. Es kann auch eine Anzahl erforderlicher Überprüfungen festgelegt werden, bevor eine Aktion unter Verwendung einer Umgebung ausgeführt wird oder eine gewisse Zeit gewartet werden, bevor die Bereitstellungen fortgesetzt werden.
Eine Github Action kann innerhalb der Github-Umgebung ausgeführt oder in einer drittanbieter Infrastruktur, die vom Benutzer konfiguriert wurde, ausgeführt werden.
Mehrere Organisationen erlauben es, Github Actions in einer drittanbieter Infrastruktur auszuführen, da dies in der Regel günstiger ist.
Sie können die selbst gehosteten Runner einer Organisation unter https://github.com/organizations/<org_name>/settings/actions/runners auflisten.
Der Weg, um herauszufinden, welche Github Actions in nicht-Github-Infrastruktur ausgeführt werden, besteht darin, nach runs-on: self-hosted in der Github Action-Konfigurations-YAML zu suchen.
Es ist nicht möglich, eine Github Action einer Organisation innerhalb einer selbst gehosteten Box einer anderen Organisation auszuführen, da ein einzigartiges Token für den Runner generiert wird, wenn er konfiguriert wird, um zu wissen, wo der Runner gehört.
Wenn der benutzerdefinierte Github Runner auf einer Maschine innerhalb von AWS oder GCP konfiguriert ist, könnte die Action Zugriff auf den Metadaten-Endpunkt haben und das Token des Dienstkontos stehlen, mit dem die Maschine betrieben wird.
Wenn alle Aktionen (oder eine bösartige Aktion) erlaubt sind, könnte ein Benutzer eine Github Action verwenden, die bösartig ist und 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 Action Zugriff hat
Laterale Bewegungen durchzuführen, wenn die Action in einer drittanbieter Infrastruktur ausgeführt wird, wo das SA-Token, das zum Ausführen der Maschine verwendet wird, abgerufen werden kann (wahrscheinlich über den Metadatenservice)
Das Token zu missbrauchen, das vom Workflow verwendet wird, um den Code des Repos zu stehlen, in dem die Action ausgeführt wird, oder sogar zu ändern.
Branch-Schutzmaßnahmen sind so konzipiert, dass sie nicht die vollständige Kontrolle über ein Repository an die Benutzer geben. Das Ziel ist es, mehrere Schutzmethoden zu implementieren, bevor man in einem bestimmten Branch Code schreiben kann.
Die Branch-Schutzmaßnahmen 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 in jedem Repo deklariert werden.
Verschiedene Schutzmaßnahmen können auf einen Branch (wie auf master) angewendet werden:
Sie können einen PR vor dem Mergen verlangen (so dass Sie Code nicht direkt über den Branch mergen können). Wenn dies ausgewählt ist, können verschiedene andere Schutzmaßnahmen in Kraft treten:
Eine Anzahl von Genehmigungen verlangen. Es ist sehr üblich, 1 oder 2 weitere Personen zu verlangen, die Ihren PR genehmigen, sodass ein einzelner Benutzer nicht in der Lage ist, Code direkt zu mergen.
Genehmigungen zurückweisen, wenn neue Commits gepusht werden. Andernfalls könnte ein Benutzer legitimen Code genehmigen und dann bösartigen Code hinzufügen und mergen.
Überprüfungen von Code-Eigentümern verlangen. Mindestens 1 Code-Eigentümer des Repos muss den PR genehmigen (so dass "zufällige" Benutzer ihn nicht genehmigen können).
Einschränken, wer Pull-Request-Überprüfungen zurückweisen kann. Sie können Personen oder Teams angeben, die berechtigt sind, Pull-Request-Überprüfungen zurückzuweisen.
Bestimmten Akteuren erlauben, die Anforderungen an Pull-Requests zu umgehen. Diese Benutzer können vorherige Einschränkungen umgehen.
Statusprüfungen verlangen, die vor dem Mergen bestehen müssen. Einige Prüfungen müssen bestehen, bevor der Commit gemergt werden kann (wie eine Github Action, die überprüft, ob es kein Klartextgeheimnis gibt).
Lösungen für Gespräche vor dem Mergen verlangen. Alle Kommentare zum Code müssen gelöst werden, bevor der PR gemergt werden kann.
Signierte Commits verlangen. Die Commits müssen signiert sein.
Lineare Historie verlangen. Verhindern, dass Merge-Commits in übereinstimmende Branches gepusht werden.
Administratoren einbeziehen. Wenn dies nicht festgelegt ist, können Administratoren 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 Sie es geschafft haben, einige Anmeldeinformationen eines Benutzers zu erhalten, könnten Repos geschützt sein, sodass Sie beispielsweise keinen Code in master pushen können, um die CI/CD-Pipeline zu kompromittieren.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
