SHA-1 : des chercheurs prouvent l'exploitation des collisions dans une attaque

SHA-1 : des chercheurs prouvent l’exploitation des collisions dans une attaque

Jumeau maléfique

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

27/02/2017 4 minutes
56

SHA-1 : des chercheurs prouvent l'exploitation des collisions dans une attaque

Deux équipes ont travaillé à la réalisation d’une méthode capable de produire en un temps « raisonnable » des collisions avec l’algorithme SHA-1. Un danger qui n’est pas neuf, mais qui s’amplifie, avec dans l’ombre la perspective de pouvoir falsifier des documents et donc faciliter certaines attaques.

L’algorithme SHA-1 (Secure Hash Algorithm) permet le hachage des données (voir notre dossier) afin d'en assurer l'intégrité. Pour cela, il produit une empreinte de 160 bits, censément unique.

On retrouve souvent le SHA-1 par exemple sur différents sites de téléchargement, quand l’utilisateur est invité à contrôler qu’il a bien le bon fichier mais aussi dans de nombreux services et outil de chiffrement. Mais SHA-1 n’est plus tout à fait considéré comme sûr depuis des années, et les principaux navigateurs comptent l’abandonner dans les mois qui viennent.

Repérer et exploiter les collisions

Pour montrer à quel point le SHA-1 n’est plus digne de confiance, deux équipes se sont associées, l’une de l’institut CWI d’Amsterdam, l’autre de Google. Dans un billet publié il y a quelques jours, les chercheurs en sécurité ont annoncé avoir trouvé une méthode, SHAttered, leur permettant de découvrir des cas de collision 100 000 fois plus rapidement qu’avec une méthode classique par force brute.

La collision est la bête noire de ce type d’algorithme. Elle se produit quand deux fichiers différents génèrent le même hash. Ce qui signifie que l’un des deux fichiers pourrait être malveillant et se faire passer pour la version authentique.

Sur le site ouvert pour l’occasion, les chercheurs évoquent les dangers inhérents à la collision. Ils présentent également deux fichiers PDF au contenu différent mais disposant de la même empreinte SHA-1. Or, on peut imaginer que le premier soit un contrat signé par un client, tandis que d’autre sera une version altérée, portant lui aussi la signature.

Faciliter les collisions revient donc à augmenter le risque que des données se fassent passer pour ce qu’elles ne sont pas. Signatures de documents, certificats électroniques, contrôle de versions, systèmes de sauvegarde, mises à jour de logiciels, correctifs de sécurité et autres sommes de contrôles pour les images ISO sont concernés.

Un défaut connu depuis 12 ans

Comme indiqué cependant, le défaut de sécurité dans SHA-1 n’est pas une nouveauté. L’expert en sécurité et cryptanalyse Bruce Schneier consacrait ainsi déjà en 2005 un article sur les collisions dans l’algorithme. Il avait été capable d’en trouver en 2^69 calculs, ce qui représentait déjà il y a 12 ans une méthode 2 000 fois plus rapide que la force brute.

Ce qui explique d’ailleurs en partie pourquoi Microsoft et Mozilla (entre autres) préparent actuellement l’abandon de SHA-1, d'ici la fin de l’année. Google l’a supprimé le mois dernier lors d’une mise à jour de Chrome. L’éditeur attendra d’ailleurs 90 jours avant de révéler le code d’exploitation et la méthode détaillée, en accord avec la politique de sa Zero Day Initiative. Les chercheurs se veulent cependant rassurants : ils n’ont observé aucune attaque par ce biais pour l’instant.

Un outil simple pour vérifier les documents

Le site des chercheurs fournit en outre une méthode simple pour vérifier si un document quelconque pourrait être impliqué dans une attaque par collision. Cette protection a été déployée par Google dans Gmail et sa Gsuite afin de signaler à la volée un éventuel problème. Le code de détection a été écrit par Marc Stevens (CWI) et Dan Shumow (Microsoft), et est disponible dans un dépôt GitHub. 

Côté utilisateur, il n’y a pas grand-chose à faire, à part s’assurer que la dernière révision du navigateur est installée. Côté développeur par contre, il faudra basculer vers des algorithmes beaucoup plus récents, comme SHA-256 ou SHA-3. Notez cependant que dans le cas de Git, Linus Torvalds a indiqué durant le week-end que plusieurs protections avaient déjà été mises en place pour empêcher ce type d'attaque de fonctionner.

