Github Security
Last updated
Last updated
Lerne & übe AWS-Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP-Hacking: HackTricks Training GCP Red Team Expert (GRTE)
(Von hier) Auf hoher Ebene ist GitHub eine Website und ein cloudbasierter Dienst, der Entwicklern hilft, ihren Code zu speichern und zu verwalten sowie Änderungen an ihrem Code zu verfolgen und zu kontrollieren.
Github-Repositories können als öffentlich, privat und intern konfiguriert werden.
Privat bedeutet, dass nur Personen der Organisation darauf zugreifen können.
Intern bedeutet, dass nur Personen des Unternehmens (ein Unternehmen kann mehrere Organisationen haben) darauf zugreifen können.
Öffentlich bedeutet, dass alle im Internet darauf zugreifen können.
Falls du den Benutzer, das Repo oder die Organisation, die du anvisieren möchtest, kennst, kannst du Github-Dorks verwenden, um sensible Informationen zu finden oder nach sensiblen Informationslecks in jedem Repo zu suchen.
Github ermöglicht es, nach etwas zu suchen, indem man als Bereich einen Benutzer, ein Repo oder eine Organisation angibt. Daher kannst du mit einer Liste von Zeichenfolgen, die in der Nähe sensibler Informationen erscheinen, leicht nach potenziell sensiblen Informationen in deinem Ziel suchen.
Tools (jedes Tool enthält seine Liste von Dorks):
Bitte beachte, dass die Github-Dorks auch dazu gedacht sind, nach Leaks unter Verwendung der Github-Suchoptionen zu suchen. Dieser Abschnitt ist den Tools gewidmet, die jedes Repo herunterladen und nach sensiblen Informationen darin suchen (sogar bestimmte Tiefen von Commits überprüfen).
Tools (jedes Tool enthält seine Liste von Regex):
Wenn du nach Leaks in einem Repo suchst und etwas wie git log -p ausführst, vergiss nicht, dass es andere Branches mit anderen Commits geben könnte, die Geheimnisse enthalten!
Es ist möglich, Repos zu kompromittieren, indem man Pull-Requests missbraucht. Um zu wissen, ob ein Repo anfällig ist, musst du hauptsächlich die Github Actions YAML-Konfigurationen lesen. Mehr Informationen dazu findest du unten.
Selbst wenn sie gelöscht oder intern sind, könnte es möglich sein, sensible Daten aus Forks von Github-Repositories zu erhalten. Überprüfe es hier:
Accessible Deleted Data in GithubEs gibt einige Standardprivilegien, die Mitgliedern der Organisation zugewiesen werden können. Diese können von der Seite https://github.com/organizations/<org_name>/settings/member_privileges oder von der Organizations API gesteuert werden.
Basisberechtigungen: Mitglieder haben die Berechtigung None/Read/write/Admin über die Org-Repositories. Empfohlen wird None oder Read.
Repository-Forking: Wenn nicht notwendig, ist es besser, Mitglieder nicht zu erlauben, die Repositories der Organisation zu forken.
Seiten erstellen: Wenn nicht notwendig, ist es besser, Mitglieder nicht zu erlauben, Seiten aus den Org-Repos zu veröffentlichen. Wenn notwendig, kannst du das Erstellen öffentlicher oder privater Seiten erlauben.
Zugriffsanforderungen für Integrationen: Mit dieser Aktivierung können externe Mitarbeiter um Zugriff auf GitHub oder OAuth-Apps bitten, um auf diese Organisation und ihre Ressourcen zuzugreifen. Es ist normalerweise erforderlich, aber wenn nicht, ist es besser, es zu deaktivieren.
Ich konnte diese Informationen nicht in der API-Antwort finden, teile sie, wenn du es tust
Änderung der Repository-Sichtbarkeit: Wenn aktiviert, können Mitglieder mit Admin-Berechtigungen für das Repository dessen Sichtbarkeit ändern. Wenn deaktiviert, können nur Organisationsinhaber die Sichtbarkeit von Repositories ändern. Wenn du nicht möchtest, dass Leute Dinge öffentlich machen, stelle sicher, dass dies deaktiviert ist.
Ich konnte diese Informationen nicht in der API-Antwort finden, teile sie, wenn du es tust
Löschen und Übertragen von Repositories: Wenn aktiviert, können Mitglieder mit Admin-Berechtigungen für das Repository öffentliche und private Repositories löschen oder übertragen.
Ich konnte diese Informationen nicht in der API-Antwort finden, teile sie, wenn du es tust
Mitglieder erlauben, Teams zu erstellen: Wenn aktiviert, kann jedes Mitglied der Organisation neue Teams erstellen. Wenn deaktiviert, können nur Organisationsinhaber neue Teams erstellen. Es ist besser, dies deaktiviert zu haben.
Ich konnte diese Informationen nicht in der API-Antwort finden, teile sie, wenn du es tust
Weitere Dinge können auf dieser Seite konfiguriert werden, aber die vorherigen sind die, die mehr mit Sicherheit zu tun haben.
Mehrere sicherheitsrelevante Einstellungen können für Aktionen von der Seite https://github.com/organizations/<org_name>/settings/actions konfiguriert werden.
Beachte, dass all diese Konfigurationen auch unabhängig für jedes Repository festgelegt werden können
Github-Aktionsrichtlinien: Es ermöglicht dir anzugeben, welche Repositories Workflows ausführen können und welche Workflows erlaubt sein sollten. Es wird empfohlen, anzugeben, welche Repositories erlaubt sein sollten und nicht alle Aktionen ausführen zu lassen.
Fork-Pull-Request-Workflows von externen Mitarbeitern: Es wird empfohlen, eine Genehmigung für alle externen Mitarbeiter zu verlangen.
Ich konnte keine API mit diesen Informationen finden, teile sie, wenn du es tust
Workflows von Fork-Pull-Requests ausführen: Es wird dringend abgeraten, Workflows von Pull-Requests auszuführen, da die Maintainer des Fork-Ursprungs die Möglichkeit erhalten, Tokens mit Lesezugriff auf das Quell-Repository zu verwenden.
Ich konnte keine API mit diesen Informationen finden, teile sie, wenn du es tust
Workflow-Berechtigungen: Es wird dringend empfohlen, nur Lesezugriffsberechtigungen für Repositories zu gewähren. Es wird abgeraten, Schreib- und Erstellungs-/Genehmigungsberechtigungen für Pull-Requests zu gewähren, um den Missbrauch des GITHUB_TOKEN zu vermeiden, das für die Ausführung von Workflows vergeben wird.
Lass es mich wissen, wenn du den API-Endpunkt kennst, um auf diese Informationen zuzugreifen!
Richtlinie für den Zugriff von Drittanbieteranwendungen: Es wird empfohlen, den Zugriff auf jede Anwendung einzuschränken und nur die benötigten zuzulassen (nach Überprüfung).
Installierte GitHub-Apps: Es wird empfohlen, nur die benötigten zuzulassen (nach Überprüfung).
Für dieses Szenario nehmen wir an, dass du Zugang zu einem Github-Konto erhalten hast.
Wenn du irgendwie bereits Anmeldeinformationen für einen Benutzer innerhalb einer Organisation hast, kannst du einfach einloggen und überprüfen, welche Unternehmens- und Organisationsrollen du hast, wenn du ein normales Mitglied bist, überprüfe, welche Berechtigungen normale Mitglieder haben, in welchen Gruppen du bist, welche **Berechtigungen du über welche Repos hast und wie die Repos geschützt sind.
Beachte, dass 2FA verwendet werden kann, sodass du nur auf diese Informationen zugreifen kannst, wenn du auch diesen Check bestehst.
Beachte, dass wenn du es schaffst, das user_session-Cookie zu stehlen (derzeit mit SameSite: Lax konfiguriert), kannst du den Benutzer vollständig impersonieren, ohne Anmeldeinformationen oder 2FA zu benötigen.
Überprüfe den Abschnitt unten über Umgehungen des Branchenschutzes, falls es nützlich ist.
Github erlaubt es Benutzern, SSH-Schlüssel festzulegen, die als Authentifizierungsmethode zum Bereitstellen von Code in ihrem Namen verwendet werden (es wird keine 2FA angewendet).
Mit diesem Schlüssel kannst du Änderungen in Repositories vornehmen, in denen der Benutzer einige Berechtigungen hat, jedoch kannst du ihn nicht verwenden, um auf die Github-API zuzugreifen, um die Umgebung aufzulisten. Du kannst jedoch lokale Einstellungen auflisten, um Informationen über die Repos und den Benutzer zu erhalten, auf die du Zugriff hast:
Wenn der Benutzer seinen Benutzernamen als seinen GitHub-Benutzernamen konfiguriert hat, können Sie auf die öffentlichen Schlüssel, die er in seinem Konto festgelegt hat, unter https://github.com/<github_username>.keys zugreifen. Sie könnten dies überprüfen, um zu bestätigen, dass der gefundene private Schlüssel verwendet werden kann.
SSH-Schlüssel können auch in Repositories als Deploy-Schlüssel festgelegt werden. Jeder, der Zugriff auf diesen Schlüssel hat, kann Projekte aus einem Repository starten. In einem Server mit verschiedenen Deploy-Schlüsseln gibt die lokale Datei ~/.ssh/config Informationen darüber, welcher Schlüssel zugeordnet ist.
Wie hier erklärt, ist es manchmal notwendig, die Commits zu signieren, oder Sie könnten entdeckt werden.
Überprüfen Sie lokal, ob der aktuelle Benutzer einen Schlüssel hat mit:
Für eine Einführung über Benutzer-Token siehe die grundlegenden Informationen.
Ein Benutzer-Token kann anstatt eines Passworts für Git über HTTPS verwendet werden oder kann verwendet werden, um sich über die grundlegende Authentifizierung bei der API zu authentifizieren. Abhängig von den damit verbundenen Berechtigungen können Sie möglicherweise verschiedene Aktionen ausführen.
Ein Benutzer-Token sieht so aus: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123
Für eine Einführung über Github Oauth-Anwendungen siehe die grundlegenden Informationen.
Ein Angreifer könnte eine bösartige Oauth-Anwendung erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich als Teil einer Phishing-Kampagne akzeptieren.
Dies sind die Scopes, die eine Oauth-Anwendung anfordern kann. Ein Benutzer sollte immer die angeforderten Scopes überprüfen, bevor er sie akzeptiert.
Darüber hinaus können, wie in den grundlegenden Informationen erklärt, Organisationen den Zugriff auf Drittanbieteranwendungen auf Informationen/Repos/Aktionen, die mit der Organisation verbunden sind, gewähren oder verweigern.
Für eine Einführung über Github-Anwendungen siehe die grundlegenden Informationen.
Ein Angreifer könnte eine bösartige Github-Anwendung erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich als Teil einer Phishing-Kampagne akzeptieren.
Darüber hinaus können, wie in den grundlegenden Informationen erklärt, Organisationen den Zugriff auf Drittanbieteranwendungen auf Informationen/Repos/Aktionen, die mit der Organisation verbunden sind, gewähren oder verweigern.
Es gibt mehrere Techniken, um eine Github-Aktion zu kompromittieren und zu missbrauchen, überprüfen Sie sie hier:
Abusing Github ActionsErfordere eine Anzahl von Genehmigungen: Wenn Sie mehrere Konten kompromittiert haben, könnten Sie einfach Ihre PRs von anderen Konten akzeptieren. Wenn Sie nur das Konto haben, von dem aus Sie die PR erstellt haben, können Sie Ihre eigene PR nicht akzeptieren. Wenn Sie jedoch Zugriff auf eine Github-Aktion-Umgebung im Repo haben, können Sie mit dem GITHUB_TOKEN möglicherweise Ihre PR genehmigen und auf diese Weise 1 Genehmigung erhalten.
Hinweis für dies und für die Code-Eigentümer-Beschränkung, dass ein Benutzer normalerweise seine eigenen PRs nicht genehmigen kann, aber wenn Sie es können, können Sie es missbrauchen, um Ihre PRs zu akzeptieren.
Genehmigungen zurückweisen, wenn neue Commits gepusht werden: Wenn dies nicht festgelegt ist, können Sie legitimen Code einreichen, warten, bis jemand ihn genehmigt, und dann bösartigen Code hinzufügen und ihn in den geschützten Branch zusammenführen.
Überprüfungen von Code-Eigentümern anfordern: Wenn dies aktiviert ist und Sie ein Code-Eigentümer sind, könnten Sie eine Github-Aktion erstellen, die Ihre PR erstellt und dann selbst genehmigt.
Wenn eine CODEOWNER-Datei falsch konfiguriert ist, beschwert sich Github nicht, aber sie wird nicht verwendet. Daher, wenn sie falsch konfiguriert ist, wird der Schutz der Code-Eigentümer nicht angewendet.
Erlaube bestimmten Akteuren, die Anforderungen an Pull-Requests zu umgehen: Wenn Sie einer dieser Akteure sind, können Sie die Pull-Request-Schutzmaßnahmen umgehen.
Administratoren einbeziehen: Wenn dies nicht festgelegt ist und Sie Administrator des Repos sind, können Sie diese Branch-Schutzmaßnahmen umgehen.
PR-Hijacking: Sie könnten in der Lage sein, die PR eines anderen zu ändern, indem Sie bösartigen Code hinzufügen, die resultierende PR selbst genehmigen und alles zusammenführen.
Entfernen von Branch-Schutzmaßnahmen: Wenn Sie ein Administrator des Repos sind, können Sie die Schutzmaßnahmen deaktivieren, Ihre PR zusammenführen und die Schutzmaßnahmen wieder aktivieren.
Umgehung von Push-Schutzmaßnahmen: Wenn ein Repo nur bestimmten Benutzern erlaubt, Push (Code zusammenführen) in Branches zu senden (der Branch-Schutz könnte alle Branches schützen, indem das Wildcard * angegeben wird).
Wenn Sie Schreibzugriff auf das Repo haben, aber nicht berechtigt sind, Code zu pushen aufgrund des Branch-Schutzes, können Sie dennoch einen neuen Branch erstellen und darin eine Github-Aktion erstellen, die ausgelöst wird, wenn Code gepusht wird. Da der Branch-Schutz den Branch nicht schützt, bis er erstellt ist, wird dieser erste Code-Push in den Branch die Github-Aktion ausführen.
Für eine Einführung über Github-Umgebungen siehe die grundlegenden Informationen.
Falls eine Umgebung von allen Branches aus zugänglich ist, ist sie nicht geschützt und Sie können leicht auf die Geheimnisse innerhalb der Umgebung zugreifen. Beachten Sie, dass Sie möglicherweise Repos finden, in denen alle Branches geschützt sind (indem ihre Namen angegeben oder * verwendet wird). In diesem Szenario sollten Sie einen Branch finden, in den Sie Code pushen können, und Sie können die Geheimnisse exfiltrieren, indem Sie eine neue Github-Aktion erstellen (oder eine vorhandene ändern).
Beachten Sie, dass Sie möglicherweise den Grenzfall finden, in dem alle Branches geschützt sind (über Wildcard *), es wird angegeben, wer Code in die Branches pushen kann (Sie können das im Branch-Schutz angeben) und Ihr Benutzer nicht berechtigt ist. Sie können dennoch eine benutzerdefinierte Github-Aktion ausführen, da Sie einen Branch erstellen und den Push-Trigger über sich selbst verwenden können. Der Branch-Schutz erlaubt den Push in einen neuen Branch, sodass die Github-Aktion ausgelöst wird.
Beachten Sie, dass nach der Erstellung des Branches der Branch-Schutz auf den neuen Branch angewendet wird und Sie ihn nicht mehr ändern können, aber zu diesem Zeitpunkt haben Sie bereits die Geheimnisse extrahiert.
Generieren Sie Benutzertoken
Stehlen Sie Github-Tokens aus Secrets
Löschen von Workflow-Ergebnissen und Branches
Geben Sie mehr Berechtigungen für die gesamte Organisation
Erstellen Sie Webhooks, um Informationen zu exfiltrieren
Laden Sie außenstehende Mitarbeiter ein
Entfernen Sie Webhooks, die vom SIEM verwendet werden
Erstellen/Ändern Sie Github Action mit einem Hintertür
Finden Sie anfällige Github Action für Befehlsinjektion durch Änderung des Secret-Werts
In Github ist es möglich, einen PR zu einem Repo von einem Fork zu erstellen. Selbst wenn der PR nicht akzeptiert wird, wird eine Commit-ID im ursprünglichen Repo für die Fork-Version des Codes erstellt. Daher könnte ein Angreifer einen bestimmten Commit aus einem scheinbar legitimen Repo verwenden, der nicht vom Eigentümer des Repos erstellt wurde.
Wie dies:
Für weitere Informationen siehe https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
