Gitea 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)
Gitea ist eine selbstgehostete, von der Community verwaltete, leichte Code-Hosting-Lösung, die in Go geschrieben ist.
Um eine Gitea-Instanz lokal auszuführen, kannst du einfach einen Docker-Container starten:
Verbinden Sie sich mit Port 3000, um auf die Webseite zuzugreifen.
Sie können es auch mit Kubernetes ausführen:
Öffentliche Repos: http://localhost:3000/explore/repos
Registrierte Benutzer: http://localhost:3000/explore/users
Registrierte Organisationen: http://localhost:3000/explore/organizations
Beachten Sie, dass Gitea standardmäßig neuen Benutzern die Registrierung erlaubt. Dies wird den neuen Benutzern keinen besonders interessanten Zugriff auf die Repos anderer Organisationen/Benutzer geben, aber ein eingeloggter Benutzer könnte in der Lage sein, mehr Repos oder Organisationen zu visualisieren.
Für dieses Szenario nehmen wir an, dass Sie Zugriff auf ein GitHub-Konto erhalten haben.
Wenn Sie irgendwie bereits Anmeldeinformationen für einen Benutzer innerhalb einer Organisation haben (oder Sie ein Sitzungscookie gestohlen haben), können Sie einfach einloggen und überprüfen, über welche Berechtigungen Sie verfügen für welche Repos, in welchen Teams Sie sind, andere Benutzer auflisten und wie die Repos geschützt sind.
Beachten Sie, dass 2FA verwendet werden kann, sodass Sie diese Informationen nur abrufen können, wenn Sie auch diesen Check bestehen.
Beachten Sie, dass wenn Sie es schaffen, das i_like_gitea
-Cookie zu stehlen (derzeit mit SameSite: Lax konfiguriert), können Sie den Benutzer vollständig impersonifizieren, ohne Anmeldeinformationen oder 2FA zu benötigen.
Gitea erlaubt 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 können Sie Änderungen in Repositories vornehmen, in denen der Benutzer einige Berechtigungen hat, jedoch können Sie ihn nicht verwenden, um auf die Gitea-API zuzugreifen, um die Umgebung aufzulisten. Sie können jedoch lokale Einstellungen auflisten, um Informationen über die Repos und Benutzer zu erhalten, auf die Sie Zugriff haben:
Wenn der Benutzer seinen Benutzernamen als seinen gitea Benutzernamen konfiguriert hat, können Sie auf die öffentlichen Schlüssel, die er in seinem Konto festgelegt hat, unter https://github.com/<gitea_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 zu Benutzer-Token siehe die grundlegenden Informationen.
Ein Benutzer-Token kann anstatt eines Passworts verwendet werden, um sich gegenüber dem Gitea-Server über die API zu authentifizieren. Es hat vollständigen Zugriff auf den Benutzer.
Für eine Einführung zu Gitea 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.
Wie in den grundlegenden Informationen erklärt, hat die Anwendung vollen Zugriff auf das Benutzerkonto.
In Github haben wir github actions, die standardmäßig ein Token mit Schreibzugriff auf das Repo erhalten, das verwendet werden kann, um Branch-Schutzmaßnahmen zu umgehen. In diesem Fall existiert das nicht, sodass die Umgehungen eingeschränkter sind. Aber schauen wir uns an, was getan werden kann:
Push aktivieren: Wenn jeder mit Schreibzugriff auf den Branch pushen kann, dann einfach darauf pushen.
Whitelist für eingeschränkten Push: Auf die gleiche Weise, wenn du Teil dieser Liste bist, push auf den Branch.
Merge-Whitelist aktivieren: Wenn es eine Merge-Whitelist gibt, musst du darin sein.
Genehmigungen müssen größer als 0 sein: Dann... musst du einen anderen Benutzer kompromittieren.
Genehmigungen auf Whitelist beschränken: Wenn nur Benutzer auf der Whitelist genehmigen können... musst du einen anderen Benutzer kompromittieren, der in dieser Liste ist.
Veraltete Genehmigungen zurückweisen: Wenn Genehmigungen nicht mit neuen Commits entfernt werden, könntest du einen bereits genehmigten PR hijacken, um deinen Code einzufügen und den PR zu mergen.
Beachte, dass wenn du ein Org/Repo-Admin bist, du die Schutzmaßnahmen umgehen kannst.
Webhooks sind in der Lage, spezifische Gitea-Informationen an bestimmte Orte zu senden. Du könntest in der Lage sein, diese Kommunikation auszunutzen. Allerdings wird normalerweise ein Geheimnis, das du nicht abrufen kannst, im Webhook festgelegt, das verhindert, dass externe Benutzer, die die URL des Webhooks, aber nicht das Geheimnis kennen, diesen Webhook ausnutzen. Aber in einigen Fällen setzen Leute anstelle des Setzens des Geheimnisses an seinem Platz, sie setzen es in die URL als Parameter, sodass das Überprüfen der URLs dir ermöglichen könnte, Geheimnisse und andere Orte zu finden, die du weiter ausnutzen könntest.
Webhooks können auf Repo- und Org-Ebene festgelegt werden.
Wenn du es irgendwie geschafft hast, in den Server zu gelangen, auf dem Gitea läuft, solltest du nach der Gitea-Konfigurationsdatei suchen. Standardmäßig befindet sie sich in /data/gitea/conf/app.ini
.
In dieser Datei kannst du Schlüssel und Passwörter finden.
Im Gitea-Pfad (standardmäßig: /data/gitea) kannst du auch interessante Informationen finden wie:
Die sqlite DB: Wenn Gitea keine externe DB verwendet, wird es eine sqlite DB verwenden.
Die Sitzungen im Sitzungsordner: Durch Ausführen von cat sessions/*/*/*
kannst du die Benutzernamen der angemeldeten Benutzer sehen (Gitea könnte auch die Sitzungen in der DB speichern).
Der jwt private key im jwt-Ordner.
Weitere sensible Informationen könnten in diesem Ordner gefunden werden.
Wenn du im Server bist, kannst du auch die gitea
-Binary verwenden, um Informationen zuzugreifen/zu ändern:
gitea dump
wird Gitea dumpen und eine .zip-Datei generieren.
gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET
wird ein Token des angegebenen Typs (Persistenz) generieren.
gitea admin user change-password --username admin --password newpassword
Ändere das Passwort.
gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token
Erstelle einen neuen Admin-Benutzer und erhalte ein Zugriffstoken.
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)