56

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Repérer et exploiter les collisions

Un défaut connu depuis 12 ans

Un outil simple pour vérifier les documents

Commentaires (56)


Il est plus que temps de migrer vers md4, voire md5 si vous êtes vraiment parano&nbsp;<img data-src=" />








tpeg5stan a écrit :



Il est plus que temps de migrer vers md4, voire md5 si vous êtes vraiment parano <img data-src=" />





taquin, va <img data-src=" />





Google l’a supprimé le mois dernier lors d’une mise à jour de Chrome.





Firefox aussi lance la mise à jour.





Notez cependant que dans le cas de Git, Linus Torvalds a indiqué durant le week-end&nbsp;que plusieurs protections avaient déjà été mises en place pour empêcher ce type d’attaque de fonctionner.





C’est-à-dire ? Je n’ai pas vu de mise à jour de git sur mon poste ce week-end.


C’est impressionnant cette obsolescence des hachages.

Par contre SHA256 commence aussi a montrer ses faiblesses.

Pourquoi toujours tarder? Economiser un peu de charge CPU face a la sécurité a rarement été un paris gagnant jusqu’à présent …




L’algorithme SHA-1 (Secure Hash Algorithm) permet le hachage des données (voir notre dossier) afin d’en assurer l’intégrité. Pour cela, il produit une empreinte de 160 bits, censément unique.





Non, par définition l’empreinte n’est pas unique. Il est juste censément impossible “dans un temps raisonnable” de déterminer un jeu de données différent ayant la même empreinte.


Tu as un graphe d’évolution ici, ça permet de mieux visualiser :&nbsphttp://valerieaurora.org/hash.html


“on peut imaginer que le premier soit un contrat signé par un client, tandis que d’autre sera une version altérée, portant lui aussi la signature.”







Pour que ce soit exploitable ainsi, encore faudrait-il qu’a partir d’un fichier donné on soit capable de générer son “jumeau de signature” avec le contenu qu’on désire. J’en doute un peu.


SHA256 avait pour cahier des charges d’optimiser les calculs, et se révèle en pratique équivalent (en charge de calcul) que SHA1.



Le problème de quitter SHA1 est plus complexe, notamment à cause des autorités de certification au-dessus qui ne savent pas faire, ou qui demandent à être changées (ou ajoutées). Pas simple dans un contexte professionnel.



Après, il n’est pas interdit d’utiliser SHA1 : dans certains cas il est largement suffisant. Il faut toujours évaluer le risque résiduel, en sécurité informatique…


Qui dit HASH, dit collisions, il n’y a pas de magie, seul l’infini permet d’éviter les collisions, mais on ne voudrait pas d’une clef infiniment grande…



Pour le moment, ils n’ont pas diffusé grand chose comme infos, il y a deux points où je serais curieux d’avoir l’explication :&nbsp;

1/ Comment ils ont réduit la complexité (je sens que je vais mourir suite à ce cours de maths)

2/ Comment ils détectent les mauvais clones dans leur outil (mais là j’imagine que pour faire le mauvais clone, on ajoute un truc dans le fichier qui pourrait apparaître bizarre car inutile dans son format)


Quoi? Tu veux dire qu’en 160 bit on ne peut pas recréer l’intégralité de tout ce qui existe? Dommage, on avait là l’archivage ultime :)


J’ai vu des poc justement où ils changent ce qu’ils veulent et par la suite ils rajoutent des bits invisible sur le rendu pour avoir une collision.








CoooolRaoul a écrit :



“on peut imaginer que le premier soit un contrat signé par un client, tandis que d’autre sera une version altérée, portant lui aussi la signature.”







Pour que ce soit exploitable ainsi, encore faudrait-il qu’a partir d’un fichier donné on soit capable de générer son “jumeau de signature” avec le contenu qu’on désire. J’en doute un peu.







C’est justement tout l’objet de cette annonce : on est capable de generer un fichier a volonté avec une signature identique.

Et c’est pour ça que c’est grave.









KP2 a écrit :



