Faille SHAttered : annonce-t-elle la fin de GIT et de SVN ?

Il y a quelques jours j’ai découvert qu’il y a quelques mois, des chercheurs ont annoncé « SHAttered » et ont partagé les fichiers sur Git-Hub, la première collision de la fonction de hachage SHA-1 sous forme de fichier. Cette annonce exprime donc la fin de SHA-1. Mais annonce-t-elle la fin de tous les algorithmes se basant sur celui-ci dont GIT et SVN ?

Petit rappel sur le hachage

Avant de répondre à la question posée, il est important de bien comprendre les basiques. Certaines personnes font l’erreur entre les notions de Cryptage/Chiffrement et de Hashage qui ont des fonctions bien différentes.

Le chiffrement permet de cacher l’identité de la donnée en entrée, mais permet à celui possédant la clé de la retrouver. C’est comme si vous enfermiez des données dans un coffre fort et que vous le fermiez à clé. Nous savons qu’il y a quelque chose à l’intérieur, mais nous ne savons pas quoi. Il vous est possible de le retrouver en ouvrant le coffre.

Le hachage lui ne sert en théorie, si celui-ci est bien fait, qu’a générer une signature de la donnée en entrée unique au monde et qui ne permet pas de recréer la donnée d’origine depuis sa signature, un peu comme l’ADN pour l’être humain. Cette signature s’appelle l’empreinte. C’est cette méthode qui nous intéresse aujourd’hui.

Il n’y a aucun algorithme infaillible, en tout cas pour l’instant. Mais pour être sûrs que l’algorithme utilisé est robuste, les informaticiens déterminent la robustesse en termes de collision. Une collision est tout simplement deux données en entrée différentes, mais donnant en résultat une même signature. Plus le nombre pour générer une seule collision est grand plus l’algorithme est robuste. Un des premiers algorithmes de hachage connus et démocratisés fut le MD5, mais celui-ci a rapidement été piraté. Ce qui veut dire qu’avec la signature il est possible de recréer la donnée en entrée. Ce qui correspond maintenant à un mauvais chiffrement. Le MD5 a rapidement été remplacé par le SHA-1, qui a su faire valoir sa robustesse et a donc été utilisé dans pas mal de sites web et de logiciels.

En quoi consiste l’attaque ?

L’attaque consiste a réduire au plus proche possible de 0 les possibilités pour trouver une même signature.

Quel rapport avec Git ?

Git stocke toutes les données dans des « objets ». Chaque objet est nommé et identifié à l’aide de l’empreinte SHA-1 de son contenu, et les objets se réfèrent les uns aux autres à l’aide de ces empreintes. Si deux objets distincts ont la même empreinte, il y a collision. En cas de collision, Git ne peut pas savoir à quel objet on fait référence.

Deux objets qui se heurtent accidentellement sont extrêmement improbables. GitHub nous dit que si vous aviez cinq millions de programmeurs générant chacun un commit par seconde, vos chances de générer une seule collision accidentelle, avant que le Soleil ne devienne un géant rouge et n’englobe la Terre, sont d’environ 50%. Soit une probabilité plutôt faible.

Pourquoi les collisions sont-elles importantes pour la sécurité de Git ?

Si Git essaie d’envoyer ou de recevoir un objet en collision sur un dépôt qui contient déjà cette empreinte, le récepteur peut comparer les octets de chaque objet, remarquer le problème et rejeter le nouvel objet. Ce contrôle a été implémenté dans Git dès sa création.

Cependant, les empreintes SHA-1 peuvent être dites de confiance à la suite de divers mécanismes. Par exemple, Git vous permet de signer cryptographiquement un commit ou un tag. Faire signer uniquement le commit ou l’objet de balise lui-même ne sera pas suffisant, car il peut à son tour pointer vers d’autres objets faisant l’objet d’une collision. Une collision dans ces objets pourrait produire une signature qui semble valide, mais qui indique des données différentes de celles du destinataire. Dans une telle attaque, le signataire ne voit que la moitié de la collision, et la victime voit l’autre moitié.

À quoi ressemblerait une attaque de collision contre Git?

