Github Security

Impara l'hacking di AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks:

Cos'è Github

(Da qui) A un livello elevato, GitHub è un sito web e un servizio basato su cloud che aiuta gli sviluppatori a memorizzare e gestire il loro codice, nonché a tracciare e controllare le modifiche al loro codice.

Informazioni di base

pageBasic Github Information

Ricognizione Esterna

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'azienda (un'azienda può avere diverse organizzazioni) potranno accedervi

  • Pubblico significa che tutto Internet potrà accedervi.

Nel caso in cui conosci l'utente, il repository o l'organizzazione che vuoi mirare puoi utilizzare dork di github per trovare informazioni sensibili o cercare perdite di informazioni sensibili su ciascun repository.

Dork di Github

Github consente di cercare qualcosa specificando come ambito un utente, un repository 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 il suo elenco di dork):

Perdite di Github

Si prega di notare che i dork di github sono anche destinati a cercare perdite utilizzando le opzioni di ricerca di github. Questa sezione è dedicata agli strumenti che scaricheranno ciascun repository e cercheranno informazioni sensibili al loro interno (controllando anche una certa profondità dei commit).

Strumenti (ogni strumento contiene il suo elenco di regex):

Quando cerchi perdite in un repository e esegui qualcosa come git log -p non dimenticare che potrebbero esserci altri branch con altri commit contenenti segreti!

Fork Esterni

È possibile compromettere i repository abusando delle pull requests. Per sapere se un repository è vulnerabile, è necessario principalmente leggere le configurazioni yaml delle azioni di Github. Maggiori informazioni su questo sotto.

Rafforzamento dell'Organizzazione

Privilegi dei Membri

Ci 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/Lettura/Scrittura/Amministratore sui repository dell'organizzazione. È consigliato Nessuno o Lettura.

  • Fork del repository: Se non è necessario, è meglio non consentire ai membri di fare il fork dei repository dell'organizzazione.

  • Creazione di pagine: Se non è necessario, è meglio non consentire ai membri di pubblicare pagine dai repository dell'organizzazione. Se necessario, è possibile consentire di creare pagine pubbliche o private.

  • Richieste di accesso all'integrazione: Con questa opzione abilitata, i collaboratori esterni potranno richiedere l'accesso per le app GitHub o OAuth per accedere a questa organizzazione e alle sue risorse. Di solito è necessario, ma se non lo è, è meglio disabilitarlo.

  • Non ho trovato 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 la visibilità del repository. Se non vuoi che le persone rendano le cose pubbliche, assicurati che ciò sia disabilitato.

  • Non ho trovato 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 ho trovato queste informazioni nella risposta delle API, condividi se lo fai

  • Consenti 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 ho trovato 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.

Impostazioni delle Azioni

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 essere impostate anche su ciascun repository in modo indipendente

  • Politiche delle azioni di Github: Ti consente di indicare quali repository possono eseguire i flussi di lavoro e quali flussi di lavoro dovrebbero essere consentiti. È consigliabile specificare quali repository dovrebbero essere consentiti e non consentire a tutte le azioni di eseguire.

  • Flussi di lavoro delle pull request dei fork dai collaboratori esterni: È consigliabile richiedere l'approvazione per tutti i collaboratori esterni.

  • Non ho trovato un'API con queste informazioni, condividi se lo fai

  • Esegui flussi di lavoro dalle pull request dei fork: È sconsigliato eseguire flussi di lavoro dalle pull request poiché i manutentori dell'origine del fork avranno la possibilità di utilizzare token con permessi di lettura sul repository di origine.

  • Non ho trovato un'API con queste informazioni, condividi se lo fai

  • Permessi del flusso di lavoro: È altamente consigliabile concedere solo permessi di lettura al repository. È sconsigliato concedere permessi di scrittura e creazione/approvazione di pull request per evitare abusi del GITHUB_TOKEN fornito per l'esecuzione dei flussi di lavoro.

