Contenido del repositorio

Entorno probado

La prueba de concepto se validó en el siguiente entorno aislado:

La explotación exitosa produjo una salida de comando similar a:

Requisitos previos

• Python 3.8 o posterior
• Acceso de red a la instancia de Gitea objetivo
• Una cuenta válida de Gitea con permisos de creación y escritura de repositorios, o una instancia de laboratorio objetivo con el registro público habilitado
• Un entorno de prueba explícitamente autorizado

El script solo usa la biblioteca estándar de Python y no requiere paquetes adicionales.

Uso

Ejemplo para una instancia de laboratorio local:

El script primero intenta el registro web y luego se autentica con las credenciales proporcionadas. Esto permite que el mismo comando funcione tanto con una cuenta nueva en una instancia con registro abierto como con una cuenta existente.

Análisis técnico

La cadena de explotación consta de cuatro etapas:

1. Envío de parche controlado por el atacante
   POST /api/v1/repos/{owner}/{repo}/diffpatch aplica el contenido del parche proporcionado usando git apply --index --recount --cached --binary --ignore-whitespace --whitespace=fix -3 dentro de un clon temporal.

2. Colocación de la ruta del hook
   El repositorio temporal se crea como un clon bare compartido. En un repositorio bare, la raíz del repositorio también es $GIT_DIR; en consecuencia, la ruta del parche hooks/post-index-change se resuelve dentro del directorio de hooks activo de Git.

3. Materialización del hook ejecutable
   El mismo parche se envía dos veces. La segunda aplicación produce un conflicto add/add, lo que provoca que el fallback de tres vías materialice la ruta en disco con modo 100755, a pesar del uso de --cached. Una actualización posterior del índice invoca post-index-change, ejecutando el código shell inyectado como la cuenta de servicio de Gitea.

4. Recuperación de salida nativa de Git
   El hook identifica el repositorio de origen a través de objects/info/alternates, almacena la salida del comando como un blob de Git, crea un árbol y un commit, y actualiza refs/heads/output-leak. La prueba de concepto luego recupera el resultado a través de la API de archivos raw de Gitea. Esta técnica no requiere una conexión saliente directa desde el objetivo.

Impacto

La explotación exitosa otorga ejecución de comandos con los privilegios de la cuenta de servicio de Gitea. Dependiendo de la configuración del despliegue, un atacante podría acceder a:

• app.ini y credenciales de la base de datos
• SECRET_KEY, INTERNAL_TOKEN y secretos relacionados con LFS
• Repositorios montados o legibles por el proceso de Gitea
• Variables de entorno del proceso
• Servicios internos accesibles desde el host o contenedor de Gitea

Se confirmó que la cuenta de laboratorio tenía acceso de lectura a app.ini.

Indicadores de compromiso

Los defensores deben investigar los siguientes artefactos y patrones de solicitudes:

• Dos solicitudes idénticas o casi idénticas a /api/v1/repos/*/*/diffpatch en rápida sucesión
• Una rama llamada output-leak
• Commits autorados por poc <[email protected]>
• Archivos ejecutables inesperados llamados hooks/post-index-change en repositorios bare o directorios de clones temporales
• Actividad sospechosa bajo rutas como /data/gitea/tmp/local-repo/upload.git*

Estos indicadores describen la prueba de concepto incluida y no son exhaustivos; un exploit modificado podría usar rutas, refs, identidades o canales de salida diferentes.

Remediación y mitigación

1. Actualice a Gitea 1.27.1 o posterior. Esta es la remediación recomendada. La corrección cambia el flujo de trabajo afectado para usar un clon temporal no bare.
2. Restrinja la API diffpatch en el proxy inverso hasta que se complete la actualización, por ejemplo, denegando el acceso a rutas coincidentes /api/v1/.../diffpatch. Valide la regla contra integraciones legítimas antes del despliegue.
3. Deshabilite el registro público estableciendo DISABLE_REGISTRATION=true si no es operativamente necesario. Esto reduce la accesibilidad no autenticada pero no protege contra usuarios existentes con acceso de escritura a repositorios.
4. Revise los registros y las refs de los repositorios en busca de los indicadores anteriores, y rote las credenciales o secretos accesibles a la cuenta de Gitea si se sospecha un compromiso.

Para el contenedor de laboratorio usado en esta investigación, la eliminación se puede realizar con:

Uso responsable

Este material se proporciona para ayudar a los defensores a reproducir, comprender, detectar y remediar la vulnerabilidad. Los operadores deben probar solo en entornos aislados y seguir los requisitos de autorización y divulgación de su organización.