C’est justement tout l’objet de cette annonce : on est capable de generer un fichier a volonté avec une signature identique.

Et c’est pour ça que c’est grave.





Ca doit pas être simple pour autant de créer un fichier qui contient à la fois ce que tu veux et génère la signature attendue. Il faut prévoir une partie de données junk qui ne seront là que pour influencer ton hash.



Je soupçonne que la faiblesse est plutôt sur les mots de passe, pour lesquels tu te moques de leur signification tant que tu génères le bon hash.









KP2 a écrit :



capable de generer un fichier a volonté&nbsp;&nbsp;



Pas à volonté non plus, ils ont mis longtemps avec des grosses ressources, et ils n’ont pas encore publié tous leurs détails.

On sait maintenant encore plus qu’avant qu’on ne doit pas faire confiance à SHA-1, et avant que ce soit exploitable plus largement, il faut attendre quelques années àmha



Oui, mais comme dit Linus, certains types de fichiers se prêtent «mieux» à l’ajout de ces données junk que d’autres. Ce n’est pas un hasard si les chercheurs parlent de documents pdf.


Sur le problème de collision sur sha1:



* on pense à Git mais c’est svn qui a eu le plus gros problème (ça pète le dépôt. cf dépôt webkit)

* pour git, il stocke la longueur donc ce qui complexifie grandement l’attaque (c’est pourquoi Linux dit qu’il y a pas le feu au lac)

* dans Git, le sha1 ne sert pas à authentifier un commit donc il fallait déjà signer les commits si on voulait être sur des données

* je ne connais pas le successeur de sha1 mais un bon prétendant est peut-être à voir du côté dehttps://blake2.net/








KP2 a écrit :



C’est justement tout l’objet de cette annonce : on est capable de generer un fichier a volonté avec une signature identique.

Et c’est pour ça que c’est grave.





Pas tout-à-fait. Ils ne partent pas de n’importe quel fichier de départ. Ils génèrent deux pdf qui ont un hash en collision, mais les deux sont générés avec du padding qui va bien.

Si tu cherches une collision sur un fichier donné, c’est un autre problème.

&nbsp;









cosmocat a écrit :



* dans Git, le sha1 ne sert pas à authentifier un commit donc il fallait déjà signer les commits si on voulait être sur des données





Je ne comprends pas ça comme ça :

“ in git we also end up using the SHA1 when we use “real” cryptography for signing the resulting trees, so the hash does end up being part of a certain chain of trust. So we do take advantage of some of the actual security features of a good cryptographic hash, and so breaking SHA1 does have real downsides for us.”



Merci pour le lien à propos de la réponse de Linus sur GIT.

Je cherchais des infos la semaine dernière…


Une fonction de hash n’est pas réversible. Donc ton archivage ultime n’était en fait pas du tout un système d’archivage.








tpeg5stan a écrit :



Tu as un graphe d’évolution ici, ça permet de mieux visualiser :&nbsp;http://valerieaurora.org/hash.html





Excellent!









CoooolRaoul a écrit :



Pour que ce soit exploitable ainsi, encore faudrait-il qu’a partir d’un fichier donné on soit capable de générer son “jumeau de signature” avec le contenu qu’on désire. J’en doute un peu.





&nbsp; Sauf que beaucoup de format de fichiers possèdent des mécanisme comme des commentaires ou diverses métadonnées qui permettent de cacher du contenu invisible qui sert uniquement à provoquer la collision alors que le reste du document est comme souhaité.



Idée à la con (ou pas ?) : et pourquoi ne pas utiliser deux hash en meme temps, même s’ils sont réputés “risqués” ?

Quelle est la probabilité / difficulté pour avoir une collision réussie à la fois sur le SHA-1 et le MD5 d’un fichier ?


Il n’y a pas que les navigateurs qui vont avoir des soucis mais aussi les VCS, voir l’article ici :https://www.developpez.com/actu/119516/Un-developpeur-teste-dans-Webkit-les-deux…


Je crois que c’est justement ce qu’il soulignait, de manière humoristique :p


je dirai faible. nulle si tu contrains en plus la taille


