Resumen (Overview)

Resulta que automatizar tus flujos de trabajo también hace que sea increíblemente fácil para los atacantes automatizar tu perdición. Una campaña de ataque autónoma, rastreada como "hackerbot-claw", está acechando actualmente repositorios públicos. ¿Su misión? Encontrar workflows de GitHub Actions inseguros y convertirlos en puertas de enlace para la ejecución de código arbitrario y la exfiltración de credenciales.

Esta campaña no es solo el proyecto de fin de semana de un script-kiddie; ha logrado comprometer con éxito varios proyectos de código abierto de alto perfil. Al abusar de configuraciones erróneas comunes, el bot efectivamente vuelve tu pipeline de CI/CD en tu contra. Si has estado tratando tus triggers de pull_request_target con la imprudencia de un desarrollador en su quinto café del día, es hora de prestar atención.

La Linux Foundation y la OpenSSF están "triagiando" (triage) activamente las consecuencias, pero el bot trabaja más rápido que un comité.

Anatomía del ataque

El bot "hackerbot-claw" no está reinventando la rueda; simplemente está usando la rueda para pasarte por encima. Se dirige específicamente a workflows que:

• Utilizan triggers privilegiados como pull_request_target.
• Ejecutan código no confiable de pull requests (PRs) forkeados sin aislamiento.
• Incluyen scripts de shell inline que confían ciegamente en inputs controlados por el usuario.
• Carecen de cualquier forma de verificación de autorización antes de disparar runners costosos (y peligrosos).

Patrones de ataque observados

1. Inyección directa de scripts: Los atacantes modifican un script dentro de un PR. Si el workflow ejecuta ese script con privilegios del repositorio, el atacante efectivamente se adueña del runner.
2. "Pwn request" (abuso de pull_request_target): Este trigger es el "Modo Dios" de GitHub Actions. Cuando se usa para hacer checkout y ejecutar código desde un fork, otorga a ese código no confiable acceso a secretos y a un GITHUB_TOKEN con permisos de escritura.
3. Inyección de contexto: Los payloads maliciosos se ocultan en nombres de ramas, títulos de PR o rutas de archivos. Si tu workflow hace algo como echo "Checking out ${{ github.head_ref }}", podrías encontrarte ejecutando echo "Checking out "; rm -rf / #.

Una víctima del mundo real: project-akri/akri

En un caso documentado que involucró a project-akri/akri, un PR malicioso introdujo un payload de inyección de shell en un script. Debido a que el workflow carecía de salvaguardas, ejecutó obedientemente los comandos del atacante, demostrando una vez más que las computadoras harán exactamente lo que les digas, incluso si es un suicidio profesional.

Mitigaciones recomendadas

Si no quieres que tu repositorio se convierta en un minero de criptomonedas para alguien más o en un punto de pivote para un ataque a la cadena de suministro, implementa estos controles de inmediato.

1. Refuerza (harden) tus workflows

Deja de usar pull_request_target a menos que sea absolutamente necesario. Si debes usarlo, nunca hagas checkout del código no confiable desde el head del PR.

# MAL: Esto le da al código del fork acceso a tus secretos
on: pull_request_target
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }} # PELIGRO

2. Aplica el principio de menor privilegio

Limita los permisos del GITHUB_TOKEN en la parte superior de tu archivo de workflow. Si un job solo necesita leer el código, indícalo explícitamente.

permissions:
  contents: read
  pull-requests: read

3. Sanitiza los inputs como si tu vida dependiera de ello

Nunca interpoles variables de contexto de GitHub directamente en scripts de shell. Usa variables de entorno en su lugar.

# MAL: Vulnerable a inyección
run: echo "Procesando rama: ${{ github.head_ref }}"

# BIEN: Manejado como datos, no como código
run: echo "Procesando rama: $BRANCH_NAME"
env:
  BRANCH_NAME: ${{ github.head_ref }}

4. Pinnea tus actions

No confíes en etiquetas (tags) como @v1. Los tags pueden ser movidos. Usa el SHA completo del commit para asegurar que el código que estás ejecutando es el código que revisaste.

- uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4.1.0

Alineación con el OpenSSF OSPS Baseline

La campaña actual "hackerbot-claw" apunta exactamente a las brechas abordadas por el OpenSSF OSPS (Open Source Project Security) Baseline. Los proyectos que siguen estas pautas son significativamente más difíciles de comprometer.

• Menor Privilegio: Restringir el GITHUB_TOKEN y usar OIDC para credenciales de nube de corta duración.
• CI/CD Protegido: Requerir la aprobación de un mantenedor para todos los colaboradores primerizos antes de que se ejecuten los workflows.
• Revisión por Pares: Usar CODEOWNERS para exigir que cualquier cambio en .github/workflows/ sea revisado por un humano consciente de la seguridad, no solo por un mantenedor cansado.

Lecturas adicionales y recursos

• Guía oficial de GitHub sobre inyección de scripts
• OpenSSF: Mitigando vectores de ataque en workflows de GitHub
• Wiz.io: Guía de seguridad de GitHub Actions
• Mejores prácticas de OpenSSF SCM

Fuente: Christopher "CRob" Robinson, Chief Technology Officer & Chief Security Architect en OpenSSF / The Linux Foundation.
GitHub | LinkedIn