GitHub, la plateforme dhbergement de code pour le contrle de version et la collaboration vient de publier une note dinformation conscutive la mise jour de sa cl prive 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 sest rendu compte que sa cl dhte RSA SSH utilise pour scuriser les oprations Git pour GitHub a t expose dans un rfrentiel GitHub public. Aussi, pour viter une compromission de leurs serveurs, lentreprise a-t-elle procd la dprciation de cette cl et en a produit une nouvelle. Mais ces actions ne sont pas de nature rassurer certains utilisateurs.
En attendant un tel problme de scurit sur GitHub, le premier sentiment qui treint les utilisateurs qui hbergent leur code sur la plateforme est de savoir si la cl a t exploite par des tiers malveillants. Pour les personnes extrieures lenvironnement, il faut savoir que SSH, ou shell scuris, est un protocole scuris et le moyen le plus courant dadministrer en toute scurit des serveurs distants. laide dun certain nombre de technologies de chiffrement, SSH fournit un mcanisme permettant dtablir une connexion scurise par chiffrement entre deux parties, dauthentifier chaque ct lautre et de transmettre des commandes et des sorties dans les deux sens. Dans le cas de GitHub, le systme cryptographique utilis pour scuriser les oprations SSH est RSA (Rivest-Shamir-Adleman) qui utilise la fois une cl publique et une cl prive. Comme son nom lindique, la cl publique est faite pour tre divulgue au public, limage de ladresse lectronique, si lanalogie est pertinente. Mais la cl prive elle doit rester toujours prive, un peu comme ce quest le mot de passe pour la bote lectronique. Toute personne malveillante qui met la main sur la cl prive peut bien videmment avoir les accs pour effectuer des oprations non permises comme couter les oprations, accder des informations sans permission, voler des informations, etc.
Dans le cas de GitHub, aprs stre rendue compte que sa cl dhte RSA SSH tait expose sur sa plateforme dans un dpt public, le niveau dalerte est pass au rouge, car nombreux sont les individus et entreprises qui hbergent leur code sur la plateforme. Cest pourquoi sa premire raction aprs avoir dcouvert la faille de scurit fut de contenir les effets de lexposition de la cl et de remplacer cette cl par une nouvelle. Sur son site, lentreprise a publi depuis plusieurs heures les informations suivantes : Vers 5 h UTC le 24 mars, par prudence, nous avons remplac notre cl dhte RSA SSH utilise pour scuriser les oprations Git pour GitHub.com. Nous avons fait cela pour protger nos utilisateurs contre toute possibilit quun adversaire se fasse passer pour GitHub ou coute clandestinement leurs oprations Git via SSH. Cette cl naccorde pas laccs linfrastructure de GitHub ou aux donnes client. Cette modification naffecte que les oprations Git sur SSH utilisant RSA. Le trafic Web vers GitHub.com et les oprations HTTPS Git ne sont pas affects . Et pour mieux rassurer les utilisateurs de la plateforme, lentreprise ajouta ceci : Veuillez noter que ce problme nest pas le rsultat dune compromission des systmes GitHub ou des informations client. Au lieu de cela, lexposition tait le rsultat de ce que nous pensons tre une publication par inadvertance dinformations prives. Nous navons aucune raison de croire que la cl expose a t abuse et avons pris cette mesure par prudence .
Si vous utilisez les cls ECDSA ou Ed25519, vous ne remarquerez aucun changement et aucune action nest ncessaire. Par contre si vous voyez le message ci-dessous lors dune connexion SSH, alors il va falloir changer la cl RSA.
1 | @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 lancienne cl, il faut excuter la commande suivante : $ ssh-keygen -R github.comUne autre option consiste mettre jour fichier ~/.ssh/known_hosts pour supprimer lancienne entre. Ensuite, vous pouvez ajouter manuellement la ligne suivante pour ajouter la nouvelle entre 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 excutant ce qui suit dans le terminal :
1 | $ 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 vrifier que vos htes se connectent via la nouvelle cl RSA SSH en confirmant que vous voyez lempreinte suivante : SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s noter que les utilisateurs de GitHub Actions peuvent voir des checs dexcution dans leurs flux de travail sils utilisent actions/checkout avec loption ssh-key. GitHub informe quils sont en train de mettre jour laction actions/checkout dans toutes les balises prises en charge, y compris @v2, @v3 et @main. Si vous pinglez laction un SHA de validation et utilisez loption ssh-key, vous devrez mettre jour votre flux de travail.
Comme pour tout scandale de fuite de donnes, les utilisateurs de la plateforme ne sont pas rests indiffrents aprs avoir eu cho des faits. Pour Mike, le fait que cette cl ntait apparemment pas stocke dans un module de scurit matriel (abrg HSM en anglais, cest un dispositif physique spcialis et hautement fiable qui effectue toutes les principales oprations cryptographiques, y compris le chiffrement, le dchiffrement, lauthentification, la gestion des cls, lchange de cls, etc.), et que les employs de GitHub aient eu accs cette cl prive (ce qui leur a permis de la pousser accidentellement) signifie que toute communication avec GitHub depuis la cration de lentreprise doit tre considre comme compromise. Cela signifie essentiellement que, selon votre niveau de paranoa, vous devrez revoir tout le code qui a dj interagi avec les rfrentiels GitHub, et tout code pouss ou extrait des rfrentiels privs ne peut plus tre considr 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 procs massif. Pas seulement contre GitHub en tant quentreprise, mais aussi envers les personnes impliques (comme le CISO). De plus, comment na-t-il jamais t dcouvert lors dun audit que la cl prive SSH tait en texte brut et accessible ? Comment GitHub a-t-il pu obtenir la certification ISO lanne dernire, alors quils nont mme pas plac leurs cls dans un HSM ? De toute vidence, en tant que client payant, Mike explique quil est assez en colre contre GitHub en ce moment.
En ce qui concerne le secret des donnes hberges sur GitHub et abord par Mike, un autre internaute du nom de Phil explique que vous devez partir du principe quun nombre important demploys de GitHub y auront accs. Vous devez supposer que tout est non chiffr sur plusieurs plateaux de disques diffrents et rpliqu plusieurs endroits diffrents gographiquement spars. Il souligne que lune des choses laquelle vous renoncez lorsque vous hbergez vos donnes prives sur le cloud est de contrler qui et dans quelles circonstances les gens peuvent voir ou modifier vos donnes prives. Si le contenu des donnes est important pour vous/votre entreprise sans recours, vous ne devez pas les stocker dans le cloud.
Shank un autre intervenant rpond Mike concernant la certification ISO de GitHub en dclarant que ISO/IEC 27001:2013 ne veut pas dire que vous devez stocker les cls prives dans les HSM. Cela ncessite simplement que vous disposiez dun SMSI conforme aux normes qui implmente tous les contrles de lannexe A et toutes les clauses. Lannexe A et les clauses ne lexigent pas spcifiquement. Si vous pouvez convaincre un auditeur que vous avez mis en place des contrles qui rpondent la norme de protection des supports cryptographiques, vous rpondez essentiellement la norme. Les contrles peuvent tre une grande varit doptions et nexigent pas spcifiquement des dtails de mise en uvre technique.
Concernant toujours ce mme point de certification ISO, Bright pour sa part soutient que la certification ISO 27001 ne vous oblige pas mettre des cls dans un HSM. La norme exige que vous ayez des contrles en place, que vous soyez conscient de vos risques et que vous teniez un registre des risques. Mais la norme nexige en aucun cas des HSM. La norme serait mme daccord pour stocker cela sur un lecteur de disquette si les risques qui lentouraient taient identifis et attnus (ou accepts).
Enfin, pour Tom, cette erreur humaine qui a conduit lexposition de la cl RSA SSH suggre que les utilisateurs ont besoin de plus dinformations de la part de GitHub. Pour lui, GitHub devrait communiquer sur la gestion des accs ces cls en interne afin que les utilisateurs puissent savoir par exemple si les employs de GitHub nont pas eu accs directement cette cl, si lincident sest produit dans le cadre dune opration qui na donn quun accs temporaire un employ, ou enfin si ces cls prives sont stockes en clair sur les ordinateurs personnels de plusieurs employs depuis sa cration.
Source : GitHub
Et vous ?
Quels commentaires faites-vous de cet incident ? De quoi remettre en cause la scurit sur GitHub ?
Comment expliquez-vous cette exposition de la cl prive par un employ de GitHub ?
Que suggrez-vous comme solution pour viter dventuels incidents lavenir ?
Voir aussi