GitHub, la plateforme d’hébergement de code pour le contrôle de version et la collaboration vient de publier une note d’information consécutive à la mise à jour de sa clé privée RSA SSH. Cette note information vient également lever le voile sur une situation peu commune à laquelle la plateforme a dû faire face cette semaine. En effet, dans le courant de la semaine, GitHub s’est rendu compte que sa clé d’hôte RSA SSH utilisée pour sécuriser les opérations Git pour GitHub a été exposée dans un référentiel GitHub public. Aussi, pour éviter une compromission de leurs serveurs, l’entreprise a-t-elle procédé à la dépréciation de cette clé et en a produit une nouvelle. Mais ces actions ne sont pas de nature à rassurer certains utilisateurs.En attendant un tel problème de sécurité sur GitHub, le premier sentiment qui étreint les utilisateurs qui hébergent leur code sur la plateforme est de savoir si la clé a été exploitée par des tiers malveillants. Pour les personnes extérieures à l’environnement, il faut savoir que SSH, ou shell sécurisé, est un protocole sécurisé et le moyen le plus courant d’administrer en toute sécurité des serveurs distants. À l’aide d’un certain nombre de technologies de chiffrement, SSH fournit un mécanisme permettant d’établir une connexion sécurisée par chiffrement entre deux parties, d’authentifier chaque côté à l’autre et de transmettre des commandes et des sorties dans les deux sens. Dans le cas de GitHub, le système cryptographique utilisé pour sécuriser les opérations SSH est RSA (Rivest-Shamir-Adleman) qui utilise à la fois une clé publique et une clé privée. Comme son nom l’indique, la clé publique est faite pour être divulguée au public, à l’image de l’adresse électronique, si l’analogie est pertinente. Mais la clé privée elle doit rester toujours privée, un peu comme ce qu’est le mot de passe pour la boîte électronique. Toute personne malveillante qui met la main sur la clé privée peut bien évidemment avoir les accès pour effectuer des opérations non permises comme écouter les opérations, accéder à des informations sans permission, voler des informations, etc.
Dans le cas de GitHub, après s’être rendue compte que sa clé d’hôte RSA SSH était exposée sur sa plateforme dans un dépôt public, le niveau d’alerte est passé au rouge, car nombreux sont les individus et entreprises qui hébergent leur code sur la plateforme. C’est pourquoi sa première réaction après avoir découvert la faille de sécurité fut de contenir les effets de l’exposition de la clé et de remplacer cette clé par une nouvelle. Sur son site, l’entreprise a publié depuis plusieurs heures les informations suivantes : « ;Vers 5 h UTC le 24 mars, par prudence, nous avons remplacé notre clé d’hôte RSA SSH utilisée pour sécuriser les opérations Git pour GitHub.com. Nous avons fait cela pour protéger nos utilisateurs contre toute possibilité qu’un adversaire se fasse passer pour GitHub ou écoute clandestinement leurs opérations Git via SSH. Cette clé n’accorde pas l’accès à l’infrastructure de GitHub ou aux données client. Cette modification n’affecte que les opérations Git sur SSH utilisant RSA. Le trafic Web vers GitHub.com et les opérations HTTPS Git ne sont pas affectés ;». Et pour mieux rassurer les utilisateurs de la plateforme, l’entreprise ajouta ceci : « ;Veuillez noter que ce problème n’est pas le résultat d’une compromission des systèmes GitHub ou des informations client. Au lieu de cela, l’exposition était le résultat de ce que nous pensons être une publication par inadvertance d’informations privées. Nous n’avons aucune raison de croire que la clé exposée a été abusée et avons pris cette mesure par prudence ;».
Si vous utilisez les clés ECDSA ou Ed25519, vous ne remarquerez aucun changement et aucune action n’est nécessaire. Par contre si vous voyez le message ci-dessous lors d’une connexion SSH, alors il va falloir changer la clé RSA.
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 | @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s. Please contact your system administrator. Add correct host key in ~/.ssh/known_hosts to get rid of this message. Host key for github.com has changed and you have requested strict checking. Host key verification failed. |
Pour supprimer l’ancienne clé, il faut exécuter la commande suivante : $ ssh-keygen -R github.com
Une autre option consiste à mettre à jour fichier ~/.ssh/known_hosts pour supprimer l’ancienne entrée. Ensuite, vous pouvez ajouter manuellement la ligne suivante pour ajouter la nouvelle entrée de clé publique RSA SSH à votre fichier ~/.ssh/known_hosts :
github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9/hWCqBywINIR+5dIg6JTJ72pcEpEjcYgXkE2YEFXV1JHnsKgbLWNlhScqb2UmyRkQyytRLtL+38TGxkxCflmO+5Z8CSSNY7GidjMIZ7Q4zMjA2n1nGrlTDkzwDCsw+wqFPGQA179cnfGWOWRVruj16z6XyvxvjJwbz0wQZ75XK5tKSb7FNyeIEs4TT4jk+S4dhPeAUC5y+bDYirYgM4GC7uEnztnZyaVWQ7B381AK4Qdrwt51ZqExKbQpTUNn+EjqoTwvqNj4kqx5QUCI0ThS/YkOxJCXmPUWZbhjpCg56i+2aB6CmK2JGhn57K5mj0MNdBXA4/WnwH6XoPWJzK5Nyu2zB3nAZp+S5hpQs+p1vN1/wsjk=
Il est également possible de mettre à jour automatiquement la clé RSA SSH de GitHub.com dans le fichier ~/.ssh/known_hosts, en exécutant ce qui suit dans le terminal :
| Code : | Sélectionner tout |
1 2 | $ ssh-keygen -R github.com $ curl -L https://api.github.com/meta | jq -r '.ssh_keys | .[]' | sed -e 's/^/github.com /' >> ~/.ssh/known_hosts |
Vous pouvez vérifier que vos hôtes se connectent via la nouvelle clé RSA SSH en confirmant que vous voyez l’empreinte suivante : SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s
À noter que les utilisateurs de GitHub Actions peuvent voir des échecs d’exécution dans leurs flux de travail s’ils utilisent actions/checkout avec l’option ssh-key. GitHub informe qu’ils sont en train de mettre à jour l’action actions/checkout dans toutes les balises prises en charge, y compris @v2, @v3 et @main. Si vous épinglez l’action à un SHA de validation et utilisez l’option ssh-key, vous devrez mettre à jour votre flux de travail.
Comme pour tout scandale de fuite de données, les utilisateurs de la plateforme ne sont pas restés indifférents après avoir eu écho des faits. Pour Mike, le fait que cette clé n’était apparemment pas stockée dans un module de sécurité matériel (abrégé HSM en anglais, c’est un dispositif physique spécialisé et hautement fiable qui effectue toutes les principales opérations cryptographiques, y compris le chiffrement, le déchiffrement, l’authentification, la gestion des clés, l’échange de clés, etc.), et que les employés de GitHub aient eu accès à cette clé privée (ce qui leur a permis de la pousser accidentellement) signifie que toute communication avec GitHub depuis la création de l’entreprise doit être considérée comme compromise. Cela signifie essentiellement que, selon votre niveau de paranoïa, vous devrez revoir tout le code qui a déjà interagi avec les référentiels GitHub, et tout code poussé ou extrait des référentiels privés ne peut plus être considéré comme privé. Pour ce dernier, les clients de GitHub font confiance à GitHub/Microsoft pour leur code, ce qui, pour la plupart des entreprises, est un atout de grande valeur. Il ajoute que cela ne le surprendrait pas si tout cela aboutissait à un procès massif. Pas seulement contre GitHub en tant qu’entreprise, mais aussi envers les personnes impliquées (comme le CISO). De plus, comment n’a-t-il jamais été découvert lors d’un audit que la clé privée SSH était en texte brut et accessible ;? Comment GitHub a-t-il pu obtenir la certification ISO l’année dernière, alors qu’ils n’ont même pas placé leurs clés dans un HSM ;? De toute évidence, en tant que client payant, Mike explique qu’il est assez en colère contre GitHub en ce moment.
En ce qui concerne le secret des données hébergées sur GitHub et abordé par Mike, un autre internaute du nom de Phil explique que vous devez partir du principe qu’un nombre important d’employés de GitHub y auront accès. Vous devez supposer que tout est non chiffré sur plusieurs plateaux de disques différents et répliqué à plusieurs endroits différents géographiquement séparés. Il souligne que l’une des choses à laquelle vous renoncez lorsque vous hébergez vos données privées sur le cloud est de contrôler qui et dans quelles circonstances les gens peuvent voir ou modifier vos données privées. Si le contenu des données est important pour vous/votre entreprise sans recours, vous ne devez pas les stocker dans le cloud.
Shank un autre intervenant répond à Mike concernant la certification ISO de GitHub en déclarant que ISO/IEC 27001:2013 ne veut pas dire que vous devez stocker les clés privées dans les HSM. Cela nécessite simplement que vous disposiez d’un SMSI conforme aux normes qui implémente tous les contrôles de l’annexe A et toutes les clauses. L’annexe A et les clauses ne l’exigent pas spécifiquement. Si vous pouvez convaincre un auditeur que vous avez mis en place des contrôles qui répondent à la norme de protection des supports cryptographiques, vous répondez essentiellement à la norme. Les contrôles peuvent être une grande variété d’options et n’exigent pas spécifiquement des détails de mise en œuvre technique.
Concernant toujours ce même point de certification ISO, Bright pour sa part soutient que la certification ISO 27001 ne vous oblige pas à mettre des clés dans un HSM. La norme exige que vous ayez des contrôles en place, que vous soyez conscient de vos risques et que vous teniez un registre des risques. Mais la norme n’exige en aucun cas des HSM. La norme serait même d’accord pour stocker cela sur un lecteur de disquette si les risques qui l’entouraient étaient identifiés et atténués (ou acceptés).
Enfin, pour Tom, cette erreur humaine qui a conduit à l’exposition de la clé RSA SSH suggère que les utilisateurs ont besoin de plus d’informations de la part de GitHub. Pour lui, GitHub devrait communiquer sur la gestion des accès à ces clés en interne afin que les utilisateurs puissent savoir par exemple si les employés de GitHub n’ont pas eu accès directement à cette clé, si l’incident s’est produit dans le cadre d’une opération qui n’a donné qu’un accès temporaire à un employé, ou enfin si ces clés privées sont stockées en clair sur les ordinateurs personnels de plusieurs employés depuis sa création.
Source : GitHub
Et vous ?
Quels commentaires faites-vous de cet incident ;? De quoi remettre en cause la sécurité sur GitHub ;? Comment expliquez-vous cette exposition de la clé privée par un employé de GitHub ;? Que suggérez-vous comme solution pour éviter d’éventuels incidents à l’avenir ;?Voir aussi
Toyota a accidentellement exposé une clé secrète publiquement sur GitHub pendant cinq ans, provoquant une fuite de données et donnant notamment accès aux données de plus de 290 000 clients Des chercheurs ont réussi à extraire la clé utilisée par les processeurs Intel pour chiffrer les MàJ ce qui pourrait permettre à des hackers de mettre à jour les puces avec leur propre microcode Le mode confidentiel de Gmail n’est pas sécurisé ni privé, mais une astuce marketing de Google pour apaiser les utilisateurs, selon ProtonMail Près de 200 Go de code source de Samsung et le code source de la dernière technologie DLSS de Nvidia ont été publiés en ligne par les pirates Lapsus$, GitGuardian a découvert 6 695 clés de Samsung Le code source de Twitch, les gains des streamers et des outils internes ont fuité en ligne, Twitch a confirmé avoir subi une violation de données suite à un changement de configuration