Teknik - Clés privées GitHub App - Parce que... c'est l'épisode 0x365! — PolySécure Podcast

Teknik - Clés privées GitHub App - Parce que... c'est l'épisode 0x365!

PolySécure Podcast · 10/11/2026 05:00 · 42 min
Informatique

Contenu de l'épisode

Parce que… c’est l’épisode 0x365! Shameless plug Description

Cette description a été faite à l’aide de GLM 5.3 Flash, à partir de la transcription qui a été effectuée par ElevenLabs Scribev2. Aucune vérification humaine n’a été faite. Si vous découvrez des erreurs ou des inexactitudes, vous pouvez m’en faire part afin que je procède aux modifications appropriées.

Une application GitHub, un plugin aux privilèges étendus

Une application GitHub fonctionne comme un plugin que l’on greffe sur une organisation. Ce bout de logiciel reçoit des droits et des privilèges, puis agit au nom de l’organisation sur ses dépôts, par exemple pour l’analyse de code dans la CI, la revue automatisée ou le scan de secrets, comme GitGuardian. Le marketplace de GitHub recense des dizaines de milliers d’applications publiques. À l’installation, l’application demande des permissions allant de la simple lecture des dépôts jusqu’à l’administration complète de l’organisation, ainsi qu’un périmètre appelé scope, qui limite l’accès à tous les dépôts ou à une sélection. La combinaison des droits et du scope définit ce qu’elle peut accomplir.

Un mécanisme d’authentification en deux jetons

Côté GitHub, la création d’une application se résume à un nom, une description et surtout une clé privée d’authentification. L’application, déployée où l’on veut, signe un jeton JWT avec cette clé pour interroger l’API et obtenir quelques métadonnées, dont ses permissions et la liste de ses installations. Elle échange ensuite ce jeton d’application contre un jeton d’installation qui lui permet d’agir avec l’identité de l’organisation où elle est installée. Ce second jeton expire au bout de dix minutes maximum, ce qui le rend peu exposé en cas de fuite. Le point critique demeure la clé privée, qui n’a aucune date d’expiration et qui permet de générer un jeton d’installation pour n’importe laquelle des installations de l’application.

Une méthodologie issue du travail sur les clés privées

Gaetan Ferry et son équipe prolongent leurs travaux du NorthSec sur les clés privées fuitées et les certificats. Ils ont exploité leur jeu de données d’environ 500 000 clés privées, restreint aux clés RSA puisque GitHub n’en génère que pour ses applications. Une étape de filtrage contextuel a retenu environ 5 000 candidats dont le contexte de fuite mentionnait GitHub ou un identifiant d’application, typiquement un fichier associant une clé hardcodée et un identifiant reconnaissable, souvent préfixé par Iv1. Chaque clé candidate a ensuite servi à signer un jeton envoyé à l’API pour vérifier sa validité.

Un taux de validité étonnant et un effet de levier

Au total, 474 clés se sont révélées valides, soit près de 10 %, alors que le taux habituel des secrets exposés sur GitHub tourne autour de 1 à 2 %, un résultat surprenant mais qui s’explique. Leur danger tient à l’effet de levier, car une seule clé peut donner accès à des centaines, voire des milliers d’organisations selon le nombre d’installations.

Deux profils d’applications compromises

L’échantillon distingue deux familles. Environ neuf applications sur dix sont à usage très restreint, avec une ou deux installations, souvent privées et conçues pour un besoin interne, comme la coordination avec une infrastructure cloud de build et de test. Leur compromission pénètre en profondeur dans l’écosystème de l’organisation, un atout précieux pour une attaque ciblée. Les applications de marketplace peuvent au contraire toucher un immense public. L’application compromise la plus installée en affichait environ 330 et échangeait des jetons OIDC dans la CI, notamment chez des chaînes automobiles. À l’opposé, la clé de Buil

Plus d'informations