Gitea Security

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

What is Gitea

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

Basic Information

Basic Gitea Information

Lab

Para ejecutar una instancia de Gitea localmente, solo puedes ejecutar un contenedor de 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

Ten en cuenta que por defecto Gitea permite que nuevos usuarios se registren. Esto no dará un acceso especialmente interesante a los nuevos usuarios sobre otros repos de organizaciones/usuarios, pero un usuario autenticado podría visualizar más repos u 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.

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

Ten 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 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 se pueden establecer en los repositorios como claves de despliegue. Cualquiera con acceso a esta clave podrá lanzar proyectos desde un repositorio. Usualmente, en un servidor con diferentes claves de despliegue, el archivo local ~/.ssh/config te dará información sobre a qué clave está relacionada.

Claves GPG

Como se explicó 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 consulta la información básica.

Un token de usuario puede ser utilizado en lugar de una contraseña para autenticarse contra el servidor de Gitea a través de la API. tendrá acceso completo sobre el usuario.

Con Aplicación Oauth

Para una introducción sobre Aplicaciones Oauth de Gitea consulta 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 probablemente la acepten como parte de una campaña de phishing.

Como se explicó en la información básica, la aplicación tendrá acceso total 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 utilizado para eludir las protecciones de ramas. En este caso eso no existe, por lo que los bypass 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.
Whitelist Restricted Push: De la misma manera, si eres parte de esta lista haz push a la rama.
Habilitar Merge Whitelist: Si hay una lista blanca de merges, necesitas estar dentro de ella.
Requerir aprobaciones es mayor que 0: Entonces... necesitas comprometer a otro usuario.
Restringir aprobaciones a los que están en la lista blanca: Si solo los usuarios en la lista blanca pueden aprobar... necesitas comprometer a otro usuario que esté dentro de esa lista.
Desestimar 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 org/repositorio puedes eludir las protecciones.

Enumerar Webhooks

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

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 se encuentra 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 base de datos sqlite: Si gitea no está utilizando una base de datos externa, utilizará una base de datos 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 base de datos).
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 Cambia la contraseña.
gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token Crea un nuevo usuario administrador y obtiene un token de acceso.