synacktiv/octoscanOctoscan es un escáner estático de vulnerabilidades para flujos de trabajo de GitHub Actions.
Octoscan es un escáner estático de vulnerabilidades para flujos de trabajo de GitHub Actions.
$ go mod tidy
$ go build
O con docker:
$ docker pull ghcr.io/synacktiv/octoscan:latest
Octoscan se puede ejecutar contra un repositorio git local, o puedes descargar todos los flujos de trabajo con la acción 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
Si no sabes qué ejecutar, simplemente ejecuta esto:
./octoscan scan path/to/repos/ --disable-rules shellcheck,local-action --filter-triggers external
Reducirá los falsos positivos y dará los resultados más interesantes.
Si has descargado los flujos de trabajo con el comando dl, es posible que tengas flujos de trabajo duplicados, ya que por defecto octoscan descarga todos los flujos de trabajo de todas las ramas. Para eliminar los flujos de trabajo duplicados y acelerar el análisis, puedes usar el comando fdupes antes de ejecutar el análisis:
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
Esta herramienta también se puede usar directamente como una GitHub action para escanear tu repositorio en eventos de push/pull_request. Para más información, consulta este repositorio.
La lista completa de reglas se puede encontrar con este 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.
Disparadores como workflow_run o pull_request_target se ejecutan en un contexto privilegiado, ya que tienen acceso de lectura a los secretos y potencialmente acceso de escritura sobre el repositorio objetivo. Realizar un checkout explícito del código no confiable hará que el código del atacante se descargue en dicho contexto.
Esta regla advierte al usuario si se usa una acción peligrosa. Se centra principalmente en artefactos no confiables.
Es una práctica común usar artefactos para pasar datos entre diferentes flujos de trabajo. Esto se encuentra a menudo con el disparador workflow_run, donde el flujo de trabajo desencadenante prepara algunos datos que luego se envían al flujo de trabajo desencadenado. Dada la naturaleza no confiable de estos datos de artefactos, es crucial tratarlos con precaución y reconocerlos como una amenaza potencial. La vulnerabilidad surge del hecho de que entidades externas, como actores maliciosos, pueden influir en el contenido de los datos del artefacto.
GitHub crea variables de entorno predeterminadas que se pueden usar dentro de cada paso de un flujo de trabajo. Las variables GITHUB_ENV y GITHUB_OUTPUT son particularmente interesantes. Es posible definir una variable de entorno en un paso y usar esa variable en otro. Esto se puede hacer escribiéndola en la variable asociada. Si un usuario puede controlar el contenido de la variable que se está estableciendo, puede conducir a la ejecución arbitraria de código.
Cada disparador de flujo de trabajo viene con un contexto de GitHub asociado, que ofrece información completa sobre el evento que lo inició. Esto incluye detalles sobre el usuario que desencadenó el evento, el nombre de la rama y otra información contextual relevante. Ciertos componentes de estos datos del evento, como el nombre del repositorio base o el número de pull request, no pueden ser manipulados ni explotados para inyección por el usuario que inició el evento (por ejemplo, en el caso de un pull request). Esto garantiza un nivel de control y seguridad sobre la información proporcionada por el contexto de GitHub durante la ejecución del flujo de trabajo.
Sin embargo, algunos elementos pueden ser controlados por un atacante y deben sanearse antes de usarse. Esta es la lista de dichos elementos:
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 ofrece la posibilidad de alojar tus propios runners y personalizar el entorno utilizado para ejecutar trabajos en flujos de trabajo. Estos runners se denominan self-hosted.
Existen dos tipos de runners self-hosted: efímeros y no efímeros. Por defecto, los runners no son efímeros, lo que significa que el entorno utilizado por el runner no se limpia después de que un trabajo se completa. Si los atacantes logran ejecutar código en un runner no efímero, podrían dejar una puerta trasera añadiendo un proceso en segundo plano y robar secretos sensibles. Por lo tanto, este tipo de runners son realmente sensibles.
Los runners no efímeros se pueden identificar revisando los registros de ejecución. Se puede usar una herramienta llamada gato para automatizar este proceso.
La vulnerabilidad de repo jacking fue presentada en DEFCON 31 por Asi Greenholts. Esta vulnerabilidad ocurre cuando una GitHub action hace referencia a una acción en una organización o usuario de GitHub que no existe.
Ten en cuenta que esta regla necesita internet para comprobar si el ataque es posible o no. El resto de comprobaciones se realizan sin conexión.
Las acciones tienen la capacidad de interactuar con la máquina del runner, lo que les permite establecer variables de entorno, definir valores de salida para que los usen otras acciones, incorporar mensajes de depuración en los registros de salida y realizar varias otras tareas. Sin embargo, antes de 2020, era posible controlar las variables de entorno escribiendo datos en STDOUT de la siguiente manera:
run: |
echo "##[set-env name=ENV_NAME;]value"
# or
echo "echo "::set-env name=ENV_NAME::value"
Los comandos de flujo de trabajo implementados eran inherentemente inseguros debido a la práctica común de registrar en STDOUT. Esta vulnerabilidad abrió vías para posibles ataques, permitiendo que cargas maliciosas se inyectaran fácilmente y activaran el comando set-env. La capacidad de modificar variables de entorno introdujo múltiples rutas para la ejecución remota de código, siendo una carga particularmente obvia la demostrada anteriormente. Esta vulnerabilidad fue inicialmente reportada por un investigador de seguridad de Project Zero.
Aunque el comando set-env está obsoleto y no se puede usar por defecto, si un desarrollador establece la variable de entorno ACTIONS_ALLOW_UNSECURE_COMMANDS en un flujo de trabajo, el comando set-env estará disponible y podrá utilizarse:
Es posible eludir la siguiente comprobación:
jobs:
merge-dependabot-pr:
runs-on: ubuntu-latest
if: github.actor == 'dependabot[bot]'
steps:
...
La idea del ataque es activar Dependabot en un repositorio bifurcado de tal manera que un PR en el repositorio bifurcado sea creado por Dependabot, luego se abre un PR desde la rama de Dependabot en el repositorio vulnerable y, finalmente, se activa Dependabot nuevamente para lanzar el flujo de trabajo vulnerable.
Puedes encontrar todos los detalles de explotación aquí: https://www.synacktiv.com/publications/github-actions-exploitation-dependabot
Busca acciones vulnerables conocidas según osv.dev.
Comprueba si hay flujos de trabajo que suban artefactos que contengan archivos sensibles como .git/config. Esta regla se basa en este artículo.
Comprueba si hay credenciales en la configuración de services:. Esta regla proviene de actionlint.
Ejecuta shellcheck en todas las tareas bash. Esta regla proviene de actionlint.
Genera una alerta si se usa una GitHub action local. Por ahora la herramienta no puede analizar los archivos de acciones locales, por lo que se genera una alerta, ya que también pueden contener vulnerabilidades.
Detecta acciones OIDC. Los flujos de trabajo que usan acciones OIDC pueden ser un buen objetivo para acceder a algunos proveedores de nube. No hay ninguna vulnerabilidad asociada a esta regla, pero echar un vistazo más de cerca a esta acción puede ser interesante si hay una vulnerabilidad que esta herramienta no encuentra.
💡 Esta ahora es una regla de depuración; debes añadir --debug-rules para buscarla.
Esta herramienta no podría haberse desarrollado sin actionlint. Muchas gracias a @rhysd.