Basic Github Information
Last updated
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-Administrationsrolle 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 erlauben, 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 die 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-Beitragsleistende, die Ihr Projekt ansehen oder diskutieren möchten.
Triage: Empfohlen für Beitragsleistende, die Probleme und Pull-Requests proaktiv verwalten müssen, ohne Schreibzugriff zu haben.
Schreiben: Empfohlen für Beitragsleistende, 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 jedes Benutzers 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 anzumelden 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. Abhängig von den 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 der 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. 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 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.
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)
