Gitea Security

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Apoya HackTricks

Revisa los planes de suscripción!
Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.
Comparte trucos de hacking enviando PRs a los repositorios de github de HackTricks y HackTricks Cloud.

Qué es Gitea

Gitea es una solución ligera de alojamiento de código autogestionada y gestionada por la comunidad escrita en Go.

Información Básica

Basic Gitea Information

Laboratorio

Para ejecutar una instancia de Gitea localmente, puedes simplemente ejecutar un contenedor docker:

docker run -p 3000:3000 gitea/gitea

Conéctese al puerto 3000 para acceder a la página web.

También podría ejecutarlo con kubernetes:

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

Enumeración No Autenticada

Repos públicos: http://localhost:3000/explore/repos
Usuarios registrados: http://localhost:3000/explore/users
Organizaciones registradas: http://localhost:3000/explore/organizations

Tenga en cuenta que por defecto Gitea permite que nuevos usuarios se registren. Esto no dará acceso especialmente interesante a los nuevos usuarios sobre los repos de otras organizaciones/usuarios, pero un usuario registrado podría ser capaz de visualizar más repos o organizaciones.

Explotación Interna

Para este escenario vamos a suponer que has obtenido algún acceso a una cuenta de github.

Si de alguna manera ya tienes credenciales para un usuario dentro de una organización (o robaste una cookie de sesión) puedes simplemente iniciar sesión y verificar qué permisos tienes sobre qué repos, en qué equipos estás, listar otros usuarios, y cómo están protegidos los repos.

Tenga en cuenta que se puede usar 2FA por lo que solo podrás acceder a esta información si también puedes pasar esa verificación.

Tenga en cuenta que si logras robar la cookie i_like_gitea (actualmente configurada con SameSite: Lax) puedes suplantar completamente al usuario sin necesidad de credenciales o 2FA.

Con Clave SSH de Usuario

Gitea permite a los usuarios establecer claves SSH que se utilizarán como método de autenticación para desplegar código en su nombre (no se aplica 2FA).

Con esta clave puedes realizar cambios en los repositorios donde el usuario tiene algunos privilegios, sin embargo, no puedes usarla para acceder a la api de gitea para enumerar el entorno. Sin embargo, puedes enumerar configuraciones locales para obtener información sobre los repos y el usuario al que tienes acceso:

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

Si el usuario ha configurado su nombre de usuario como su nombre de usuario de gitea, puedes acceder a las claves públicas que ha establecido en su cuenta en https://github.com/<gitea_username>.keys, podrías verificar esto para confirmar que la clave privada que encontraste puede ser utilizada.

Las claves SSH también pueden ser establecidas en repositorios como deploy keys. Cualquiera con acceso a esta clave podrá lanzar proyectos desde un repositorio. Usualmente en un servidor con diferentes deploy keys, el archivo local ~/.ssh/config te dará información sobre la clave relacionada.

GPG Keys

Como se explica aquí a veces es necesario firmar los commits o podrías ser descubierto.

Verifica localmente si el usuario actual tiene alguna clave con:

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

Con Token de Usuario

Para una introducción sobre Tokens de Usuario revisa la información básica.

Un token de usuario puede ser usado en lugar de una contraseña para autenticarse contra el servidor de Gitea vía API. Tendrá acceso completo sobre el usuario.

Con Aplicación Oauth

Para una introducción sobre Aplicaciones Oauth de Gitea revisa la información básica.

Un atacante podría crear una Aplicación Oauth maliciosa para acceder a datos/acciones privilegiadas de los usuarios que las acepten, probablemente como parte de una campaña de phishing.

Como se explica en la información básica, la aplicación tendrá acceso completo sobre la cuenta del usuario.

Bypass de Protección de Ramas

En Github tenemos github actions que por defecto obtienen un token con acceso de escritura sobre el repositorio que puede ser usado para eludir las protecciones de ramas. En este caso eso no existe, por lo que los bypasses son más limitados. Pero veamos qué se puede hacer:

Habilitar Push: Si alguien con acceso de escritura puede hacer push a la rama, simplemente haz push a ella.
Lista Blanca de Push Restringido: De la misma manera, si eres parte de esta lista, haz push a la rama.
Habilitar Lista Blanca de Merge: Si hay una lista blanca de merge, necesitas estar dentro de ella.
Requerir aprobaciones mayor que 0: Entonces... necesitas comprometer a otro usuario.
Restringir aprobaciones a la lista blanca: Si solo los usuarios de la lista blanca pueden aprobar... necesitas comprometer a otro usuario que esté dentro de esa lista.
Descartar aprobaciones obsoletas: Si las aprobaciones no se eliminan con nuevos commits, podrías secuestrar un PR ya aprobado para inyectar tu código y fusionar el PR.

Ten en cuenta que si eres un administrador de la organización/repositorio puedes eludir las protecciones.

Enumerar Webhooks

Webhooks pueden enviar información específica de gitea a algunos lugares. Podrías ser capaz de explotar esa comunicación. Sin embargo, usualmente se establece un secreto que no puedes recuperar en el webhook que impedirá que usuarios externos que conozcan la URL del webhook pero no el secreto exploten ese webhook. Pero en algunas ocasiones, en lugar de establecer el secreto en su lugar, lo establecen en la URL como un parámetro, por lo que revisar las URLs podría permitirte encontrar secretos y otros lugares que podrías explotar más.

Los webhooks pueden ser establecidos a nivel de repositorio y de organización.

Post Explotación

Dentro del servidor

Si de alguna manera lograste entrar en el servidor donde se está ejecutando gitea, deberías buscar el archivo de configuración de gitea. Por defecto, está ubicado en /data/gitea/conf/app.ini

En este archivo puedes encontrar claves y contraseñas.

En la ruta de gitea (por defecto: /data/gitea) también puedes encontrar información interesante como:

La DB sqlite: Si gitea no está usando una db externa, usará una db sqlite.
Las sesiones dentro de la carpeta de sesiones: Ejecutando cat sessions/*/*/* puedes ver los nombres de usuario de los usuarios conectados (gitea también podría guardar las sesiones dentro de la DB).
La clave privada jwt dentro de la carpeta jwt.
Más información sensible podría encontrarse en esta carpeta.

Si estás dentro del servidor, también puedes usar el binario gitea para acceder/modificar información:

gitea dump volcará gitea y generará un archivo .zip.
gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET generará un token del tipo indicado (persistencia).
gitea admin user change-password --username admin --password newpassword Cambiar la contraseña.
gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token Crear un nuevo usuario administrador y obtener un token de acceso.