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
Image: BleepingComputer.com
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.
¿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.
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.
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.
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:
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.
wget.
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:
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:
step-security
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.
Un malware corriendo dentro de un contenedor puede explotar un bug del kernel, escalar a root y, de repente, está en el host. El límite del contenedor se vuelve decorativo.
Los proveedores de nube construyen infraestructura física impresionante y resiliente, pero no pueden hacer que la geopolítica o la física sean irrelevantes. Una región puede caerse por horas, meses o para siempre. Tu arquitectura debería asumir esa posibilidad y ubicar los datos en consecuencia.
