Gitea Security
Lerne & übe AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: 
HackTricks Training GCP Red Team Expert (GRTE)
Was ist Gitea
Gitea ist eine selbstgehostete, community-gemanagte, leichtgewichtige Code-Hosting-Lösung, die in Go geschrieben ist.
Grundlegende Informationen
Basic Gitea InformationLabor
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önnten es auch mit Kubernetes ausführen:
Unauthenticated Enumeration
Ö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 gibt den neuen Benutzern keinen besonders interessanten Zugriff auf die Repos anderer Organisationen/Benutzer, aber ein eingeloggter Benutzer könnte in der Lage sein, mehr Repos oder Organisationen zu visualisieren.
Internal Exploitation
Für dieses Szenario nehmen wir an, dass Sie Zugang zu einem github-Konto erhalten haben.
Mit Benutzeranmeldedaten/Web-Cookie
Wenn Sie irgendwie bereits Anmeldedaten für einen Benutzer innerhalb einer Organisation haben (oder Sie haben ein Sitzungscookie gestohlen), können Sie sich einfach einloggen und überprüfen, welche Berechtigungen Sie haben über 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 nur auf diese Informationen zugreifen können, wenn Sie auch diese Überprüfung 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 imitieren, ohne Anmeldedaten oder 2FA zu benötigen.
Mit Benutzer-SSH-Schlüssel
Gitea erlaubt Benutzern, SSH-Schlüssel zu setzen, die als Authentifizierungsmethode verwendet werden, um Code in ihrem Namen zu deployen (es wird keine 2FA angewendet).
Mit diesem Schlüssel können Sie Änderungen in Repositories vornehmen, in denen der Benutzer einige Privilegien hat, jedoch können Sie ihn nicht verwenden, um auf die gitea-API zuzugreifen, um die Umgebung zu enumerieren. Sie können jedoch lokale Einstellungen enumerieren, 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 gesetzt 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 gesetzt werden. Jeder, der Zugriff auf diesen Schlüssel hat, kann Projekte aus einem Repository starten. Normalerweise gibt die lokale Datei ~/.ssh/config auf einem Server mit verschiedenen Deploy-Schlüsseln Informationen darüber, welcher Schlüssel zugeordnet ist.
GPG-Schlüssel
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:
Mit Benutzer-Token
Für eine Einführung zu Benutzer-Token, siehe die grundlegenden Informationen.
Ein Benutzer-Token kann anstelle eines Passworts verwendet werden, um sich gegen den Gitea-Server zu authentifizieren via API. Es hat vollständigen Zugriff auf den Benutzer.
Mit Oauth-Anwendung
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 im Rahmen einer Phishing-Kampagne akzeptieren.
Wie in den grundlegenden Informationen erklärt, hat die Anwendung vollständigen Zugriff auf das Benutzerkonto.
Branch-Schutz-Umgehung
In Github haben wir github actions, die standardmäßig ein Token mit Schreibzugriff auf das Repository erhalten, das verwendet werden kann, um Branch-Schutzmaßnahmen zu umgehen. In diesem Fall existiert das nicht, daher sind die Umgehungen begrenzter. Aber schauen wir uns an, was getan werden kann:
Push aktivieren: Wenn jemand mit Schreibzugriff auf den Branch pushen kann, einfach pushen.
Whitelist-Eingeschränkter Push: Ebenso, wenn Sie Teil dieser Liste sind, pushen Sie auf den Branch.
Merge-Whitelist aktivieren: Wenn es eine Merge-Whitelist gibt, müssen Sie darin sein.
Erforderliche Genehmigungen größer als 0: Dann... müssen Sie einen anderen Benutzer kompromittieren.
Genehmigungen auf Whitelist beschränken: Wenn nur Benutzer auf der Whitelist genehmigen können... müssen Sie einen anderen Benutzer kompromittieren, der auf dieser Liste steht.
Veraltete Genehmigungen aufheben: Wenn Genehmigungen bei neuen Commits nicht entfernt werden, könnten Sie eine bereits genehmigte PR kapern, um Ihren Code einzuschleusen und die PR zu mergen.
Beachten Sie, dass wenn Sie ein Org/Repo-Admin sind, können Sie die Schutzmaßnahmen umgehen.
Webhooks auflisten
Webhooks können spezifische Gitea-Informationen an bestimmte Orte senden. Sie könnten in der Lage sein, diese Kommunikation auszunutzen. Normalerweise wird jedoch ein Geheimnis gesetzt, das Sie nicht abrufen können, um externe Benutzer, die die URL des Webhooks kennen, aber nicht das Geheimnis, daran zu hindern, diesen Webhook auszunutzen. Aber in einigen Fällen setzen Leute das Geheimnis nicht an die richtige Stelle, sondern in die URL als Parameter, sodass das Überprüfen der URLs Ihnen ermöglichen könnte, Geheimnisse und andere Orte zu finden, die Sie weiter ausnutzen könnten.
Webhooks können auf Repo- und Org-Ebene gesetzt werden.
Post-Exploitation
Innerhalb des Servers
Wenn Sie es irgendwie geschafft haben, in den Server zu gelangen, auf dem Gitea läuft, sollten Sie nach der Gitea-Konfigurationsdatei suchen. Standardmäßig befindet sie sich in /data/gitea/conf/app.ini.
In dieser Datei können Sie Schlüssel und Passwörter finden.
Im Gitea-Pfad (standardmäßig: /data/gitea) können Sie 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/*/*/*können Sie die Benutzernamen der angemeldeten Benutzer sehen (Gitea könnte die Sitzungen auch in der DB speichern).Der jwt private key im jwt-Ordner.
Weitere sensible Informationen könnten in diesem Ordner gefunden werden.
Wenn Sie sich auf dem Server befinden, können Sie auch das gitea-Binary verwenden, um auf Informationen zuzugreifen/Informationen zu ändern:
gitea dumpwird Gitea dumpen und eine .zip-Datei erstellen.gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRETwird ein Token des angegebenen Typs generieren (Persistenz).gitea admin user change-password --username admin --password newpasswordÄndert das Passwort.gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-tokenErstellt einen neuen Admin-Benutzer und erhält ein Zugriffstoken.
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Last updated