L’attaque récente ne peut pas provoquer de collision avec un objet existant. Il ne peut que générer une paire de collisions à partir de zéro, où les deux moitiés de la paire sont similaires, mais contiennent une petite partie de données aléatoires soigneusement sélectionnées qui diffèrent.

Par conséquent, une attaque ressemblerait à ceci:

1. Générer une paire de collisions, où la moitié semble innocente et l’autre fait quelque chose de non désiré. Il est plus facile de le faire avec les fichiers binaires où les humains sont peu susceptibles de remarquer la différence entre les deux moitiés (la récente attaque a utilisé des fichiers PDF à cet effet).
2. Convaincre un projet d’accepter votre moitié innocente, et attendre qu’ils le rajoutent au projet.
3. Distribuer une copie du repo avec la moitié malveillante (soit en entrant dans un serveur d’hébergement, soit en remplaçant l’objet innocent sur le disque, soit en l’hébergeant ailleurs et en demandant aux gens de vérifier leur intégrité en fonction des signatures). Toute personne qui vérifie la signature pensera que le contenu correspond à ce que les propriétaires du projet ont validé.

Comment certains hébergeurs Git tels que GitHub protègent-ils contre des attaques de collision?

La génération d’une collision par force brute coûte trop cher, et le restera pour encore un bon bout de temps. L’attaque récente utilise des techniques spéciales pour exploiter les faiblesses de l’algorithme SHA-1 qui trouvent une collision en moins de temps (100000x fois moins de temps). Ces techniques laissent un motif dans les octets qui peuvent être détectés lors du calcul du SHA-1 de la moitié d’une paire de collisions.

Certains hébergeurs de GIT, tel que GitHubs effectuent maintenant cette détection pour chaque empreinte SHA-1. Il calcule et annule l’opération s’il existe des preuves que l’objet est la moitié d’une paire de collisions. Cela empêche les attaquants d’utiliser le site pour convaincre un projet d’accepter la moitié « innocente » de leur collision, tout en les empêchant d’accueillir la moitié malveillante.

Le code de détection est open-source et disponible sur GitHub et a été écrit par Marc Stevens.

Y a-t-il des collisions Git?

On sait maintenant qu’il y a des collisions SHA-1 et que chaque système se reposant sur ce hachage est compromis, mais il n’y a pourtant pas pour l’instant de collisions GIT.

Eh oui, Git a rajouté une petite modification aux signatures. Les signatures d’objet de Git tiennent compte non seulement des octets bruts des fichiers, mais aussi des informations d’en-tête spécifiques à Git comme la date des commits et autres information.

Les fichiers PDF fournis par les chercheurs SHAttered entrent en collision dans leurs octets bruts, mais pas lorsqu’ils sont ajoutés à un dépôt Git.

Et SVN ?

Si vous utilisez encore SVN, je ne peux que vous conseiller d’être extrêmement vigilant pour l’instant. Aucune correction n’a été publiée à l’heure actuelle. Il est donc maintenant possible de pirater un serveur de versioning se basant sur SVN.

Et les BlockChain?

Je ne vais pas dans cet article vous expliquer ce que fait un blockchain et qui l’utilise. Cependant, sachez que l’intégralité du raisonnement se base sur les algorithmes de signature, mais sur la version SHA-256, moins susceptible aux collisions et dont le hack ne fonctionne pas.

Quels types de systèmes sont affectés?

Toute application qui s’appuie sur SHA-1 pour les signatures numériques, l’intégrité du fichier ou l’identification des fichiers est potentiellement vulnérable. Ceux-ci incluent:

• Signatures des certificats numériques
• Signatures PGP / GPG par courrier électronique
• Signatures des fournisseurs de logiciels
• Mises à jour de logiciels
• Checksums de contrôle des ISO
• Systèmes de sauvegarde
• Systèmes de déduplication
• Certains navigateurs non à jour.
• GIT

Pour plus d’information, n’hésitez pas à faire un tour sur le site des personnes qui ont trouvé cette faille : http://shattered.io/

En espérant que cet article a pu vous éclairer sur la sécurité de vos environnements.