Integrazioni

Fammi sapere se conosci il punto finale dell'API per accedere a queste informazioni!

  • Politica di accesso alle applicazioni di terze parti: Si consiglia di limitare l'accesso a ogni applicazione e consentire solo quelle necessarie (dopo averle esaminate).

  • App GitHub installate: Si consiglia di consentire solo quelle necessarie (dopo averle esaminate).

Ricognizione e attacchi che abusano delle credenziali

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

Con le credenziali dell'utente

Se in qualche modo hai già le credenziali di un utente all'interno di un'organizzazione, puoi semplicemente effettuare l'accesso e controllare quali ruoli aziendali e organizzativi hai, se sei un membro grezzo, controllare quali autorizzazioni hanno i membri grezzi, in quali gruppi sei, quali autorizzazioni hai su quali repository e come sono protetti i repository.

Tieni presente che potrebbe essere utilizzato 2FA, quindi potrai accedere a queste informazioni solo se riesci anche a superare tale controllo.

Nota che se riesci a rubare il cookie user_session (attualmente configurato con SameSite: Lax) puoi impersonare completamente l'utente senza necessità di credenziali o 2FA.

Controlla la sezione qui sotto riguardante i bypass delle protezioni del branch nel caso possa esserti utile.

Con la chiave SSH dell'utente

Github consente agli utenti di impostare chiavi SSH che verranno utilizzate come metodo di autenticazione per distribuire codice per loro conto (nessun 2FA viene applicato).

Con questa chiave puoi effettuare modifiche nei repository in cui 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 repository e sull'utente a cui hai accesso:

# Go to the the repository folder
# Get repo config and current user name and email
git config --list

Se l'utente ha configurato il suo nome utente come il suo nome utente di GitHub, è possibile accedere alle chiavi pubbliche che ha impostato nel suo account su https://github.com/<github_username>.keys, potresti controllare questo per confermare che la chiave privata che hai trovato possa essere utilizzata.

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

Chiavi GPG

Come spiegato qui a volte è necessario firmare i commit o potresti essere scoperto.

Controlla localmente se l'utente attuale ha qualche chiave con:

gpg --list-secret-keys --keyid-format=long

Con Token Utente

Per una introduzione sui Token Utente controlla le informazioni di base.

Un token utente può essere utilizzato al posto di una password per Git su HTTPS, o può essere utilizzato per autenticarsi all'API tramite Autenticazione di Base. A seconda dei privilegi ad esso associati, potresti essere in grado di eseguire azioni diverse.

Un token utente ha questo aspetto: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123

Con Applicazione Oauth

Per una introduzione sulle Applicazioni Oauth di Github controlla le informazioni di base.

Un attaccante potrebbe creare una Applicazione Oauth malevola per accedere a dati/azioni privilegiate degli utenti che li accettano probabilmente come parte di una campagna di phishing.

Questi sono gli ambiti che un'applicazione Oauth può richiedere. Si dovrebbe sempre controllare gli ambiti richiesti prima di accettarli.

Inoltre, come spiegato nelle informazioni di base, le organizzazioni possono concedere/negare l'accesso alle applicazioni di terze parti alle informazioni/repos/azioni relative all'organizzazione.

Con Applicazione Github

Per una introduzione sulle Applicazioni di Github controlla le informazioni di base.

Un attaccante potrebbe creare una Applicazione Github malevola per accedere a dati/azioni privilegiate degli utenti che li accettano probabilmente come parte di una campagna di phishing.

Inoltre, come spiegato nelle informazioni di base, le organizzazioni possono concedere/negare l'accesso alle applicazioni di terze parti alle informazioni/repos/azioni relative all'organizzazione.

Compromissione e Abuso di Github Action

Ci sono diverse tecniche per compromettere e abusare di una Github Action, controllale qui:

pageAbusing Github Actions