J’ai déjà vu des gens couper un mdp en deux et hasher avec deux algos différents chaque partie. Le principe reste le même donc je ne pense pas qu’il y ait quelque chose qui l’interdise. Après pour un serveur web, selon son traffic, peut-être que ça peut plomber ses perfs, je vois que ça.


Blizzard utilisaient des collisions d’empreinte pour que chaque joueurs ait la même carte dans une langue différent sur Warcraft III, réutilisé plus tard pour les versions traduites de la carte DoTa.


Non mais non mais non …. Couper un mot de passe en deux pour utiliser 2 fonctions de hash !!! Quelle horreur.&nbsp;




  • Règle n°1 en crypto : Si vous n’êtes pas un expert, n’inventez pas vos protocoles (et ne mettez pas en oeuvre vous même les protocoles) ! &nbsp;

  • Règle n°2 en crypto : Vous n’êtes pas un expert (et moi non plus).



    Couper un mot de passe en deux … si j’ai un mot de passe de 8 caractères (ce qui est malheureusement considéré comme long pour beaucoup de gens) ça fait 2 hashs sur des mots de passes de 4 caractères …. donc je te trouve une image inverse&nbsp;(et tu peux choisir l’algo de hash que tu veux) par force brute en moins de 2x10 minutes … sur mon smartphone … en jouant à un jeu 3D en même temps dessus … avec un code écrit en brainfuck (bon ok, peut-être pas en brainfuck) !



    La force des solutions crypto c’est quelles sont éprouvées par toute une communauté de chercheurs/scientifiques/ingénieurs/industriels. Et c’est pour ça que l’on change régulièrement d’algorithme de référence : on découvre de nouvelles faiblesses sur des algos “réputés” fiables.


Pour ça que certains sites donnent le md5 et le sha-1 en même temps je présume ? (et l’empreinte sha-256)


ah je connaissais Ook! mais pas son origine.

C’est toujours beau de voir des gens se dépasser de la sorte <img data-src=" />


au temps pour moi, je n’avais pas compris


Juste pour préciser, je ne parlais pas de faire un SHA-1 sur le MD5, mais de calculer en parallèle le MD5 et le SHA-1 d’un fichier, et de les comparer séparément.



Mais j’adore la réponse de tijojo :)


oui, oui, je saisis mieux l’idée, mais du coup tu perds un peu l’intérêt du hash, d’en avoir deux <img data-src=" />


Hash(“Question universelle”) = 42


Md5 est fortement utilisé pour vérifier qu’un téléchargement c’est bien passé. Si tu veux de la sécu, de la vrai : CRC32 ça roxx ! 😂


s/Hash/Réponse/

<img data-src=" />


Ça peu sembler une bonne idée mais je ferais toujours la même réponse : ne pas essayer d’inventer son protocole crypto. Je suis rouillé en md5 (et en sha-1) mais tu as potentiellement des comportements similaires entre les deux algos qui font qu’une attaque par image inverse ne serait pas beaucoup plus compliqué sur le duo. &nbsp;Si la solution était si simple, sha-2 serait la concaténation d’un md5 et d’un sha1 (en général, c’est pas grave si le hashé est légèrement plus grand).

J’aime beaucoup le lien qui a été donné précédemment :&nbsp;http://valerieaurora.org/hash.html.&nbsp;

&nbsp;

Donc, comme disais le poète : “Écoutez, laissez la police faire son travail, dès que j’aurai de plus amples informations croyez bien que vous en serez les premiers informés.“Ou encore mieux, faîtes des études en cryptographie ou en sécurité informatique et faites évaluer votre proposition (accompagné de sa preuve) par la communauté scientifique.



&nbsp;Après, ajouter des couches ou des vérifications de cohérence des données réduit le risque (et c’est probablement ce qui fait dire à Linus qu’il n’y a pas le feu au lac). Mais, malgré tout, la conclusion est qu’il est urgent d’envisager à penser à commencer un abandon de sha-1 (et de md5 pour ceux qui n’aurais pas déjà franchi le pas).

&nbsp;


