# Sicurezza di Gitea

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

## Cos'è Gitea

**Gitea** è una soluzione di **hosting di codice leggero gestita dalla comunità e self-hosted** scritta in Go.

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

### Informazioni di base

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

## Laboratorio

Per eseguire un'istanza di Gitea localmente, puoi semplicemente eseguire un container docker:
```bash
docker run -p 3000:3000 gitea/gitea
```
Collegati alla porta 3000 per accedere alla pagina web.

Puoi anche eseguirlo con kubernetes:
```
helm repo add gitea-charts https://dl.gitea.io/charts/
helm install gitea gitea-charts/gitea
```
## Enumerazione non autenticata

- Repos pubblici: [http://localhost:3000/explore/repos](http://localhost:3000/explore/repos)
- Utenti registrati: [http://localhost:3000/explore/users](http://localhost:3000/explore/users)
- Organizzazioni registrate: [http://localhost:3000/explore/organizations](http://localhost:3000/explore/organizations)

Nota che per **default Gitea consente a nuovi utenti di registrarsi**. Questo non darà accesso particolarmente interessante ai nuovi utenti su altri repos di organizzazioni/utenti, ma un **utente autenticato** potrebbe essere in grado di **visualizzare più repos o organizzazioni**.

## Sfruttamento Interno

Per questo scenario supponiamo che tu abbia ottenuto un certo accesso a un account github.

### Con Credenziali Utente/Cookie Web

Se in qualche modo hai già le credenziali per un utente all'interno di un'organizzazione (o hai rubato un cookie di sessione) puoi **semplicemente accedere** e controllare quali **permessi hai** su quali **repos,** in **quali team** sei, **elencare altri utenti**, e **come sono protetti i repos.**

Nota che **2FA potrebbe essere utilizzato** quindi potrai accedere a queste informazioni solo se riesci anche a **superare quel controllo**.

> [!NOTE]
> Nota che se **riesci a rubare il cookie `i_like_gitea`** (attualmente configurato con SameSite: Lax) puoi **completamente impersonare l'utente** senza bisogno di credenziali o 2FA.

### Con Chiave SSH Utente

Gitea consente agli **utenti** di impostare **chiavi SSH** che verranno utilizzate come **metodo di autenticazione per distribuire codice** per loro conto (non viene applicata 2FA).

Con questa chiave puoi effettuare **modifiche nei repository dove l'utente ha alcuni privilegi**, tuttavia non puoi usarla per accedere all'api di gitea per enumerare l'ambiente. Tuttavia, puoi **enumerare le impostazioni locali** per ottenere informazioni sui repos e sugli utenti a cui hai accesso:
```bash
# Go to the the repository folder
# Get repo config and current user name and email
git config --list
```
Se l'utente ha configurato il proprio nome utente come il suo nome utente gitea, puoi accedere alle **chiavi pubbliche che ha impostato** nel suo account in _https://github.com/\<gitea_username>.keys_, puoi controllare questo per confermare che la chiave privata che hai trovato può essere utilizzata.

**Le chiavi SSH** possono anche essere impostate nei repository come **chiavi di distribuzione**. Chiunque abbia accesso a questa chiave sarà in grado di **lanciare progetti da un repository**. Di solito, in un server con diverse chiavi di distribuzione, il file locale **`~/.ssh/config`** ti darà informazioni su quale chiave è correlata.

#### Chiavi GPG

Come spiegato [**qui**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/gitea-security/broken-reference/README.md), a volte è necessario firmare i commit o potresti essere scoperto.

Controlla localmente se l'utente corrente ha qualche chiave con:
```shell
gpg --list-secret-keys --keyid-format=long
```
### Con Token Utente

Per un'introduzione sui [**Token Utente controlla le informazioni di base**](basic-gitea-information.md#personal-access-tokens).

Un token utente può essere utilizzato **invece di una password** per **autenticarsi** contro il server Gitea [**via API**](https://try.gitea.io/api/swagger#/). avrà **accesso completo** sull'utente.

### Con Applicazione Oauth

Per un'introduzione sulle [**Applicazioni Oauth di Gitea controlla le informazioni di base**](./#with-oauth-application).

Un attaccante potrebbe creare un'**Applicazione Oauth malevola** per accedere a dati/azioni privilegiati degli utenti che le accettano probabilmente come parte di una campagna di phishing.

Come spiegato nelle informazioni di base, l'applicazione avrà **accesso completo all'account utente**.

### Bypass della Protezione dei Branch

In Github abbiamo le **github actions** che per impostazione predefinita ottengono un **token con accesso in scrittura** sul repo che può essere utilizzato per **bypassare le protezioni dei branch**. In questo caso che **non esistono**, quindi i bypass sono più limitati. Ma diamo un'occhiata a cosa si può fare:

- **Abilita Push**: Se chiunque con accesso in scrittura può pushare sul branch, basta pushare.
- **Whitelist Pus**h Riservati: Allo stesso modo, se fai parte di questa lista push sul branch.
- **Abilita Whitelist Merge**: Se c'è una whitelist di merge, devi essere all'interno.
- **Richiedi approvazioni maggiori di 0**: Allora... devi compromettere un altro utente.
- **Restrigi approvazioni a utenti in whitelist**: Se solo gli utenti in whitelist possono approvare... devi compromettere un altro utente che è all'interno di quella lista.
- **Annulla approvazioni scadute**: Se le approvazioni non vengono rimosse con nuovi commit, potresti dirottare una PR già approvata per iniettare il tuo codice e unire la PR.

Nota che **se sei un admin di org/repo** puoi bypassare le protezioni.

### Enumerare Webhook

I **Webhook** sono in grado di **inviare informazioni specifiche di gitea in alcuni luoghi**. Potresti essere in grado di **sfruttare quella comunicazione**.\
Tuttavia, di solito un **segreto** che non puoi **recuperare** è impostato nel **webhook** che **previene** agli utenti esterni che conoscono l'URL del webhook ma non il segreto di **sfruttare quel webhook**.\
Ma in alcune occasioni, le persone invece di impostare il **segreto** al suo posto, lo **impostano nell'URL** come parametro, quindi **controllare gli URL** potrebbe permetterti di **trovare segreti** e altri luoghi che potresti sfruttare ulteriormente.

I webhook possono essere impostati a **livello di repo e di org**.

## Post Sfruttamento

### All'interno del server

Se in qualche modo sei riuscito a entrare nel server dove gitea è in esecuzione, dovresti cercare il file di configurazione di gitea. Per impostazione predefinita si trova in `/data/gitea/conf/app.ini`

In questo file puoi trovare **chiavi** e **password**.

Nel percorso gitea (per impostazione predefinita: /data/gitea) puoi trovare anche informazioni interessanti come:

- Il DB **sqlite**: Se gitea non utilizza un db esterno utilizzerà un db sqlite.
- Le **sessioni** all'interno della cartella delle sessioni: Eseguendo `cat sessions/*/*/*` puoi vedere i nomi utente degli utenti connessi (gitea potrebbe anche salvare le sessioni all'interno del DB).
- La **chiave privata jwt** all'interno della cartella jwt.
- Maggiore **informazione sensibile** potrebbe essere trovata in questa cartella.

Se sei all'interno del server puoi anche **utilizzare il binario `gitea`** per accedere/modificare informazioni:

- `gitea dump` eseguirà il dump di gitea e genererà un file .zip.
- `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET` genererà un token del tipo indicato (persistenza).
- `gitea admin user change-password --username admin --password newpassword` Cambia la password.
- `gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token` Crea un nuovo utente admin e ottieni un token di accesso.

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