synacktiv/octoscanOctoscan è uno scanner statico di vulnerabilità per i workflow di GitHub Actions.
Octoscan è uno scanner statico di vulnerabilità per i workflow delle GitHub Actions.
$ go mod tidy
$ go build
Oppure con docker:
$ docker pull ghcr.io/synacktiv/octoscan:latest
Octoscan può essere eseguito su un repository git locale, oppure puoi scaricare tutti i workflow con l'azione dl:
$ octoscan dl -h
Octoscan.
Usage:
octoscan dl [options] --org <org> [--repo <repo> --token <pat> --default-branch --max-branches <num> --path <path> --output-dir <dir> --include-archives]
Options:
-h, --help Show help
-d, --debug Debug output
--verbose Verbose output
--org <org> Organizations to target
--repo <repo> Repository to target
--token <pat> GHP to authenticate to GitHub
--default-branch Only download workflows from the default branch
--max-branches <num> Limit the number of branches to download
--path <path> GitHub file path to download [default: .github/workflows]
--output-dir <dir> Output dir where to download files [default: octoscan-output]
--include-archives Also download archived repositories
./octoscan dl --token ghp_<token> --org apache --repo incubator-answer
Se non sai cosa eseguire, esegui semplicemente questo:
./octoscan scan path/to/repos/ --disable-rules shellcheck,local-action --filter-triggers external
Questo ridurrà i falsi positivi e fornirà i risultati più interessanti.
Se hai scaricato i workflow con il comando dl, potresti avere workflow duplicati, poiché di default octoscan scarica tutti i workflow di tutti i branch. Per eliminare i workflow duplicati e velocizzare l'analisi, puoi usare il comando fdupes prima di eseguire l'analisi:
fdupes -n -r -N -d path/to/repo
$ octoscan scan -h
octoscan
Usage:
octoscan scan [options] --list-rules
octoscan scan [options] <target>
octoscan scan [options] <target> [--debug-rules --filter-triggers=<triggers> --filter-run --ignore=<pattern> ((--disable-rules | --enable-rules ) <rules>) --config-file <config>]
Options:
-h, --help
-v, --version
-d, --debug
--verbose
--format <format> Output format, json, sarif or custom template to format error messages in Go template syntax. See https://github.com/rhysd/actionlint/tree/main/docs/usage.md#format
--oneline Use one line per one error. Useful for reading error messages from programs
Args:
<target> Target File or directory to scan
--filter-triggers <triggers> Scan workflows with specific triggers (comma separated list: "push,pull_request_target" or pre-configured: external/allnopr)
--filter-run Search for expression injection only in run shell scripts.
--ignore <pattern> Regular expression matching to error messages you want to ignore.
--disable-rules <rules> Disable specific rules. Split on ","
--enable-rules <rules> Enable specific rules, this will disable all other rules. Split on ","
--debug-rules Enable debug rules.
--config-file <config> Config file.
Examples:
$ octoscan scan ci.yml --disable-rules shellcheck,local-action --filter-triggers external
Questo strumento può essere utilizzato anche direttamente come GitHub action per analizzare il tuo repository sugli eventi push/pull_request. Per maggiori informazioni, consulta questo repository.
L'elenco completo delle regole può essere visualizzato con questo comando:
$ octoscan scan --list-rules
2024/08/07 16:50:48 [INFO] Available rules
- shellcheck
Checks for shell script sources in "run:" using shellcheck
- credentials
Checks for credentials in "services:" configuration
- dangerous-action
Check for dangerous actions.
- dangerous-checkout
Check for dangerous checkout.
- expression-injection
Check for expression injection.
- dangerous-write
Check for dangerous write operation on $GITHUB_OUTPUT or $GITHUB_ENV.
- local-action
Check for local actions.
- runner-label
Checks for GitHub-hosted and preset self-hosted runner labels in "runs-on:"
- unsecure-commands
Check 'ACTIONS_ALLOW_UNSECURE_COMMANDS' env variable.
- known-vulnerability
Check for known vulnerabilities.
- bot-check
Check for if statements that are based on a bot identity.
- dangerous-artefact
Check for workflow that upload artefacts containing sensitive files.
- debug-external-trigger
Check for workflow that can be externally triggered.
- debug-artefacts
Check for workflow that upload artefacts.
- debug-js-exec
Check for workflow that execute system commands in JS scripts.
- debug-oidc-action
Check for OIDC actions.
- repo-jacking
Verify that external actions are pointing to a valid GitHub user or organization.
Trigger come workflow_run o pull_request_target vengono eseguiti in un contesto privilegiato, poiché hanno accesso in lettura ai segreti e potenzialmente accesso in scrittura sul repository bersaglio. Eseguire un checkout esplicito sul codice non fidato comporta il download del codice dell'attaccante in tale contesto.
Questa regola avvisa l'utente se viene utilizzata un'azione pericolosa. È principalmente focalizzata sugli artefatti non fidati.
È pratica comune utilizzare gli artefatti per trasferire dati tra diversi workflow. Lo si riscontra spesso con il trigger workflow_run, dove il workflow che scatena l'evento prepara alcuni dati che verranno poi inviati al workflow attivato. Data la natura non fidata di questi dati degli artefatti, è fondamentale trattarli con cautela e riconoscerli come una potenziale minaccia. La vulnerabilità deriva dal fatto che entità esterne, come attori malintenzionati, possono influenzare il contenuto dei dati degli artefatti.
GitHub crea variabili d'ambiente predefinite che possono essere utilizzate all'interno di ogni step di un workflow. Le variabili GITHUB_ENV e GITHUB_OUTPUT sono particolarmente interessanti. È possibile definire una variabile d'ambiente in uno step e utilizzarla in un altro. Ciò può essere fatto scrivendola nella variabile associata. Se un utente può controllare il contenuto della variabile che viene impostata, ciò può portare a esecuzione di codice arbitrario.
Ogni trigger di workflow è associato a un contesto GitHub che offre informazioni complete sull'evento che lo ha attivato. Ciò include dettagli sull'utente che ha attivato l'evento, il nome del branch e altre informazioni contestuali rilevanti. Alcune componenti di questi dati dell'evento, come il nome del repository base o il numero della pull request, non possono essere manipolate o sfruttate per un'iniezione dall'utente che ha avviato l'evento (ad esempio, nel caso di una pull request). Questo garantisce un livello di controllo e sicurezza sulle informazioni fornite dal contesto GitHub durante l'esecuzione del workflow.
Tuttavia, alcuni elementi possono essere controllati da un attaccante e dovrebbero essere sanitizzati prima dell'uso. Ecco l'elenco di tali elementi:
github.event.issue.titlegithub.event.issue.bodygithub.event.pull_request.titlegithub.event.pull_request.bodygithub.event.comment.bodygithub.event.review.bodygithub.event.pages.*.page_namegithub.event.commits.*.messagegithub.event.head_commit.messagegithub.event.head_commit.author.emailgithub.event.head_commit.author.namegithub.event.commits.*.author.emailgithub.event.commits.*.author.namegithub.event.pull_request.head.refgithub.event.pull_request.head.labelgithub.event.pull_request.head.repo.default_branchgithub.head_refenv.*steps.*.outputs.*needs.*.outputs.*
GitHub offre la possibilità di ospitare i propri runner e personalizzare l'ambiente utilizzato per eseguire i job nei workflow. Questi runner sono chiamati self-hosted.
Esistono due tipi di runner self-hosted: effimeri (ephemeral) e non effimeri. Di default, i runner sono non effimeri, il che significa che l'ambiente utilizzato dal runner non viene pulito dopo il completamento di un job. Se un attaccante riesce a eseguire codice su un runner non effimero, potrebbe comprometterlo aggiungendo un processo in background e rubare segreti sensibili. Questi tipi di runner sono quindi molto delicati.
I runner non effimeri possono essere identificati esaminando i log di esecuzione. Uno strumento chiamato gato può essere utilizzato per automatizzare questo processo.
La vulnerabilità del repo jacking è stata presentata al DEFCON 31 da Asi Greenholts. Questa vulnerabilità si verifica quando una GitHub action fa riferimento a un'azione su un'organizzazione o un utente GitHub inesistente.
Nota che questa regola richiede l'accesso a internet per verificare se l'attacco è possibile o meno. Tutti gli altri controlli vengono eseguiti offline.
Le azioni hanno la capacità di interagire con la macchina del runner, consentendo loro di impostare variabili d'ambiente, definire valori di output per l'uso da parte di altre azioni, incorporare messaggi di debug nei log di output e svolgere varie altre attività. Tuttavia, prima del 2020, era possibile controllare le variabili d'ambiente scrivendo dati su STDOUT in questo modo:
run: |
echo "##[set-env name=ENV_NAME;]value"
# or
echo "echo "::set-env name=ENV_NAME::value"
I comandi di workflow implementati erano intrinsecamente insicuri a causa della pratica comune di registrare tutto su STDOUT. Questa vulnerabilità apriva la strada a potenziali attacchi, consentendo di iniettare facilmente payload dannosi e attivare il comando set-env. La capacità di modificare le variabili d'ambiente introduceva molteplici percorsi per l'esecuzione remota di codice, con un payload particolarmente ovvio rappresentato da quello dimostrato in precedenza. Questa vulnerabilità è stata inizialmente segnalata da un ricercatore di sicurezza di Project Zero.
Sebbene il comando set-env sia deprecato e non utilizzabile di default, se uno sviluppatore imposta la variabile d'ambiente ACTIONS_ALLOW_UNSECURE_COMMANDS in un workflow, il comando set-env diventa disponibile e può essere utilizzato:
È possibile bypassare il seguente controllo:
jobs:
merge-dependabot-pr:
runs-on: ubuntu-latest
if: github.actor == 'dependabot[bot]'
steps:
...
L'idea dell'attacco è di attivare Dependabot su un repository fork in modo tale che una PR sul repository fork venga creata da Dependabot, poi una PR dal branch di Dependabot viene aperta sul repository vulnerabile e infine Dependabot viene attivato di nuovo per lanciare il workflow vulnerabile.
Puoi trovare tutti i dettagli dello sfruttamento qui: https://www.synacktiv.com/publications/github-actions-exploitation-dependabot
Cerca azioni vulnerabili note basandosi su osv.dev.
Controlla i workflow che caricano artefatti contenenti file sensibili come .git/config. Questa regola si basa su questo articolo.
Verifica la presenza di credenziali nella configurazione services:. Questa regola proviene da actionlint.
Esegue shellcheck su tutti i task bash. Questa regola proviene da actionlint.
Solleva un avviso se viene utilizzata una GitHub action locale. Per ora lo strumento non è in grado di analizzare i file delle azioni locali, quindi viene sollevato un avviso poiché possono contenere anch'esse vulnerabilità.
Rileva le azioni OIDC. I workflow che utilizzano azioni OIDC possono essere un buon bersaglio per accedere ad alcuni cloud provider. Non vi è alcuna vulnerabilità associata a questa regola, ma dare un'occhiata più da vicino a questa azione può essere interessante se esiste una vulnerabilità non rilevata da questo strumento.
💡 Questa è ora una regola di debug, devi aggiungere --debug-rules per cercarla.
Questo strumento non sarebbe stato possibile senza actionlint. Un grande ringraziamento a @rhysd.