Gitea-Sicherheit

Reading time: 7 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Was ist Gitea

Gitea ist eine selbstgehostete, von der Community verwaltete, leichte Code-Hosting-Lösung, die in Go geschrieben ist.

Grundlegende Informationen

Basic Gitea Information

Labor

Um eine Gitea-Instanz lokal auszuführen, können Sie einfach einen Docker-Container starten:

bash
docker run -p 3000:3000 gitea/gitea

Verbinden Sie sich mit Port 3000, um auf die Webseite zuzugreifen.

Sie können es auch mit Kubernetes ausführen:

helm repo add gitea-charts https://dl.gitea.io/charts/
helm install gitea gitea-charts/gitea

Unauthentifizierte Enumeration

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.

Interne Ausnutzung

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 einen 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.

note

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.

Mit Benutzer-SSH-Schlüssel

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 zu enumerieren. Sie können jedoch lokale Einstellungen enumerieren, um Informationen über die Repos und Benutzer zu erhalten, auf die Sie Zugriff haben:

bash
# Go to the the repository folder
# Get repo config and current user name and email
git config --list

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 private Schlüssel, den Sie gefunden haben, 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.

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:

shell
gpg --list-secret-keys --keyid-format=long

Mit Benutzer-Token

Für eine Einführung über Benutzer-Token überprüfen Sie 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.

Mit Oauth-Anwendung

Für eine Einführung über Gitea 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 als Teil einer Phishing-Kampagne akzeptieren.

Wie in den grundlegenden Informationen erklärt, hat die Anwendung vollen Zugriff auf das Benutzerkonto.

Umgehung des Branch-Schutzes

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, sodass die Umgehungen eingeschränkter sind. Aber schauen wir uns an, was getan werden kann:

  • Push aktivieren: Wenn jemand mit Schreibzugriff auf den Branch pushen kann, pushen Sie einfach darauf.
  • Whitelist für eingeschränkten Push: Auf die gleiche Weise, 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.
  • Genehmigungen sind größer als 0 erforderlich: 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 zurückweisen: Wenn Genehmigungen mit neuen Commits nicht entfernt werden, könnten Sie einen bereits genehmigten PR hijacken, um Ihren Code einzufügen und den PR zu mergen.

Beachten Sie, dass wenn Sie ein Org/Repo-Admin sind, können Sie die Schutzmaßnahmen umgehen.

Webhooks auflisten

Webhooks sind in der Lage, spezifische Gitea-Informationen an bestimmte Orte zu senden. Sie könnten in der Lage sein, diese Kommunikation auszunutzen.
Allerdings wird normalerweise ein Geheimnis, das Sie nicht abrufen können, im Webhook festgelegt, das verhindert, dass externe Benutzer, die die URL des Webhooks, aber nicht das Geheimnis kennen, diesen Webhook ausnutzen.
In einigen Fällen setzen Menschen jedoch anstelle des Geheimnisses an seinem Platz, es in der 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 festgelegt werden.

Post-Exploitation

Auf dem Server

Wenn Sie es irgendwie geschafft haben, auf 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 finden Sie Schlüssel und Passwörter.

Im Gitea-Pfad (standardmäßig: /data/gitea) finden Sie auch interessante Informationen 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 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 Sie sich auf dem Server befinden, können Sie 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 generiert ein Token des angegebenen Typs (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-token erstellt einen neuen Admin-Benutzer und erhält ein Zugriffstoken.

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks