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
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

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Commentaires (56)


tpeg5stan Abonné
Le 27/02/2017 à 10h 40

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


Le 27/02/2017 à 10h 43







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=" />



Jarodd Abonné
Le 27/02/2017 à 10h 44



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.


Le 27/02/2017 à 10h 46

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 …


Le 27/02/2017 à 10h 48



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.


tpeg5stan Abonné
Le 27/02/2017 à 10h 48

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


Le 27/02/2017 à 10h 49

“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.


Jean_G Abonné
Le 27/02/2017 à 10h 50

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…


Le 27/02/2017 à 11h 00

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)


Le 27/02/2017 à 11h 00

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 :)


Le 27/02/2017 à 11h 02

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.


Le 27/02/2017 à 11h 04







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.



Le 27/02/2017 à 11h 11







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.



tpeg5stan Abonné
Le 27/02/2017 à 11h 13







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



Le 27/02/2017 à 11h 19

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.


Le 27/02/2017 à 11h 45

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/


alex.d. Abonné
Le 27/02/2017 à 12h 06







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;



alex.d. Abonné
Le 27/02/2017 à 12h 11







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.”



Le 27/02/2017 à 12h 32

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

Je cherchais des infos la semaine dernière…


Le 27/02/2017 à 12h 49

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.


Le 27/02/2017 à 12h 50







tpeg5stan a écrit :



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





Excellent!



Uther Abonné
Le 27/02/2017 à 12h 54







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é.



Le 27/02/2017 à 12h 56

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 ?


Mimoza Abonné
Le 27/02/2017 à 12h 57

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…


g0d0t Abonné
Le 27/02/2017 à 12h 58

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


Le 27/02/2017 à 13h 04

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


Le 27/02/2017 à 13h 04

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.


Zulgrib Abonné
Le 27/02/2017 à 13h 42

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.


Le 27/02/2017 à 13h 46

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.


Zulgrib Abonné
Le 27/02/2017 à 13h 48

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


Le 27/02/2017 à 13h 51

Merci


Le 27/02/2017 à 13h 53

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=" />


tpeg5stan Abonné
Le 27/02/2017 à 13h 54

au temps pour moi, je n’avais pas compris


Le 27/02/2017 à 13h 59

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 :)


tpeg5stan Abonné
Le 27/02/2017 à 14h 01

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=" />


Le 27/02/2017 à 14h 02

Hash(“Question universelle”) = 42


Le 27/02/2017 à 14h 24

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 ! 😂


fred42 Abonné
Le 27/02/2017 à 14h 28

s/Hash/Réponse/

<img data-src=" />


Le 27/02/2017 à 14h 39

Ç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;


Le 27/02/2017 à 14h 48

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.


fred42 Abonné
Le 27/02/2017 à 14h 57







tijojo a écrit :



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





Il ne permet aucune correction.



tpeg5stan Abonné
Le 27/02/2017 à 15h 33







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=" />



Le 27/02/2017 à 15h 38

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


fred42 Abonné
Le 27/02/2017 à 15h 53

Quelles vacances ?


Le 27/02/2017 à 16h 10

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


fred42 Abonné
Le 27/02/2017 à 16h 15

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)


Le 27/02/2017 à 16h 29

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


Le 27/02/2017 à 16h 59

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;


Le 27/02/2017 à 18h 17

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=" />


tpeg5stan Abonné
Le 27/02/2017 à 19h 12

Personne ne l’a encore posté ?



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


Le 28/02/2017 à 09h 10







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



Le 28/02/2017 à 09h 14







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



alex.d. Abonné
Le 28/02/2017 à 09h 26







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;



fred42 Abonné
Le 28/02/2017 à 10h 45







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.



Le 28/02/2017 à 11h 59

“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;


Le 28/02/2017 à 13h 07

&lt;3