Bypass delle Protezioni del Branch

  • Richiedere un numero di approvazioni: Se hai compromesso diversi account potresti semplicemente accettare i tuoi PR da altri account. Se hai solo l'account da cui hai creato il PR, non puoi accettare il tuo stesso PR. Tuttavia, se hai accesso a un ambiente Github Action all'interno del repository, utilizzando il GITHUB_TOKEN potresti essere in grado di approvare il tuo PR e ottenere 1 approvazione in questo modo.

  • Nota per questo e per la restrizione dei proprietari del codice che di solito un utente non potrà approvare i propri PR, ma se sei in grado di farlo, puoi abusarne per accettare i tuoi PR.

  • Ignora le approvazioni quando vengono effettuati nuovi commit: Se questo non è impostato, puoi inviare codice legittimo, aspettare che qualcuno lo approvi, inserire codice dannoso e unirlo al branch protetto.

  • Richiedere recensioni dai proprietari del codice: Se questo è attivato e sei un proprietario del codice, potresti fare in modo che una Github Action crei il tuo PR e poi lo approvi 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 sua protezione dei proprietari del codice non viene applicata.

  • Consenti ad attori specifici di ignorare i requisiti del pull request: Se sei uno di questi attori, puoi ignorare le protezioni del pull request.

  • Includi amministratori: Se questo non è impostato e sei un amministratore del repository, puoi ignorare queste protezioni del branch.

  • Dirottamento del PR: Potresti essere in grado di modificare il PR di qualcun altro aggiungendo codice dannoso, approvando il PR risultante tu stesso e unendo tutto.

  • Rimozione delle Protezioni del Branch: Se sei un amministratore del repository puoi disabilitare le protezioni, unire il tuo PR e reimpostare le protezioni.

  • Bypass delle protezioni di push: Se un repository consente solo a determinati utenti di inviare push (unire codice) nei branch (la protezione del branch potrebbe proteggere tutti i branch specificando il jolly *).

  • Se hai accesso in scrittura al repository 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 del codice. Poiché la protezione del branch non proteggerà il branch fino a quando non viene creato, questo primo push di codice al branch eseguirà la github action.

Bypass delle Protezioni degli Ambienti

Per una introduzione sugli Ambienti di Github controlla le informazioni di base.

Nel caso in cui un ambiente possa essere acceduto da tutti i branch, non è protetto e puoi facilmente accedere ai segreti all'interno dell'ambiente. Nota che potresti trovare repository in cui tutti i branch sono protetti (specificando i loro nomi o utilizzando *), in quel caso, trova un branch in cui 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 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.

push: # Run it when a push is made to a branch
branches:
- current_branch_name #Use '**' to run when a push is made to any branch

Nota che dopo la creazione del branch, la protezione del branch si applicherà al nuovo branch e non sarà possibile modificarlo, ma nel frattempo avrai già estratto le informazioni segrete.

Persistenza

  • Generare un token utente

  • Rubare i token di Github dalle secrets

  • Cancellazione dei risultati del workflow e dei branch

  • Concedere più permessi a tutta l'organizzazione

  • Creare webhook per esfiltrare informazioni

  • Invitare collaboratori esterni

  • Rimuovere i webhook utilizzati dal SIEM

  • Creare/modificare Github Action con un backdoor

  • Trovare Github Action vulnerabile per l'iniezione di comandi tramite modifica del valore segreto

Commit dell'impostore - Backdoor tramite commit del repository

In Github è possibile creare una PR a un repository da un fork. Anche se la PR non viene accettata, verrà creato un ID commit all'interno del repository originale per la versione fork del codice. Pertanto, un attaccante potrebbe fissare l'uso di un commit specifico da un repository apparentemente legittimo che non è stato creato dal proprietario del repository.

Come questo:

name: example
on: [push]
jobs:
commit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
- shell: bash
run: |
echo 'hello world!'

Per ulteriori informazioni consulta https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd

Impara l'hacking AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

Last updated