Basic Gitea Information
Impara e pratica AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica GCP Hacking: 
HackTricks Training GCP Red Team Expert (GRTE)
Struttura di Base
La struttura di base dell'ambiente Gitea è raggruppare i repo per organizzazione(i), ognuna delle quali può contenere diversi repository e diversi team. Tuttavia, nota che proprio come in github gli utenti possono avere repo al di fuori dell'organizzazione.
Inoltre, un utente può essere membro di diverse organizzazioni. All'interno dell'organizzazione l'utente può avere diversi permessi su ciascun repository.
Un utente può anche far parte di diversi team con diversi permessi su diversi repo.
E infine i repository possono avere meccanismi di protezione speciali.
Permessi
Organizzazioni
Quando viene creata un'organizzazione viene creato un team chiamato Owners e l'utente viene inserito al suo interno. Questo team darà accesso amministrativo sull'organizzazione, quei permessi e il nome del team non possono essere modificati.
Gli Org admin (proprietari) possono selezionare la visibilità dell'organizzazione:
Pubblica
Limitata (solo utenti loggati)
Privata (solo membri)
Gli Org admin possono anche indicare se gli admin del repo possono aggiungere e/o rimuovere l'accesso per i team. Possono anche indicare il numero massimo di repo.
Quando si crea un nuovo team, vengono selezionate diverse impostazioni importanti:
Viene indicato i repo dell'org a cui i membri del team potranno accedere: repo specifici (repo in cui il team è aggiunto) o tutti.
Viene anche indicato se i membri possono creare nuovi repo (il creatore avrà accesso amministrativo ad esso)
I permessi che i membri del repo avranno:
Accesso Amministratore
Accesso Specifico:
Team & Utenti
In un repo, l'org admin e gli admin del repo (se consentito dall'org) possono gestire i ruoli assegnati ai collaboratori (altri utenti) e ai team. Ci sono 3 possibili ruoli:
Amministratore
Scrittura
Lettura
Autenticazione Gitea
Accesso Web
Utilizzando username + password e potenzialmente (e consigliato) una 2FA.
Chiavi SSH
Puoi configurare il tuo account con una o più chiavi pubbliche permettendo alla relativa chiave privata di eseguire azioni per tuo conto. http://localhost:3000/user/settings/keys
Chiavi GPG
Non puoi impersonare l'utente con queste chiavi, ma se non le usi potrebbe essere possibile che tu venga scoperto per aver inviato commit senza una firma.
Token di Accesso Personale
Puoi generare un token di accesso personale per dare a un'applicazione accesso al tuo account. Un token di accesso personale dà pieno accesso al tuo account: http://localhost:3000/user/settings/applications
Applicazioni Oauth
Proprio come i token di accesso personale, le applicazioni Oauth avranno accesso completo al tuo account e ai luoghi a cui il tuo account ha accesso perché, come indicato nei docs, gli scope non sono ancora supportati:
Chiavi di Deploy
Le chiavi di deploy possono avere accesso in sola lettura o scrittura al repo, quindi potrebbero essere interessanti per compromettere repo specifici.
Protezioni dei Branch
Le protezioni dei branch sono progettate per non dare il controllo completo di un repository agli utenti. L'obiettivo è mettere diversi metodi di protezione prima di poter scrivere codice all'interno di qualche branch.
Le protezioni dei branch di un repository possono essere trovate in https://localhost:3000/<orgname>/<reponame>/settings/branches
Non è possibile impostare una protezione del branch a livello di organizzazione. Quindi tutte devono essere dichiarate su ciascun repo.
Diverse protezioni possono essere applicate a un branch (come a master):
Disabilita Push: Nessuno può fare push su questo branch
Abilita Push: Chiunque con accesso può fare push, ma non forzare il push.
Whitelist Restricted Push: Solo utenti/team selezionati possono fare push su questo branch (ma non forzare il push)
Abilita Merge Whitelist: Solo utenti/team in whitelist possono unire PR.
Abilita controlli di stato: Richiedi che i controlli di stato passino prima di unire.
Richiedi approvazioni: Indica il numero di approvazioni richieste prima che una PR possa essere unita.
Limita approvazioni a utenti in whitelist: Indica utenti/team che possono approvare PR.
Blocca merge su revisioni rifiutate: Se vengono richieste modifiche, non può essere unita (anche se gli altri controlli passano)
Blocca merge su richieste di revisione ufficiali: Se ci sono richieste di revisione ufficiali non può essere unita
Annulla approvazioni obsolete: Quando ci sono nuovi commit, le vecchie approvazioni verranno annullate.
Richiedi commit firmati: I commit devono essere firmati.
Blocca merge se la pull request è obsoleta
Pattern di file protetti/non protetti: Indica pattern di file da proteggere/non proteggere contro le modifiche
Come puoi vedere, anche se sei riuscito a ottenere alcune credenziali di un utente, i repo potrebbero essere protetti impedendoti di fare push di codice su master per esempio per compromettere la pipeline CI/CD.
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Last updated