Italian - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Basic Github Information

Supporta HackTricks

Struttura di Base

La struttura di base dell'ambiente github di una grande azienda è possedere un enterprise che possiede diverse organizzazioni e ognuna di esse può contenere diversi repository e diversi team. Le aziende più piccole possono semplicemente possedere un'organizzazione e nessun enterprise.

Dal punto di vista di un utente, un utente può essere un membro di diversi enterprise e organizzazioni. All'interno di esse, l'utente può avere diversi ruoli di enterprise, organizzazione e repository.

Inoltre, un utente può essere parte di diversi team con diversi ruoli di enterprise, organizzazione o repository.

E infine, i repository possono avere meccanismi di protezione speciali.

Privilegi

Ruoli di Enterprise

  • Proprietario dell'enterprise: Le persone con questo ruolo possono gestire gli amministratori, gestire le organizzazioni all'interno dell'enterprise, gestire le impostazioni dell'enterprise, applicare politiche tra le organizzazioni. Tuttavia, non possono accedere alle impostazioni o ai contenuti dell'organizzazione a meno che non vengano nominati proprietari dell'organizzazione o non ricevano accesso diretto a un repository di proprietà dell'organizzazione.

  • Membri dell'enterprise: I membri delle organizzazioni possedute dal tuo enterprise sono anche automaticamente membri dell'enterprise.

Ruoli di Organizzazione

In un'organizzazione, gli utenti possono avere diversi ruoli:

  • Proprietari dell'organizzazione: I proprietari dell'organizzazione hanno accesso amministrativo completo alla tua organizzazione. Questo ruolo dovrebbe essere limitato, ma non a meno di due persone, nella tua organizzazione.

  • Membri dell'organizzazione: Il ruolo predefinito, non amministrativo per le persone in un'organizzazione è il membro dell'organizzazione. Per impostazione predefinita, i membri dell'organizzazione hanno un certo numero di permessi.

  • Gestori della fatturazione: I gestori della fatturazione sono utenti che possono gestire le impostazioni di fatturazione per la tua organizzazione, come le informazioni di pagamento.

  • Gestori della sicurezza: È un ruolo che i proprietari dell'organizzazione possono assegnare a qualsiasi team in un'organizzazione. Quando applicato, dà a ogni membro del team i permessi per gestire avvisi e impostazioni di sicurezza nella tua organizzazione, così come permessi di lettura per tutti i repository nell'organizzazione.

  • Se la tua organizzazione ha un team di sicurezza, puoi utilizzare il ruolo di gestore della sicurezza per dare ai membri del team il minimo accesso di cui hanno bisogno all'organizzazione.

  • Gestori delle App Github: Per consentire ad utenti aggiuntivi di gestire le App GitHub di proprietà di un'organizzazione, un proprietario può concedere loro i permessi di gestore delle App GitHub.

  • Collaboratori esterni: Un collaboratore esterno è una persona che ha accesso a uno o più repository dell'organizzazione ma non è esplicitamente un membro dell'organizzazione.

Puoi confrontare i permessi di questi ruoli in questa tabella: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles

Privilegi dei Membri

In https://github.com/organizations/<org_name>/settings/member_privileges puoi vedere i permessi che gli utenti avranno solo per essere parte dell'organizzazione.

Le impostazioni qui configurate indicheranno i seguenti permessi dei membri dell'organizzazione:

  • Essere admin, scrittore, lettore o nessun permesso su tutti i repository dell'organizzazione.

  • Se i membri possono creare repository privati, interni o pubblici.

  • Se è possibile forkare i repository.

  • Se è possibile invitare collaboratori esterni.

  • Se siti pubblici o privati possono essere pubblicati.

  • I permessi che gli admin hanno sui repository.

  • Se i membri possono creare nuovi team.

Ruoli di Repository

Per impostazione predefinita, i ruoli di repository sono creati:

  • Lettura: Raccomandato per contributori non di codice che vogliono visualizzare o discutere il tuo progetto.

  • Triage: Raccomandato per contributori che devono gestire proattivamente problemi e richieste di pull senza accesso in scrittura.

  • Scrittura: Raccomandato per i contributori che spingono attivamente al tuo progetto.

  • Manutenzione: Raccomandato per project manager che devono gestire il repository senza accesso a azioni sensibili o distruttive.

  • Admin: Raccomandato per le persone che hanno bisogno di accesso completo al progetto, comprese azioni sensibili e distruttive come gestire la sicurezza o eliminare un repository.

Puoi confrontare i permessi di ciascun ruolo in questa tabella https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role

Puoi anche creare i tuoi ruoli in https://github.com/organizations/<org_name>/settings/roles

Team

Puoi elencare i team creati in un'organizzazione in https://github.com/orgs/<org_name>/teams. Nota che per vedere i team che sono figli di altri team devi accedere a ciascun team genitore.

Utenti

Gli utenti di un'organizzazione possono essere elencati in https://github.com/orgs/<org_name>/people.

Nelle informazioni di ciascun utente puoi vedere i team di cui l'utente è membro e i repository a cui l'utente ha accesso.

Autenticazione Github

