Github Security
Was ist Github
(Aus hier) Auf einer hohen 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.
Grundlegende Informationen
pageBasic Github InformationExterne Aufklärung
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 das gesamte Internet darauf zugreifen kann.
Wenn Sie den Benutzer, das Repo oder die Organisation, die Sie angreifen möchten, kennen, können Sie Github-Dorks verwenden, um nach sensiblen Informationen zu suchen oder nach sensiblen Informationslecks in jedem Repo zu suchen.
Github-Dorks
Github ermöglicht es, nach etwas zu suchen, wobei ein Benutzer, ein Repo oder eine Organisation als Bereich angegeben wird. Daher können Sie mit einer Liste von Zeichenfolgen, die in der Nähe sensibler Informationen erscheinen werden, einfach potenzielle sensible Informationen in Ihrem Ziel suchen.
Tools (jedes Tool enthält seine Liste von Dorks):
Github-Lecks
Bitte beachten Sie, dass die Github-Dorks auch dazu dienen, Lecks mithilfe der Github-Suchoptionen zu suchen. Dieser Abschnitt ist den Tools gewidmet, die jedes Repo herunterladen und nach sensiblen Informationen darin suchen (sogar bestimmte Commit-Tiefen überprüfen).
Tools (jedes Tool enthält seine Liste von Regexes):
Wenn Sie in einem Repo nach Lecks suchen und etwas wie git log -p ausführen, vergessen Sie nicht, dass es andere Branches mit anderen Commits geben könnte, die Geheimnisse enthalten!
Externe Forks
Es ist möglich, Repos zu kompromittieren, indem Pull-Requests missbraucht werden. Um festzustellen, ob ein Repo gefährdet ist, müssen Sie hauptsächlich die Github Actions-YAML-Konfigurationen lesen. Weitere Informationen dazu unten.
Organisationssicherung
Mitgliederrechte
Es gibt einige Standardberechtigungen, die den 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 aus gesteuert werden.
Basisberechtigungen: Mitglieder haben die Berechtigung Keine/Lesen/Schreiben/Admin über die Org-Repositories. Empfohlen wird Keine oder Lesen.
Repository-Forking: Wenn nicht erforderlich, ist es besser, den Mitgliedern nicht zu erlauben, Organisation-Repositories zu forken.
Seitenerstellung: Wenn nicht erforderlich, ist es besser, den Mitgliedern nicht zu erlauben, Seiten aus den Org-Repos zu veröffentlichen. Wenn erforderlich, können Sie öffentliche oder private Seiten erstellen.
Integration Access Requests: Mit dieser Option können externe Mitarbeiter Zugriff auf GitHub- oder OAuth-Apps anfordern, um auf diese Organisation und ihre Ressourcen zuzugreifen. Normalerweise ist dies erforderlich, aber wenn nicht, ist es besser, es zu deaktivieren.
Ich konnte diese Informationen nicht in der API-Antwort finden, teilen Sie sie, wenn Sie sie haben
Änderung der Repository-Sichtbarkeit: Wenn aktiviert, können Mitglieder mit Admin-Berechtigungen für das Repository dessen Sichtbarkeit ändern. Wenn deaktiviert, können nur die Organisationseigentümer die Repository-Sichtbarkeit ändern. Wenn Sie nicht möchten, dass Dinge öffentlich gemacht werden, stellen Sie sicher, dass dies deaktiviert ist.
Ich konnte diese Informationen nicht in der API-Antwort finden, teilen Sie sie, wenn Sie sie haben
Repository-Löschung und -Übertragung: 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, teilen Sie sie, wenn Sie sie haben
Mitgliedern das Erstellen von Teams erlauben: Wenn aktiviert, kann jedes Mitglied der Organisation neue Teams erstellen. Wenn deaktiviert, können nur die Organisationseigentümer neue Teams erstellen. Es ist besser, dies deaktiviert zu haben.
Ich konnte diese Informationen nicht in der API-Antwort finden, teilen Sie sie, wenn Sie sie haben
Weitere Dinge können auf dieser Seite konfiguriert werden, aber die zuvor genannten sind die sicherheitsrelevantesten.
Aktions-Einstellungen
Verschiedene sicherheitsrelevante Einstellungen können für Aktionen von der Seite https://github.com/organizations/<org_name>/settings/actions aus konfiguriert werden.
Beachten Sie, dass all diese Konfigurationen auch für jedes Repository unabhängig festgelegt werden können
Github-Aktionsrichtlinien: Es ermöglicht Ihnen 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 zuzulassen.
Fork-Pull-Request-Workflows von externen Mitarbeitern: Es wird empfohlen, für alle externen Mitarbeiter eine Genehmigung zu verlangen.
Ich konnte keine API mit diesen Informationen finden, teilen Sie sie, wenn Sie sie haben
Workflows aus Fork-Pull-Requests ausführen: Es wird dringend abgeraten, Workflows aus Pull-Requests auszuführen, da den Betreibern des Fork-Ursprungs die Möglichkeit gegeben wird, Tokens mit Leseberechtigungen auf das Quell-Repository zu verwenden.
Ich konnte keine API mit diesen Informationen finden, teilen Sie sie, wenn Sie sie haben
Workflow-Berechtigungen: Es wird dringend empfohlen, nur Lese-Repository-Berechtigungen zu erteilen. Es wird davon abgeraten, Schreib- und Erstell-/Genehmigen-Pull-Request-Berechtigungen zu erteilen, um den Missbrauch des GITHUB_TOKENs, der zum Ausführen von Workflows verwendet wird, zu vermeiden.
Integrationen
Lass 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 erforderlichen zuzulassen (nach Überprüfung).
Installierte GitHub-Apps: Es wird empfohlen, nur die erforderlichen zuzulassen (nach Überprüfung).
Aufklärung & Angriffe unter Ausnutzung von Anmeldeinformationen
Für dieses Szenario gehen wir davon aus, dass Sie Zugriff auf ein GitHub-Konto erhalten haben.
Mit Benutzeranmeldeinformationen
Wenn Sie auf irgendeine Weise bereits Anmeldeinformationen für einen Benutzer innerhalb einer Organisation haben, können Sie sich einfach anmelden und überprüfen, welche Unternehmens- und Organisationsrollen Sie haben, ob Sie ein einfaches Mitglied sind, überprüfen, welche Berechtigungen einfache Mitglieder haben, in welchen Gruppen Sie sind, welche Berechtigungen Sie über welche Repos haben und wie die Repos geschützt sind.
Beachten Sie, dass 2FA verwendet werden kann, sodass Sie nur auf diese Informationen zugreifen können, wenn Sie auch diese Überprüfung bestehen.
Beachten Sie, dass wenn es Ihnen gelingt, das user_session-Cookie zu stehlen (derzeit konfiguriert mit SameSite: Lax), können Sie den Benutzer vollständig imitieren, ohne Anmeldeinformationen oder 2FA zu benötigen.
Überprüfen Sie den Abschnitt unten zu Umgehungen von Branch-Schutzmaßnahmen, falls dies nützlich ist.
Mit Benutzer-SSH-Schlüssel
Github erlaubt Benutzern, SSH-Schlüssel festzulegen, die als Authentifizierungsmethode zum Bereitstellen von Code in ihrem Namen verwendet werden (keine 2FA wird angewendet).
Mit diesem Schlüssel können Sie Änderungen in Repositories vornehmen, in denen der Benutzer einige Berechtigungen hat, jedoch können Sie ihn nicht verwenden, um auf die GitHub-API zuzugreifen, um die Umgebung aufzulisten. Sie können jedoch lokale Einstellungen auflisten, um Informationen zu den Repos und Benutzern zu erhalten, auf die Sie Zugriff haben:
Wenn der Benutzer seinen Benutzernamen als seinen Github-Benutzernamen konfiguriert hat, können Sie auf die öffentlichen Schlüssel zugreifen, die er in seinem Konto unter https://github.com/<github_username>.keys festgelegt hat. 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-Keys festgelegt werden. Jeder, der Zugriff auf diesen Schlüssel hat, kann Projekte aus einem Repository starten. Normalerweise gibt Ihnen die lokale Datei ~/.ssh/config Informationen darüber, welcher Schlüssel damit verbunden ist.
GPG-Schlüssel
Wie hier erklärt, ist es manchmal erforderlich, die Commits zu signieren, oder Sie könnten entdeckt werden.
Überprüfen Sie lokal, ob der aktuelle Benutzer einen Schlüssel hat mit:
Mit Benutzertoken
Für eine Einführung zu Benutzertoken überprüfen Sie die grundlegenden Informationen.
Ein Benutzertoken kann anstelle eines Passworts für Git über HTTPS verwendet werden oder zur Authentifizierung bei der API über Basic Authentication. Je nach den damit verbundenen Berechtigungen können unterschiedliche Aktionen ausgeführt werden.
Ein Benutzertoken sieht so aus: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123
Mit Oauth-Anwendung
Für eine Einführung zu Github Oauth-Anwendungen überprüfen Sie die grundlegenden Informationen.
Ein Angreifer könnte eine bösartige Oauth-Anwendung erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich im Rahmen einer Phishing-Kampagne akzeptieren.
Dies sind die Bereiche, die eine Oauth-Anwendung anfordern kann. Man sollte immer die angeforderten Bereiche überprüfen, bevor man sie akzeptiert.
Darüber hinaus können, wie in den grundlegenden Informationen erklärt, Organisationen den Zugriff von Drittanbieteranwendungen auf Informationen/Repos/Aktionen, die mit der Organisation verbunden sind, gewähren/verweigern.
Mit Github-Anwendung
Für eine Einführung zu Github-Anwendungen überprüfen Sie die grundlegenden Informationen.
Ein Angreifer könnte eine bösartige Github-Anwendung erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich im Rahmen einer Phishing-Kampagne akzeptieren.
Darüber hinaus können, wie in den grundlegenden Informationen erklärt, Organisationen den Zugriff von Drittanbieteranwendungen auf Informationen/Repos/Aktionen, die mit der Organisation verbunden sind, gewähren/verweigern.
Kompromittierung & Missbrauch von Github-Aktionen
Es gibt mehrere Techniken, um eine Github-Aktion zu kompromittieren und zu missbrauchen, überprüfen Sie sie hier:
pageAbusing Github ActionsUmgehung des Branch-Schutzes
Anzahl der Genehmigungen erforderlich: Wenn Sie mehrere Konten kompromittiert haben, können Sie Ihre PRs von anderen Konten aus akzeptieren. Wenn Sie nur Zugriff auf 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 innerhalb des Repos haben, können Sie möglicherweise mit dem GITHUB_TOKEN Ihre PR genehmigen und auf diese Weise eine Genehmigung erhalten.
Hinweis für diese und für die Einschränkung der Code-Besitzer, dass normalerweise ein Benutzer seine eigenen PRs nicht genehmigen kann, aber wenn Sie es können, können Sie es missbrauchen, um Ihre PRs zu akzeptieren.
Genehmigungen ablehnen, wenn neue Commits gepusht werden: Wenn dies nicht festgelegt ist, können Sie legitimen Code einreichen, warten, bis ihn jemand genehmigt, bösartigen Code einfügen und ihn in den geschützten Branch zusammenführen.
Reviews von Code-Besitzern erforderlich: Wenn dies aktiviert ist und Sie ein Code-Besitzer 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, verwendet sie jedoch nicht. Daher wird, wenn sie falsch konfiguriert ist, ihr Code-Besitzer-Schutz nicht angewendet.
Bestimmten Akteuren das Umgehen von Pull-Request-Anforderungen ermöglichen: Wenn Sie einer dieser Akteure sind, können Sie Pull-Request-Schutzmaßnahmen umgehen.
Administratoren einschließen: Wenn dies nicht festgelegt ist und Sie Admin des Repos sind, können Sie diese Branch-Schutzmaßnahmen umgehen.
PR-Hijacking: Sie könnten in der Lage sein, die PR einer anderen Person zu ändern, bösartigen Code hinzuzufügen, die resultierende PR selbst zu genehmigen und alles zusammenzuführen.
Entfernen von Branch-Schutzmaßnahmen: Wenn Sie ein Admin des Repos sind, können Sie die Schutzmaßnahmen deaktivieren, Ihre PR zusammenführen und die Schutzmaßnahmen wieder aktivieren.
Umgehen von Push-Schutzmaßnahmen: Wenn ein Repo nur bestimmten Benutzern das Senden von Pushes (Code-Merges) in Branches erlaubt (der Branch-Schutz könnte alle Branches schützen und den Platzhalter
*verwenden), können Sie trotzdem 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 zum Branch die Github-Aktion ausführen.
Umgehung von Umgebungs-Schutzmaßnahmen
Für eine Einführung zu Github-Umgebungen überprüfen Sie die grundlegenden Informationen.
Falls eine Umgebung von allen Branches aus zugegriffen werden kann, ist sie nicht geschützt und Sie können leicht auf die Secrets innerhalb der Umgebung zugreifen. Beachten Sie, dass Sie möglicherweise Repos finden, in denen alle Branches geschützt sind (durch Angabe ihrer Namen oder durch Verwendung von *), in diesem Szenario einen Branch finden, in den Sie Code pushen können und Sie können die Secrets exfiltrieren, indem Sie eine neue Github-Aktion erstellen (oder eine vorhandene ändern).
Beachten Sie, dass Sie den Grenzfall finden könnten, in dem alle Branches geschützt sind (über den Platzhalter *), es jedoch angegeben ist, wer Code in die Branches pushen kann (Sie können dies im Branch-Schutz angeben) und Ihr Benutzer nicht zugelassen 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 das Pushen 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.
Persistenz
Generieren Sie Benutzertoken
Stehlen Sie Github-Token aus Geheimnissen
Löschen von Workflow-Ergebnissen und Branches
Geben Sie allen Organisationen mehr Berechtigungen
Erstellen Sie Webhooks, um Informationen zu exfiltrieren
Laden Sie externe Mitarbeiter ein
Entfernen Sie Webhooks, die vom SIEM verwendet werden
Erstellen/Ändern Sie Github Action mit einer Hintertür
Finden Sie anfällige Github Action für Befehlseingriffe über die Änderung des Geheimnis-Werts
Imposter Commits - Hintertür über Repo-Commits
In Github ist es möglich, einen PR zu einem Repo von einem Fork aus zu erstellen. Selbst wenn der PR nicht akzeptiert wird, wird eine Commit-ID im Original-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 Besitzer 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
Last updated