Github Security
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)
(Da qui) A un livello alto, GitHub è un sito web e un servizio basato su cloud che aiuta gli sviluppatori a memorizzare e gestire il loro codice, oltre a tracciare e controllare le modifiche al loro codice.
I repository di Github possono essere configurati come pubblici, privati e interni.
Privato significa che solo le persone dell'organizzazione potranno accedervi
Interno significa che solo le persone dell'impresa (un'impresa può avere diverse organizzazioni) potranno accedervi
Pubblico significa che tutto internet potrà accedervi.
Nel caso tu conosca l'utente, il repo o l'organizzazione che vuoi targetizzare, puoi usare github dorks per trovare informazioni sensibili o cercare leak di informazioni sensibili in ogni repo.
Github consente di cercare qualcosa specificando come ambito un utente, un repo o un'organizzazione. Pertanto, con un elenco di stringhe che appariranno vicino a informazioni sensibili, puoi facilmente cercare potenziali informazioni sensibili nel tuo obiettivo.
Strumenti (ogni strumento contiene la sua lista di dorks):
Si prega di notare che i github dorks sono anche destinati a cercare leak utilizzando le opzioni di ricerca di github. Questa sezione è dedicata a quegli strumenti che scaricheranno ogni repo e cercheranno informazioni sensibili in essi (anche controllando una certa profondità di commit).
Strumenti (ogni strumento contiene la sua lista di regex):
Quando cerchi leak in un repo e esegui qualcosa come git log -p non dimenticare che potrebbero esserci altri rami con altri commit contenenti segreti!
È possibile compromettere i repo abusando delle pull request. Per sapere se un repo è vulnerabile, devi principalmente leggere le configurazioni yaml delle Github Actions. Maggiori informazioni su questo di seguito.
Anche se eliminati o interni, potrebbe essere possibile ottenere dati sensibili dai fork dei repository di github. Controllalo qui:
Accessible Deleted Data in GithubCi sono alcuni privilegi predefiniti che possono essere assegnati ai membri dell'organizzazione. Questi possono essere controllati dalla pagina https://github.com/organizations/<org_name>/settings/member_privileges o dall'API delle organizzazioni.
Permessi di base: I membri avranno il permesso Nessuno/Leggi/scrivi/Amministratore sui repository dell'organizzazione. Si raccomanda di impostare Nessuno o Leggi.
Forking dei repository: Se non necessario, è meglio non consentire ai membri di forkare i repository dell'organizzazione.
Creazione di pagine: Se non necessario, è meglio non consentire ai membri di pubblicare pagine dai repo dell'organizzazione. Se necessario, puoi consentire di creare pagine pubbliche o private.
Richieste di accesso all'integrazione: Con questo abilitato, i collaboratori esterni potranno richiedere accesso per le app GitHub o OAuth per accedere a questa organizzazione e alle sue risorse. È solitamente necessario, ma se non lo è, è meglio disabilitarlo.
Non sono riuscito a trovare queste informazioni nella risposta delle API, condividi se lo fai
Cambio di visibilità del repository: Se abilitato, i membri con permessi amministrativi per il repository potranno cambiare la sua visibilità. Se disabilitato, solo i proprietari dell'organizzazione possono cambiare le visibilità dei repository. Se non vuoi che le persone rendano le cose pubbliche, assicurati che questo sia disabilitato.
Non sono riuscito a trovare queste informazioni nella risposta delle API, condividi se lo fai
Cancellazione e trasferimento del repository: Se abilitato, i membri con permessi amministrativi per il repository potranno cancellare o trasferire repository pubblici e privati.
Non sono riuscito a trovare queste informazioni nella risposta delle API, condividi se lo fai
Consentire ai membri di creare team: Se abilitato, qualsiasi membro dell'organizzazione potrà creare nuovi team. Se disabilitato, solo i proprietari dell'organizzazione possono creare nuovi team. È meglio avere questo disabilitato.
Non sono riuscito a trovare queste informazioni nella risposta delle API, condividi se lo fai
Altre cose possono essere configurate in questa pagina, ma le precedenti sono quelle più legate alla sicurezza.
Diverse impostazioni relative alla sicurezza possono essere configurate per le azioni dalla pagina https://github.com/organizations/<org_name>/settings/actions.
Nota che tutte queste configurazioni possono anche essere impostate su ciascun repository in modo indipendente
Politiche delle azioni di Github: Consente di indicare quali repository possono eseguire flussi di lavoro e quali flussi di lavoro dovrebbero essere consentiti. Si raccomanda di specificare quali repository dovrebbero essere consentiti e di non consentire a tutte le azioni di essere eseguite.
Flussi di lavoro delle pull request forkate da collaboratori esterni: Si raccomanda di richiedere approvazione per tutti i collaboratori esterni.
Non sono riuscito a trovare un'API con queste informazioni, condividi se lo fai
Esegui flussi di lavoro da pull request forkate: È fortemente sconsigliato eseguire flussi di lavoro da pull request poiché i manutentori del fork originale avranno la possibilità di utilizzare token con permessi di lettura sul repository sorgente.
Non sono riuscito a trovare un'API con queste informazioni, condividi se lo fai
Permessi dei flussi di lavoro: È altamente raccomandato fornire solo permessi di lettura sui repository. È sconsigliato fornire permessi di scrittura e di creazione/approvazione delle pull request per evitare l'abuso del GITHUB_TOKEN fornito per l'esecuzione dei flussi di lavoro.
Fammi sapere se conosci l'endpoint API per accedere a queste informazioni!
Politica di accesso alle applicazioni di terze parti: Si raccomanda di limitare l'accesso a ogni applicazione e consentire solo quelle necessarie (dopo averle esaminate).
App GitHub installate: Si raccomanda di consentire solo quelle necessarie (dopo averle esaminate).
Per questo scenario supponiamo che tu abbia ottenuto un accesso a un account github.
Se in qualche modo hai già le credenziali per un utente all'interno di un'organizzazione, puoi solo accedere e controllare quali ruoli di impresa e organizzazione hai, se sei un membro normale, controlla quali permessi hanno i membri normali, in quali gruppi sei, quali permessi hai su quali repo e come sono protetti i repo.
Nota che 2FA potrebbe essere utilizzato, quindi potrai accedere a queste informazioni solo se puoi anche superare quel controllo.
Nota che se riesci a rubare il cookie user_session (attualmente configurato con SameSite: Lax) puoi completamente impersonare l'utente senza bisogno di credenziali o 2FA.
Controlla la sezione qui sotto riguardo ai bypass delle protezioni dei rami nel caso possa essere utile.
Github 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 github per enumerare l'ambiente. Tuttavia, puoi enumerare le impostazioni locali per ottenere informazioni sui repo e sull'utente a cui hai accesso:
Se l'utente ha configurato il proprio nome utente come il suo nome utente github, puoi accedere alle chiavi pubbliche che ha impostato nel suo account in https://github.com/<github_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.
Come spiegato qui, a volte è necessario firmare i commit o potresti essere scoperto.
Controlla localmente se l'utente corrente ha qualche chiave con:
Per un'introduzione sui Token Utente controlla le informazioni di base.
Un token utente può essere utilizzato invece di una password per Git su HTTPS, o può essere utilizzato per autenticarsi all'API tramite Basic Authentication. A seconda dei privilegi ad esso associati, potresti essere in grado di eseguire diverse azioni.
Un token utente appare così: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123
Per un'introduzione sulle Applicazioni Oauth di Github controlla le informazioni di base.
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.
Questi sono i scope che un'applicazione Oauth può richiedere. Un utente dovrebbe sempre controllare gli scope richiesti prima di accettarli.
Inoltre, come spiegato nelle informazioni di base, le organizzazioni possono concedere/negare l'accesso a applicazioni di terze parti a informazioni/repo/azioni relative all'organizzazione.
Per un'introduzione sulle Applicazioni Github controlla le informazioni di base.
Un attaccante potrebbe creare un'Applicazione Github malevola per accedere a dati/azioni privilegiati degli utenti che le accettano probabilmente come parte di una campagna di phishing.
Inoltre, come spiegato nelle informazioni di base, le organizzazioni possono concedere/negare l'accesso a applicazioni di terze parti a informazioni/repo/azioni relative all'organizzazione.
Ci sono diverse tecniche per compromettere e abusare di una Github Action, controllale qui:
Abusing Github ActionsRichiedere un numero di approvazioni: Se hai compromesso diversi account, potresti semplicemente accettare le tue PR da altri account. Se hai solo l'account da cui hai creato la PR, non puoi accettare la tua PR. Tuttavia, se hai accesso a un ambiente Github Action all'interno del repo, utilizzando il GITHUB_TOKEN potresti essere in grado di approvare la tua PR e ottenere 1 approvazione in questo modo.
Nota per questo e per la restrizione dei Code Owners che di solito un utente non sarà in grado di approvare le proprie PR, ma se lo sei, puoi abusarne per accettare le tue PR.
Annullare le approvazioni quando vengono inviati nuovi commit: Se questo non è impostato, puoi inviare codice legittimo, aspettare che qualcuno lo approvi e poi inserire codice malevolo e fonderlo nel branch protetto.
Richiedere revisioni dai Code Owners: Se questo è attivato e sei un Code Owner, potresti far sì che una Github Action crei la tua PR e poi approvarla tu stesso.
Quando un file CODEOWNER è configurato in modo errato, Github non si lamenta ma non lo utilizza. Pertanto, se è configurato in modo errato, la protezione dei Code Owners non viene applicata.
Consentire a attori specificati di bypassare i requisiti delle pull request: Se sei uno di questi attori, puoi bypassare le protezioni delle pull request.
Includere gli amministratori: Se questo non è impostato e sei un amministratore del repo, puoi bypassare queste protezioni del branch.
Hijacking delle PR: Potresti essere in grado di modificare la PR di qualcun altro aggiungendo codice malevolo, approvando la PR risultante tu stesso e fondendo tutto.
Rimozione delle Protezioni dei Branch: Se sei un amministratore del repo puoi disabilitare le protezioni, fondere la tua PR e ripristinare le protezioni.
Bypass delle protezioni di push: Se un repo consente solo a determinati utenti di inviare push (fondere codice) nei branch (la protezione del branch potrebbe proteggere tutti i branch specificando il carattere jolly *).
Se hai accesso in scrittura sul repo ma non ti è consentito inviare codice a causa della protezione del branch, puoi comunque creare un nuovo branch e al suo interno creare una github action che viene attivata quando viene inviato codice. Poiché la protezione del branch non proteggerà il branch fino a quando non sarà creato, questo primo push di codice nel branch eseguirà la github action.
Per un'introduzione su Github Environment controlla le informazioni di base.
Nel caso in cui un ambiente possa essere accessibile da tutti i branch, non è protetto e puoi facilmente accedere ai segreti all'interno dell'ambiente. Nota che potresti trovare repo in cui tutti i branch sono protetti (specificando i loro nomi o utilizzando *); in quel scenario, trova un branch dove puoi inviare codice e puoi esfiltrare i segreti creando una nuova github action (o modificandone una).
Nota che potresti trovare il caso limite in cui tutti i branch sono protetti (tramite carattere jolly *) è specificato chi può inviare codice ai branch (puoi specificarlo nella protezione del branch) e il tuo utente non è autorizzato. Puoi comunque eseguire una github action personalizzata perché puoi creare un branch e utilizzare il trigger di push su se stesso. La protezione del branch consente il push a un nuovo branch quindi la github action verrà attivata.
Nota che dopo la creazione del branch, la protezione del branch si applicherà al nuovo branch e non sarai in grado di modificarlo, ma per quel momento avrai già estratto i segreti.
Genera token utente
Ruba token github da secrets
Cancellazione dei risultati del workflow e dei branch
Dai più permessi a tutta l'organizzazione
Crea webhook per esfiltrare informazioni
Invita collaboratori esterni
Rimuovi i webhook utilizzati dal SIEM
Crea/modifica Github Action con una backdoor
Trova Github Action vulnerabili a command injection tramite modifica del valore secret
In Github è possibile creare una PR per un repo da un fork. Anche se la PR non viene accettata, un commit id all'interno del repo originale verrà creato per la versione fork del codice. Pertanto, un attaccante potrebbe fare riferimento a un commit specifico da un repo apparentemente legittimo che non è stato creato dal proprietario del repo.
Come questo:
Per ulteriori informazioni controlla https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-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)
