Permisos de Workflow Excesivos

Los workflows de GitHub Actions con permissions: write-all o sin bloque de permissions explicito otorgan al GITHUB_TOKEN acceso excesivo, permitiendo que un paso comprometido modifique codigo, cree releases, escriba paquetes o cambie configuraciones del repositorio.

Cómo Funciona

Cada ejecucion de workflow de GitHub Actions recibe un GITHUB_TOKEN con permisos delimitados al repositorio. Por defecto (para repositorios creados antes de febrero 2023), este token tiene acceso de lectura y escritura a todos los scopes del repositorio: contents, packages, issues, pull-requests, deployments y mas. Si cualquier paso en el workflow es comprometido (via un ataque a la cadena de suministro en una action, inyeccion de script o confusion de dependencias), el atacante hereda todos estos permisos. Puede pushear codigo a cualquier rama, crear releases con artifacts maliciosos, escribir en GitHub Packages o modificar issues y PRs. GitHub introdujo permisos granulares para limitar el GITHUB_TOKEN solo a los scopes que un workflow realmente necesita.

Código Vulnerable

# BAD: no permissions block = default read-write to everything
name: CI
on: [push]
# No permissions block -- GITHUB_TOKEN gets full read-write access
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test
---
# Also BAD: explicitly granting write-all
name: CI
on: [push]
permissions: write-all
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test  # only needs read access, but has write-all

Código Seguro

# GOOD: minimal permissions at workflow and job level
name: CI
on: [push]
permissions:
  contents: read  # only what's needed at workflow level
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test
  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    permissions:
      contents: read
      deployments: write  # only this job needs deploy permission
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh

Ejemplo Real

En 2022, el equipo de GitHub Actions revelo que los workflows sin bloques de permissions explicitos eran una superficie de riesgo importante. Varios ataques a la cadena de suministro explotaron el GITHUB_TOKEN con write-all por defecto para pushear codigo malicioso o publicar paquetes contaminados. GitHub cambio el valor predeterminado para repositorios nuevos a solo lectura e introdujo la clave permissions especificamente para abordar este vector de ataque.

Cómo Prevenirlo

Configura permissions: read-all o permissions: {} a nivel de workflow y otorga permisos especificos solo a los jobs que los necesiten
Cambia los permisos predeterminados del GITHUB_TOKEN a solo lectura en Settings > Actions > General de tu organizacion
Usa bloques de permissions a nivel de job para delimitar el GITHUB_TOKEN de cada job al acceso minimo requerido
Audita todos los archivos de workflow buscando bloques de permissions faltantes o permisos excesivamente amplios usando actionlint o el overview de seguridad de GitHub

Tecnologías Afectadas

GitHub ActionsNode.jsPythonDocker

Data Hogo detecta esta vulnerabilidad automáticamente.

Escanea Tu Repo Gratis

Vulnerabilidades Relacionadas

GitHub Actions Sin Fijar a SHA

high

Usar GitHub Actions referenciados por tags mutables como @main o @v3 en lugar de SHAs de commit completos significa que una action comprometida o secuestrada puede inyectar codigo malicioso en tu pipeline CI sin ningun cambio en tu archivo workflow.

CWE-1395OWASP A08:2021

Inyeccion de Script en GitHub Actions

critical

Usar datos de eventos no confiables como github.event.issue.title directamente dentro de bloques run: permite a los atacantes inyectar comandos shell arbitrarios en tu pipeline CI creando titulos de issues, cuerpos de PR o mensajes de commit maliciosos.

CWE-94OWASP A03:2021

Secretos Filtrados en Logs de CI

high

Imprimir o hacer echo de variables de entorno que contienen secretos en scripts de CI los expone en los logs de build, que frecuentemente son accesibles para todos los colaboradores del repositorio y a veces visibles publicamente en proyectos open-source.

CWE-532OWASP A09:2021

Riesgos de Runners Self-Hosted

high

Usar runners self-hosted de GitHub Actions con pull_request_target o workflows de forks publicos permite que codigo no confiable de contribuidores externos se ejecute en tu infraestructura con acceso a secrets, estado persistido y la red del host.

CWE-94OWASP A08:2021