synacktiv/octoscanOctoscan is a static vulnerability scanner for GitHub action workflows.
Octoscan ist ein statischer Schwachstellen-Scanner für GitHub-Action-Workflows.
$ go mod tidy
$ go build
Oder mit Docker:
$ docker pull ghcr.io/synacktiv/octoscan:latest
Octoscan kann gegen ein lokales Git-Repository ausgeführt werden, oder Sie können alle Workflows mit der Aktion dl herunterladen:
$ 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
Wenn Sie nicht wissen, was Sie ausführen sollen, führen Sie einfach Folgendes aus:
./octoscan scan path/to/repos/ --disable-rules shellcheck,local-action --filter-triggers external
Das reduziert False Positives und liefert die interessantesten Ergebnisse.
Wenn Sie die Workflows mit dem Befehl dl heruntergeladen haben, können doppelte Workflows auftreten, da Octoscan standardmäßig alle Workflows aller Branches herunterlädt. Um doppelte Workflows zu löschen und die Analyse zu beschleunigen, können Sie den Befehl fdupes vor der Analyse ausführen:
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
Dieses Tool kann auch direkt als GitHub Action verwendet werden, um Ihr Repository bei push-/pull_request-Ereignissen zu scannen. Weitere Informationen finden Sie in diesem Repository.
Die vollständige Liste der Regeln finden Sie mit diesem Befehl:
$ 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 wie workflow_run oder pull_request_target laufen in einem privilegierten Kontext, da sie Lesezugriff auf Secrets und potenziell Schreibzugriff auf das Ziel-Repository haben. Wenn in einem solchen Kontext ein expliziter Checkout des nicht vertrauenswürdigen Codes durchgeführt wird, wird der Angreifercode in diesem Kontext heruntergeladen.
Diese Regel warnt den Benutzer, wenn eine gefährliche Action verwendet wird. Sie konzentriert sich hauptsächlich auf nicht vertrauenswürdige Artefakte.
Es ist üblich, Artefakte zu verwenden, um Daten zwischen verschiedenen Workflows auszutauschen. Wir begegnen diesem Muster häufig beim Trigger workflow_run, bei dem der auslösende Workflow Daten vorbereitet, die dann an den ausgelösten Workflow gesendet werden. Aufgrund der nicht vertrauenswürdigen Natur dieser Artefaktdaten ist es entscheidend, sie mit Vorsicht zu behandeln und als potenzielle Bedrohung zu erkennen. Die Schwachstelle entsteht dadurch, dass externe Akteure wie Angreifer den Inhalt der Artefaktdaten beeinflussen können.
GitHub erstellt standardmäßig Umgebungsvariablen, die in jedem Schritt eines Workflows verwendet werden können. Die Variablen GITHUB_ENV und GITHUB_OUTPUT sind besonders interessant. Es ist möglich, in einem Schritt eine Umgebungsvariable zu definieren und diese Variable in einem anderen Schritt zu verwenden. Dies kann erreicht werden, indem man sie in die zugehörige Variable schreibt. Wenn ein Benutzer den Inhalt der gesetzten Variable kontrollieren kann, kann dies zu beliebiger Codeausführung führen.
Jeder Workflow-Trigger verfügt über einen zugehörigen GitHub-Kontext, der umfassende Informationen über das Ereignis liefert, das ihn ausgelöst hat. Dazu gehören Details über den Benutzer, der das Ereignis ausgelöst hat, den Branchnamen und andere relevante Kontextinformationen. Bestimmte Komponenten dieser Ereignisdaten, wie der Name des Basis-Repositorys oder die Pull-Request-Nummer, können von dem Benutzer, der das Ereignis ausgelöst hat (z. B. im Falle eines Pull Requests), nicht manipuliert oder für eine Injektion ausgenutzt werden. Das gewährleistet ein gewisses Maß an Kontrolle und Sicherheit über die Informationen, die der GitHub-Kontext während der Workflow-Ausführung bereitstellt.
Einige Elemente können jedoch von einem Angreifer kontrolliert werden und sollten vor der Verwendung bereinigt werden. Hier ist die Liste dieser Elemente:
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.email
GitHub bietet die Möglichkeit, eigene Runner zu hosten und die Umgebung anzupassen, die zum Ausführen von Jobs in Workflows verwendet wird. Diese Runner werden als selbstgehostet bezeichnet.
Es gibt zwei Arten von selbstgehosteten Runnern: ephemere und nicht-ephemere. Standardmäßig sind die Runner nicht ephemer, d. h. die vom Runner verwendete Umgebung wird nach Abschluss eines Jobs nicht bereinigt. Wenn es Angreifern gelingt, Code auf einem nicht-ephemeren Runner auszuführen, könnten sie ihm eine Hintertür einbauen, indem sie einen Prozess im Hintergrund hinzufügen und sensible Secrets stehlen. Solche Runner sind daher wirklich sensibel.
Nicht-ephemere Runner können anhand der Ausführungsprotokolle identifiziert werden. Ein Tool namens gato kann verwendet werden, um diesen Prozess zu automatisieren.
Die Repo-Jacking-Schwachstelle wurde von Asi Greenholts auf der DEFCON 31 vorgestellt. Diese Schwachstelle tritt auf, wenn eine GitHub Action eine Action einer nicht existierenden GitHub-Organisation oder eines nicht existierenden Benutzers referenziert.
Beachten Sie, dass diese Regel eine Internetverbindung benötigt, um zu prüfen, ob der Angriff möglich ist oder nicht. Alle anderen Prüfungen werden offline durchgeführt.
Actions können mit der Runner-Maschine interagieren, Umgebungsvariablen setzen, Ausgabewerte für andere Actions definieren, Debug-Meldungen in die Ausgabelogs aufnehmen und verschiedene andere Aufgaben ausführen. Vor 2020 war es jedoch möglich, Umgebungsvariablen zu kontrollieren, indem Daten auf STDOUT geschrieben wurden, etwa so:
run: |
echo "##[set-env name=ENV_NAME;]value"
# or
echo "echo "::set-env name=ENV_NAME::value"
Die implementierten Workflow-Befehle waren aufgrund der üblichen Praxis, in STDOUT zu protokollieren, von Natur aus unsicher. Diese Schwachstelle eröffnete Angriffsmöglichkeiten, da schädliche Payloads leicht injiziert und der Befehl set-env ausgelöst werden konnte. Die Möglichkeit, Umgebungsvariablen zu verändern, führte zu mehreren Wegen für Remote-Codeausführung, wobei der zuvor gezeigte Payload besonders offensichtlich war. Diese Schwachstelle wurde ursprünglich von einem Sicherheitsforscher von Project Zero gemeldet.
Obwohl der Befehl set-env veraltet und standardmäßig nicht verwendbar ist, wird er verfügbar und kann verwendet werden, wenn ein Entwickler die Umgebungsvariable ACTIONS_ALLOW_UNSECURE_COMMANDS in einem Workflow setzt:
Es ist möglich, die folgende Prüfung zu umgehen:
jobs:
merge-dependabot-pr:
runs-on: ubuntu-latest
if: github.actor == 'dependabot[bot]'
steps:
...
Die Idee des Angriffs besteht darin, Dependabot in einem geforkten Repository so auszulösen, dass ein PR im geforkten Repository von Dependabot erstellt wird, dann ein PR vom Dependabot-Zweig im verwundbaren Repository geöffnet wird und schließlich Dependabot erneut ausgelöst wird, um den verwundbaren Workflow zu starten.
Alle Details zur Ausnutzung finden Sie hier: https://www.synacktiv.com/publications/github-actions-exploitation-dependabot
Sucht nach bekannten verwundbaren Actions auf Basis von osv.dev.
Prüft, ob ein Workflow Artefakte hochlädt, die sensible Dateien wie .git/config enthalten. Diese Regel basiert auf diesem Artikel.
Prüft auf Zugangsdaten in der services:-Konfiguration. Diese Regel stammt aus actionlint.
Führt shellcheck für alle Bash-Aufgaben aus. Diese Regel stammt aus actionlint.
Löst eine Warnung aus, wenn eine lokale GitHub Action verwendet wird. Derzeit kann das Tool keine lokalen Action-Dateien parsen, daher wird eine Warnung ausgegeben, da auch diese Schwachstellen enthalten können.
Erkennt OIDC-Actions. Workflows, die OIDC-Actions verwenden, können ein gutes Ziel sein, um Zugang zu einigen Cloud-Anbietern zu erhalten. Mit dieser Regel ist keine Schwachstelle verbunden, aber ein genauerer Blick auf diese Action kann interessant sein, falls es eine Schwachstelle gibt, die von diesem Tool nicht gefunden wird.
💡 Dies ist jetzt eine Debug-Regel. Sie müssen --debug-rules hinzufügen, um nach dieser Regel zu suchen.
Dieses Tool hätte ohne actionlint nicht entwickelt werden können. Vielen Dank an @rhysd.
github.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.*