Vulnerabilidad crítica en un repo de Stripe: ¿Cómo asegurar los Workflows de GitHub Actions? Entendiendo "Pwn Request"

Una vulnerabilidad grave en el GitHub Actions Workflow de Stripe permitió a un investigador obtener acceso al token de GitHub del repositorio. Esta vulnerabilidad, conocida como "Pwn Request", explotó la confianza depositada en los pull requests para obtener acceso no autorizado a información confidencial y realizar acciones como fusionar commits no autorizados en la rama principal (main branch).

Este incidente sirve como un claro recordatorio de la importancia de comprender y asegurar los workflows de GitHub Actions y los riesgos potenciales que representan el código no confiable y los actores maliciosos.

Entendiendo el exploit y la vulnerabilidad

¿Recuerdas aquella vez que dejaste tus cuentas de redes sociales abiertas en el computador de un amigo? Esta brecha de seguridad es algo así, pero en lugar de ser trolleado por tu descuido, involucra código, credenciales y una gran cantidad de daños potenciales a todo tu código (codebase) e incluso entornos de producción (production environments).

Un investigador de seguridad, probablemente impulsado por la cafeína y la adrenalina, encontró una vulnerabilidad "pwn request" en un repositorio público de Stripe. Esta vulnerabilidad les permitió hacer cosas que no deberían poder hacer, como fusionar commits no autorizados en la rama principal (main branch) y, lo que es peor, tener en sus manos el preciado token de GitHub del workflow.

La vulnerabilidad en sí misma es un caso clásico de "Pwn Request", que, a pesar de sonar como algo que un hacker diría en una mala película de acción, es una falla de seguridad grave. En términos simples, aprovecha la confianza depositada en los pull requests.

Así es como sucedió:

• Triggers riesgosos: El workflow vulnerable usaba el trigger pull_request_target, que, en el mundo de GitHub Actions, es como darle las llaves de tu casa a cualquier desconocido que te las pida. Este trigger se ejecuta con privilegios elevados, lo que significa que tiene acceso a todo, incluidos los secretos como el token de GitHub.

• Sacando código de forks que no son de confianza: Para empeorar las cosas, el workflow extraía código de una referencia (ref) explícita que se originó en un fork que no era de confianza. Esto es como invitar a un extraño a tu casa y dejar que revise tus objetos de valor.

Esta combinación de un trigger riesgoso y una extracción de código (checkout) sin verificar creó la tormenta perfecta para que el investigador la explotara.

El ataque paso a paso:

Ahora, vamos a desglosar el ataque como si fuera un montaje de película de atracos, con música dramática y tomas en cámara lenta:

• Bifurcando (forking) y enviando un pull request malicioso: El investigador, como cualquier buen hacker que se precie, comenzó bifurcando (forking) el repositorio de Stripe y enviando un pull request (PR) que contenía código malicioso. Cual caballo de madera atravesando las puertas de Troya.

• Explotando el workflow: El workflow de GitHub Actions del repositorio, sin saberlo y activado por el evento pull_request_target, ejecutó alegremente el código malicioso del investigador. Esto le dio al atacante acceso al token de GitHub del repositorio, las joyas de la corona de esta operación.

• Fusionando el PR y extrayendo el token: Con el token de GitHub en su poder, el investigador pudo fusionar automáticamente su PR en la rama principal (main branch), sin pasar por ningún proceso de revisión. Es como entrar directamente a la bóveda porque engañaste a alguien para que te regale la llave. En un PR posterior, el investigador decidió presumir un poco y extrajo el token de GitHub a un servidor remoto usando wget.

La evidencia del exploit:

• El pull request del investigador: https://github.com/stripe-samples/accept-a-payment/pull/2719
• El pull request del exploit que extrajo el token de GitHub: https://github.com/stripe-samples/accept-a-payment/pull/2723/files

Implicaciones y riesgos

Este incidente es un claro recordatorio de que incluso los gigantes tecnológicos como Stripe no son inmunes a las vulnerabilidades de seguridad. He aquí por qué esta brecha debería poner a todos nerviosos:

• Ejecución de código no autorizada: Imagina que alguien entra a tu casa y reorganiza tus muebles. Ahora imagina que entran en tu repositorio de código e inyectan código malicioso. Eso es precisamente lo que permite la ejecución de código no autorizada, lo que podría dar lugar a puertas traseras (backdoors), software comprometido y un montón de dolores de cabeza.
• Robo de credenciales de CI/CD: Robar credenciales de CI/CD, como los tokens de GitHub, es como entregar la llave maestra de toda tu infraestructura digital. Los atacantes pueden acceder a los registros de packages, a los entornos de cloud e incluso a repositorios de código más confidenciales.
• Fusiones no autorizadas: Al automatizar la fusión de PR con tokens robados, los atacantes pueden eludir esos molestos procesos de revisión manual que están ahí por una razón. Esto puede dar lugar a graves riesgos de seguridad, como los compromisos de la cadena de suministro (supply chain), en los que el código malicioso se cuela en el software de uso generalizado.

Prevención de futuros ataques

Entonces, ¿cómo podemos prevenir estos ataques y evitar convertirnos en la próxima historia con moraleja en el mundo de la ciberseguridad? Aquí tienes algunas ideas:

• Trata tus workflows de GitHub Actions como si fueran de la realeza: No te limites a configurarlos y olvidarte de ellos. Revisa y actualiza periódicamente tus workflows, prestando especial atención a los triggers utilizados y a los permisos concedidos.
• Adopta el principio de mínimo privilegio: Concede a tus workflows el mínimo acceso indispensable para que hagan su trabajo. Limitar el alcance de los tokens es como guardar bajo llave tus objetos de valor: dificulta mucho más que los atacantes se lleven todo si consiguen burlar tus defensas.
• Implementa reglas estrictas de protección de ramas: Dificulta que se cuelen cambios no autorizados aplicando reglas de protección de ramas, como exigir varias aprobaciones para las fusiones de PR. Es como tener un sistema de seguridad para tu base de código (codebase).
• Utiliza un runner reforzado: El Harden-Runner de StepSecurity (https://github.com/step-security/harden-runner) es un salvavidas (o mejor dicho, un salvavidas de código). Añade una capa extra de seguridad al evitar que los datos sensibles, como esos jugosos tokens de GitHub, sean extraídos por código malicioso. Piensa en él como el equivalente en ciberseguridad a una bóveda para tus activos más valiosos.

GitHub - step-security/harden-runner: Network egress filtering and runtime security for GitHub-hosted and self-hosted runners

Network egress filtering and runtime security for GitHub-hosted and self-hosted runners - step-security/harden-runner

GitHubstep-security

Resumen

Esta brecha de seguridad en el repositorio de Stripe es una llamada de atención para todos aquellos que piensan que "a mí no me puede pasar". Asegurar tus pipelines de CI/CD, especialmente aquellos que utilizan GitHub Actions, no es una sugerencia, es una necesidad. Implementando medidas de seguridad sólidas, podemos hacer la vida mucho más difícil a los atacantes y mantener nuestras bases de código (codebases), y nuestra cordura, intactas.

Fuente

Security Breach in Stripe Repo: A Deep Dive into the “Pwn Request” Vulnerability

The Vulnerability in Stripe’s GitHub Actions Workflow Shows Why Securing CI/CD Pipelines Is Essential