Basic Github Information
Last updated
Last updated
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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.
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.
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.
Manager di fatturazione: I manager di fatturazione sono utenti che possono gestire le impostazioni di fatturazione per la tua organizzazione, come le informazioni di pagamento.
Manager della Sicurezza: È un ruolo che i proprietari dell'organizzazione possono assegnare a qualsiasi team in un'organizzazione. Quando applicato, fornisce 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 manager della sicurezza per dare ai membri del team il minimo accesso di cui hanno bisogno all'organizzazione.
Manager 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 manager 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
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.
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
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.
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.
Github offre diversi modi per autenticarti al tuo account e svolgere azioni per tuo conto.
Accedendo a github.com puoi effettuare il login utilizzando il tuo nome utente e password (e un 2FA potenzialmente).
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
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.
Puoi generare un token di accesso personale per dare accesso a un'applicazione 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
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 login con github che potresti trovare in alcune piattaforme.
Puoi creare le tue applicazioni Oauth in https://github.com/settings/developers
Puoi vedere tutte le applicazioni Oauth che hanno accesso al tuo account in https://github.com/settings/applications
Puoi vedere i scopi che le App Oauth possono chiedere in https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps
Puoi vedere l'accesso di terze parti delle applicazioni in un'organizzazione in https://github.com/organizations/<org_name>/settings/oauth_application_policy
Alcuni consigli di sicurezza:
Un OAuth App dovrebbe sempre agire come l'utente GitHub autenticato in tutto GitHub (ad esempio, quando fornisce notifiche all'utente) e con accesso solo agli scopi specificati.
Un OAuth App può essere utilizzato come fornitore di identità abilitando un "Login con GitHub" per l'utente autenticato.
Non costruire un OAuth App se desideri che la tua applicazione agisca su un singolo repository. Con lo scopo repo, le App OAuth 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 App OAuth 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.
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.
Per installare un'App GitHub, devi essere un proprietario dell'organizzazione o avere permessi di admin in un repository.
L'App GitHub dovrebbe collegarsi a un account personale o a un'organizzazione.
Puoi creare la tua applicazione Github in https://github.com/settings/apps
Puoi vedere tutte le applicazioni Github che hanno accesso al tuo account in https://github.com/settings/apps/authorizations
Questi sono i Endpoint API per le Applicazioni Github https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. A seconda dei permessi dell'App, sarà in grado di accedere ad alcuni di essi.
Puoi vedere le app installate in un'organizzazione in https://github.com/organizations/<org_name>/settings/installations
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 "Login 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 scopo workflow. L'utente deve avere permessi di admin o scrittura nel repository che contiene il file di workflow. Per ulteriori informazioni, vedere "Comprendere gli scopi per le app OAuth."
Di più qui.
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.
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).
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 alcune 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.
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 Secrets.
Questi segreti possono essere configurati per il repo o per tutta l'organizzazione. Poi, affinché l'Azione possa accedere al segreto, devi dichiararlo come:
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).
Github consente di creare ambienti in cui puoi salvare segreti. Poi, puoi dare accesso all'azione github ai segreti all'interno dell'ambiente con qualcosa come:
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.
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.
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.
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.
Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