Github offre diversi modi per autenticarsi al tuo account e svolgere azioni per tuo conto.

Accesso Web

Accedendo a github.com puoi effettuare il login utilizzando il tuo nome utente e password (e un 2FA potenzialmente).

Chiavi SSH

Puoi configurare il tuo account con una o più chiavi pubbliche che consentono alla relativa chiave privata di eseguire azioni per tuo conto. https://github.com/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. Scopri di più su modalità vigile qui.

Token di Accesso Personali

Puoi generare un token di accesso personale per dare a un'applicazione accesso al tuo account. Quando crei un token di accesso personale, l'utente deve specificare i permessi che il token avrà. https://github.com/settings/tokens

Applicazioni Oauth

Le applicazioni Oauth possono chiederti permessi per accedere a parte delle tue informazioni github o per impersonarti per eseguire alcune azioni. Un esempio comune di questa funzionalità è il pulsante di accesso con github che potresti trovare in alcune piattaforme.

Alcuni consigli di sicurezza:

  • Un OAuth App dovrebbe sempre agire come l'utente GitHub autenticato in tutto GitHub (ad esempio, quando fornisce notifiche agli utenti) e con accesso solo agli scope specificati.

  • Un OAuth App può essere utilizzato come fornitore di identità abilitando un "Accesso con GitHub" per l'utente autenticato.

  • Non costruire un OAuth App se desideri che la tua applicazione agisca su un singolo repository. Con lo scope repo, le OAuth Apps possono agire su _tutti_** i repository dell'utente autenticato**.

  • Non costruire un OAuth App per agire come un'applicazione per il tuo team o azienda. Le OAuth Apps si autenticano come un singolo utente, quindi se una persona crea un OAuth App per un'azienda da utilizzare, e poi lascia l'azienda, nessun altro avrà accesso ad essa.

  • Di più qui.

Applicazioni Github

Le applicazioni Github possono chiedere permessi per accedere alle tue informazioni github o impersonarti per eseguire azioni specifiche su risorse specifiche. Nelle App Github devi specificare i repository a cui l'app avrà accesso.

Alcuni consigli di sicurezza:

  • Un'App GitHub dovrebbe eseguire azioni indipendentemente da un utente (a meno che l'app non stia utilizzando un token user-to-server). Per mantenere i token di accesso user-to-server più sicuri, puoi utilizzare token di accesso che scadranno dopo 8 ore e un token di aggiornamento che può essere scambiato per un nuovo token di accesso. Per ulteriori informazioni, vedere "Aggiornamento dei token di accesso user-to-server."

  • Assicurati che l'App GitHub si integri con repository specifici.

  • L'App GitHub dovrebbe collegarsi a un account personale o a un'organizzazione.

  • Non aspettarti che l'App GitHub conosca e faccia tutto ciò che un utente può.

  • Non utilizzare un'App GitHub se hai solo bisogno di un servizio "Accesso con GitHub". Ma un'App GitHub può utilizzare un flusso di identificazione utente per accedere gli utenti e fare altre cose.

  • Non costruire un'App GitHub se vuoi solo agire come un utente GitHub e fare tutto ciò che quell'utente può fare.

  • Se stai utilizzando la tua app con GitHub Actions e desideri modificare i file di workflow, devi autenticarti per conto dell'utente con un token OAuth che include lo scope workflow. L'utente deve avere permessi di admin o scrittura nel repository che contiene il file di workflow. Per ulteriori informazioni, vedere "Comprendere gli scope per le app OAuth."

  • Di più qui.

Github Actions

Questa non è un modo per autenticarsi in github, ma una malicious Github Action potrebbe ottenere accesso non autorizzato a github e a seconda dei privilegi concessi all'Action, potrebbero essere eseguiti diversi attacchi. Vedi sotto per ulteriori informazioni.

Azioni Git

Le azioni Git consentono di automatizzare l'esecuzione di codice quando si verifica un evento. Di solito, il codice eseguito è in qualche modo correlato al codice del repository (forse costruire un container docker o controllare che la PR non contenga segreti).

Configurazione

In https://github.com/organizations/<org_name>/settings/actions è possibile controllare la configurazione delle azioni github per l'organizzazione.

È possibile vietare completamente l'uso delle azioni github, consentire tutte le azioni github, o consentire solo determinate azioni.

È anche possibile configurare chi ha bisogno di approvazione per eseguire un'azione Github e i permessi del GITHUB_TOKEN di un'azione Github quando viene eseguita.

Segreti Git

Le azioni Github di solito necessitano di qualche tipo di segreti per interagire con github o applicazioni di terze parti. Per evitare di metterli in chiaro nel repo, github consente di inserirli come Segreti.

Questi segreti possono essere configurati per il repo o per tutta l'organizzazione. Poi, affinché l'Azione possa accedere al segreto, devi dichiararlo come:

steps:
- name: Hello world action
with: # Set the secret as an input
super_secret: ${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret: ${{ secrets.SuperSecret }}

Esempio usando Bash

steps:
- shell: bash
env:
SUPER_SECRET: ${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

I segreti possono essere accessibili solo dalle Github Actions che li hanno dichiarati.

Una volta configurati nel repo o nelle organizzazioni, gli utenti di github non potranno più accedervi, potranno solo cambiarli.

Pertanto, l'unico modo per rubare i segreti di github è avere accesso alla macchina che sta eseguendo la Github Action (in quel caso potrai accedere solo ai segreti dichiarati per l'Action).

Ambienti Git

Github consente di creare ambienti in cui puoi salvare segreti. Poi, puoi dare alla github action accesso ai segreti all'interno dell'ambiente con qualcosa come:

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

Puoi configurare un ambiente per essere accessibile da tutti i rami (predefinito), solo rami protetti o specificare quali rami possono accedervi. Può anche impostare un numero di revisioni richieste prima di eseguire un'azione utilizzando un ambiente o attendere un tempo prima di consentire il proseguimento delle distribuzioni.

Git Action Runner

Un'azione Github può essere eseguita all'interno dell'ambiente github o può essere eseguita in un'infrastruttura di terze parti configurata dall'utente.

Diverse organizzazioni consentiranno di eseguire azioni Github in un'infrastruttura di terze parti poiché tende a essere più economica.

Puoi elencare i runner auto-ospitati di un'organizzazione in https://github.com/organizations/<org_name>/settings/actions/runners

Il modo per scoprire quali Github Actions vengono eseguite in infrastrutture non github è cercare runs-on: self-hosted nella configurazione yaml dell'azione Github.

Non è possibile eseguire un'azione Github di un'organizzazione all'interno di una macchina auto-ospitata di un'altra organizzazione perché un token unico viene generato per il Runner quando viene configurato per sapere a quale runner appartiene.

Se il Github Runner personalizzato è configurato in una macchina all'interno di AWS o GCP, ad esempio, l'azione potrebbe avere accesso all'endpoint dei metadati e rubare il token dell'account di servizio con cui la macchina sta funzionando.

Compromissione dell'azione Git

Se tutte le azioni (o un'azione malevola) sono consentite, un utente potrebbe utilizzare un'azione Github che è malevola e comprometterà il contenitore in cui viene eseguita.

Un'azione Github malevola eseguita potrebbe essere sfruttata dall'attaccante per:

  • Rubare tutti i segreti a cui l'azione ha accesso

  • Muoversi lateralmente se l'azione viene eseguita all'interno di un'infrastruttura di terze parti dove il token SA utilizzato per eseguire la macchina può essere accessibile (probabilmente tramite il servizio di metadati)

  • Abusare del token utilizzato dal workflow per rubare il codice del repo dove l'azione è eseguita o addirittura modificarlo.

Protezioni dei rami

Le protezioni dei rami sono progettate per non dare il controllo completo di un repository agli utenti. L'obiettivo è mettere in atto diversi metodi di protezione prima di poter scrivere codice all'interno di un ramo.

Le protezioni dei rami di un repository possono essere trovate in https://github.com/<orgname>/<reponame>/settings/branches

Non è possibile impostare una protezione del ramo a livello di organizzazione. Quindi tutte devono essere dichiarate su ciascun repo.

Diverse protezioni possono essere applicate a un ramo (come a master):

  • Puoi richiedere una PR prima di unire (quindi non puoi unire direttamente il codice sul ramo). Se questo è selezionato, possono essere in atto diverse altre protezioni:

  • Richiedere un numero di approvazioni. È molto comune richiedere l'approvazione di 1 o 2 persone in più per la tua PR in modo che un singolo utente non possa unire direttamente il codice.

  • Annullare le approvazioni quando vengono inviati nuovi commit. Altrimenti, un utente potrebbe approvare codice legittimo e poi l'utente potrebbe aggiungere codice malevolo e unirlo.

  • Richiedere revisioni dai proprietari del codice. Almeno 1 proprietario del codice del repo deve approvare la PR (quindi gli utenti "casuali" non possono approvarla)

  • Limitare chi può annullare le revisioni delle richieste di pull. Puoi specificare persone o team autorizzati ad annullare le revisioni delle richieste di pull.

  • Consentire a determinati attori di bypassare i requisiti delle richieste di pull. Questi utenti saranno in grado di bypassare le restrizioni precedenti.

  • Richiedere che i controlli di stato passino prima di unire. Alcuni controlli devono passare prima di poter unire il commit (come un'azione github che verifica che non ci siano segreti in chiaro).

  • Richiedere la risoluzione delle conversazioni prima di unire. Tutti i commenti sul codice devono essere risolti prima che la PR possa essere unita.

  • Richiedere commit firmati. I commit devono essere firmati.

  • Richiedere una storia lineare. Impedire che i commit di unione vengano inviati a rami corrispondenti.

  • Includere gli amministratori. Se questo non è impostato, gli amministratori possono bypassare le restrizioni.

  • Limitare chi può inviare a rami corrispondenti. Limitare chi può inviare una PR.

Come puoi vedere, anche se riesci a ottenere alcune credenziali di un utente, i repo potrebbero essere protetti impedendoti di inviare codice a master ad esempio per compromettere il pipeline CI/CD.

Riferimenti

Supporta HackTricks
PreviousAccessible Deleted Data in GithubNextGitea Security

Last updated