Attention, CRC32 est une fonction de hashage utilisé comme code correcteur d’erreur. Ce n’est pas un hashage cryptographique (résistant aux attaques par image inverse) cf. wikipedia. C’est à dire que tu peux modifier le fichier source intentionnellement et sans trop de difficulté en conservant la même signature (ce que l’on reproche à sha-1 maintenant). L’utilisation de md5 pour les téléchargement c’est un petit détournement du principe initial de l’algo qui se voulais être un hash crypto à l’origine. Md5 garde l’avantage d’être dispo dans tous les langages et d’avoir pleins d’outils qui l’utilisent mais grosso modo, tu pourrais donner un modulo des bites du fichier, tu aurais &nbsp;presque la même garanti de non modification (semi-)aléatoire.








tijojo a écrit :



Attention, CRC32 est une fonction de hashage utilisé comme code correcteur détecteur d’erreur.





Il ne permet aucune correction.









Out of Atomic a écrit :



Md5 est fortement utilisé pour vérifier qu’un téléchargement c’est bien passé.&nbsp;&nbsp;



&nbsp;Oui,c’est vrai&nbsp;<img data-src=" />



Mais pas trop pour la sécurité, quand même&nbsp;<img data-src=" />



Ok avec le fond, mais sinon oh, la fin des vacances ça vous a mis de mauvais poil ?! fallait pas en prendre alors.


Quelles vacances ?


vacances scolaires de février, période de ski ect.


Et c’était obligatoire d’être en vacances à ce moment ?



Tout le monde n’est pas en âge scolaire enseignant ou skieur sur NXI.



Edit : ah, j’oubliais : on écrit “etc.” abréviation de “et caetera” (et les autres choses)


Aucun rapport avec le fait d’être enseignant… Juste rapport avec le fait d’avoir des enfants. Bref.


Non non… c’était pas dit méchamment … &nbsp;:o) Des fois, j’oublie que je dois ajouter plus de smiley pour être bien compris par écrit. Je voulais juste donner un avis à sur le problème posé :o).



Sinon je suis d’accord avec Fred … c’est bien pour la détection d’erreur. Je voulais juste dire que CRC est un algo qui vient plutôt du domaine de la correction d’erreur (au sens large)/théorie de l’information plus que du domaine de la sécu info.&nbsp;<img data-src=" />



Enfin pour les vacs … Ben, dans certains métier, tu travailles mieux quand les étudiants sont pas là (genre enseignant-chercheur) ;o)&nbsp;


Il y a des spécialistes en crypto sur NextInpact qui n’en sont pas vraiment… alors dans le doute que ces gens créent des sites qui hébergent mes données, je préfère le préciser. <img data-src=" />


Personne ne l’a encore posté ?



Bon, le commitstrip du jour :&nbsphttp://www.commitstrip.com/fr/2017/02/27/17279/








tijojo a écrit :



[…]

Enfin pour les vacs … Ben, dans certains métier, tu travailles mieux quand les étudiants sont pas là (genre enseignant-chercheur) ;o)&nbsp;



Et en Île&nbsp; de France, tu trouves plus facilement une place assise dans le train









tijojo a écrit :



[…]

&nbsp;ajouter des couches ou des vérifications de cohérence des données réduit le risque (et c’est probablement ce qui fait dire à Linus qu’il n’y a pas le feu au lac) […]





Ben oui, si j’ai bien compris, il fait remarquer que:




  • l’ajout de «junk data» dans un source C ne va pas plaire au compilateur

  • passer par les commentaires n’est pas forcément une option non plus,

    &nbsp; parce que git emploie quelques contrôles de cohérences.



    Par contre, il dit bien que ceux qui utilisent git pour gérer des documents pdf ne sont effectivement pas à l’abri









shadowfox a écrit :



Aucun rapport avec le fait d’être enseignant… Juste rapport avec le fait d’avoir des enfants. Bref.





D’avoir des enfants et d’être en zone B.

&nbsp;









alex.d. a écrit :



D’avoir des enfants et d’être en zone B.





Et avoir beaucoup de vacances pour les prendre avec ses enfants à chaque fois.



“Pour cela, il produit une empreinte de 160 bits, censément unique.“Non ce n’est pas tout à fait ça la promesse de SHA-1.La promesse est : qu’il est en pratique (avec la puissance de calcul disponible) impossible de trouver deux messages différents qui ont la même empreinte, même si on sais qu’en théorie ça existe.&nbsp;