Gitea Security
Was ist Gitea
Gitea ist eine selbstgehostete, von der Community verwaltete, leichte Code-Hosting-Lösung, die in Go geschrieben ist.
Grundinformationen
Labor
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:
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 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.
Internal Exploitation
Für dieses Szenario nehmen wir an, dass Sie Zugriff auf ein GitHub-Konto erhalten haben.
Mit Benutzeranmeldeinformationen/Web-Cookie
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.
Beachten Sie, dass wenn Sie es schaffen, den i_like_gitea Cookie zu stehlen (der derzeit mit SameSite: Lax konfiguriert ist), 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:
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:
Mit Benutzer-Token
Für eine Einführung über 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.
Mit Oauth-Anwendung
Für eine Einführung über 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.
Umgehung des Branch-Schutzes
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 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 müssen größer als 0 sein: 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 in dieser Liste ist.
Veraltete Genehmigungen zurückweisen: Wenn Genehmigungen nicht mit neuen Commits 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, Sie die Schutzmaßnahmen umgehen können.
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. In der Regel wird jedoch 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. 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 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.
Nach der Ausnutzung
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 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 im Server befinden, können Sie auch die gitea-Binary verwenden, um Informationen zuzugreifen/zu ändern:
gitea dumpwird Gitea dumpen und eine .zip-Datei generieren.gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRETgeneriert 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-tokenErstellt einen neuen Admin-Benutzer und erhält ein Zugriffstoken.
Last updated
