# Sécurité de Gitea

{{#include ../../banners/hacktricks-training.md}}

## Qu'est-ce que Gitea

**Gitea** est une solution **d'hébergement de code léger gérée par la communauté et auto-hébergée** écrite en Go.

![](<../../images/image (160).png>)

### Informations de base

{{#ref}}
basic-gitea-information.md
{{#endref}}

## Laboratoire

Pour exécuter une instance Gitea localement, vous pouvez simplement exécuter un conteneur docker :
```bash
docker run -p 3000:3000 gitea/gitea
```
Connectez-vous au port 3000 pour accéder à la page web.

Vous pouvez également l'exécuter avec kubernetes :
```
helm repo add gitea-charts https://dl.gitea.io/charts/
helm install gitea gitea-charts/gitea
```
## Énumération non authentifiée

- Repos publics : [http://localhost:3000/explore/repos](http://localhost:3000/explore/repos)
- Utilisateurs enregistrés : [http://localhost:3000/explore/users](http://localhost:3000/explore/users)
- Organisations enregistrées : [http://localhost:3000/explore/organizations](http://localhost:3000/explore/organizations)

Notez qu'en **default Gitea permet aux nouveaux utilisateurs de s'inscrire**. Cela ne donnera pas un accès particulièrement intéressant aux nouveaux utilisateurs sur les repos d'autres organisations/utilisateurs, mais un **utilisateur connecté** pourrait être en mesure de **visualiser plus de repos ou d'organisations**.

## Exploitation interne

Pour ce scénario, nous allons supposer que vous avez obtenu un accès à un compte github.

### Avec les identifiants de l'utilisateur / Cookie Web

Si vous avez d'une manière ou d'une autre déjà des identifiants pour un utilisateur au sein d'une organisation (ou si vous avez volé un cookie de session), vous pouvez **simplement vous connecter** et vérifier quels **permissions vous avez** sur quels **repos,** dans **quelles équipes** vous êtes, **lister d'autres utilisateurs**, et **comment les repos sont protégés.**

Notez que **2FA peut être utilisé** donc vous ne pourrez accéder à ces informations que si vous pouvez également **passer cette vérification**.

> [!NOTE]
> Notez que si vous **réussissez à voler le cookie `i_like_gitea`** (actuellement configuré avec SameSite: Lax), vous pouvez **complètement usurper l'identité de l'utilisateur** sans avoir besoin d'identifiants ou de 2FA.

### Avec la clé SSH de l'utilisateur

Gitea permet aux **utilisateurs** de définir des **clés SSH** qui seront utilisées comme **méthode d'authentification pour déployer du code** en leur nom (aucune 2FA n'est appliquée).

Avec cette clé, vous pouvez effectuer des **modifications dans les dépôts où l'utilisateur a des privilèges**, cependant vous ne pouvez pas l'utiliser pour accéder à l'API gitea afin d'énumérer l'environnement. Cependant, vous pouvez **énumérer les paramètres locaux** pour obtenir des informations sur les repos et l'utilisateur auquel vous avez accès :
```bash
# Go to the the repository folder
# Get repo config and current user name and email
git config --list
```
Si l'utilisateur a configuré son nom d'utilisateur comme son nom d'utilisateur gitea, vous pouvez accéder aux **clés publiques qu'il a définies** dans son compte à _https://github.com/\<gitea_username>.keys_, vous pouvez vérifier cela pour confirmer que la clé privée que vous avez trouvée peut être utilisée.

Les **clés SSH** peuvent également être définies dans les dépôts en tant que **clés de déploiement**. Quiconque ayant accès à cette clé pourra **lancer des projets à partir d'un dépôt**. En général, sur un serveur avec différentes clés de déploiement, le fichier local **`~/.ssh/config`** vous donnera des informations sur la clé à laquelle il est lié.

#### Clés GPG

Comme expliqué [**ici**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/gitea-security/broken-reference/README.md), il est parfois nécessaire de signer les commits sinon vous pourriez être découvert.

Vérifiez localement si l'utilisateur actuel a une clé avec :
```shell
gpg --list-secret-keys --keyid-format=long
```
### Avec le jeton utilisateur

Pour une introduction sur [**les jetons utilisateur, consultez les informations de base**](basic-gitea-information.md#personal-access-tokens).

Un jeton utilisateur peut être utilisé **au lieu d'un mot de passe** pour **s'authentifier** contre le serveur Gitea [**via l'API**](https://try.gitea.io/api/swagger#/). Il aura **un accès complet** sur l'utilisateur.

### Avec l'application Oauth

Pour une introduction sur [**les applications Oauth de Gitea, consultez les informations de base**](./#with-oauth-application).

Un attaquant pourrait créer une **application Oauth malveillante** pour accéder aux données/actions privilégiées des utilisateurs qui les acceptent probablement dans le cadre d'une campagne de phishing.

Comme expliqué dans les informations de base, l'application aura **un accès complet sur le compte utilisateur**.

### Contournement de la protection des branches

Dans Github, nous avons **github actions** qui, par défaut, obtiennent un **jeton avec un accès en écriture** sur le dépôt qui peut être utilisé pour **contourner les protections de branche**. Dans ce cas, cela **n'existe pas**, donc les contournements sont plus limités. Mais examinons ce qui peut être fait :

- **Activer le push** : Si quelqu'un avec un accès en écriture peut pousser vers la branche, poussez simplement vers celle-ci.
- **Liste blanche des push restreints** : De la même manière, si vous faites partie de cette liste, poussez vers la branche.
- **Activer la liste blanche de fusion** : S'il y a une liste blanche de fusion, vous devez en faire partie.
- **Exiger que les approbations soient supérieures à 0** : Alors... vous devez compromettre un autre utilisateur.
- **Restreindre les approbations aux utilisateurs sur liste blanche** : Si seuls les utilisateurs sur liste blanche peuvent approuver... vous devez compromettre un autre utilisateur qui est dans cette liste.
- **Rejeter les approbations obsolètes** : Si les approbations ne sont pas supprimées avec de nouveaux commits, vous pourriez détourner une PR déjà approuvée pour injecter votre code et fusionner la PR.

Notez que **si vous êtes un admin d'org/repo**, vous pouvez contourner les protections.

### Énumérer les Webhooks

Les **webhooks** sont capables d'**envoyer des informations spécifiques de gitea à certains endroits**. Vous pourriez être en mesure de **exploiter cette communication**.\
Cependant, généralement, un **secret** que vous ne pouvez **pas récupérer** est défini dans le **webhook** qui **empêchera** les utilisateurs externes qui connaissent l'URL du webhook mais pas le secret d'**exploiter ce webhook**.\
Mais dans certaines occasions, les gens au lieu de définir le **secret** à sa place, ils **le définissent dans l'URL** comme paramètre, donc **vérifier les URL** pourrait vous permettre de **trouver des secrets** et d'autres endroits que vous pourriez exploiter davantage.

Les webhooks peuvent être définis au **niveau du dépôt et au niveau de l'org**.

## Post-exploitation

### À l'intérieur du serveur

Si d'une manière ou d'une autre vous parvenez à entrer dans le serveur où gitea fonctionne, vous devriez chercher le fichier de configuration de gitea. Par défaut, il est situé dans `/data/gitea/conf/app.ini`

Dans ce fichier, vous pouvez trouver des **clés** et des **mots de passe**.

Dans le chemin gitea (par défaut : /data/gitea), vous pouvez également trouver des informations intéressantes comme :

- La base de données **sqlite** : Si gitea n'utilise pas une base de données externe, il utilisera une base de données sqlite.
- Les **sessions** dans le dossier des sessions : En exécutant `cat sessions/*/*/*`, vous pouvez voir les noms d'utilisateur des utilisateurs connectés (gitea pourrait également enregistrer les sessions dans la base de données).
- La **clé privée jwt** dans le dossier jwt.
- Plus d'**informations sensibles** pourraient être trouvées dans ce dossier.

Si vous êtes à l'intérieur du serveur, vous pouvez également **utiliser le binaire `gitea`** pour accéder/modifier des informations :

- `gitea dump` va dumper gitea et générer un fichier .zip.
- `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET` va générer un jeton du type indiqué (persistance).
- `gitea admin user change-password --username admin --password newpassword` Changer le mot de passe.
- `gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token` Créer un nouvel utilisateur admin et obtenir un jeton d'accès.

{{#include ../../banners/hacktricks-training.md}}
