L’algorithme de hachage SHA-1 n’est plus en odeur de sainteté depuis que des chercheurs ont montré de quelle manière des collisions pouvaient être exploitées dans des attaques. GitHub, qui l’utilise largement, a expliqué hier soir les mécanismes mis en place pour protéger ses utilisateurs.
Une attaque par collision se base sur l’idée qu’un algorithme puisse produire le même hash pour deux fichiers différents. Véritable bête noire dans ce domaine, une collision peut être exploitée pour faire passer un fichier malveillant comme légitime, ou même pour falsifier une signature électronique. Depuis qu’une équipe de chercheurs en a à nouveau montré les risques fin février (attaque SHAttered), SHA-1 fait justement l’objet d’attentions particulières.
GitHub explique comment il pourrait être attaqué
GitHub a d’ailleurs annoncé hier soir certaines mesures visant à court-circuiter les risques pour les utilisateurs. SHA-1 y est en effet utilisé pour identifier l’ensemble des données hébergées, stockées dans des objets. Il fallait donc empêcher que deux objets puissent obtenir le même hash. Un cas de figure accidentel que l’équipe juge extrêmement improbable. On parle donc bien ici d’une attaque éventuelle.
L’éditeur en explique d’ailleurs les mécanismes. Un pirate commence par générer une paire d’objets identifiés tous deux par le même hash. Il doit convaincre ensuite le développeur d’accepter le fichier innocent et attend qu’il le pousse dans son projet via un commit. Le pirate récupère ensuite le dépôt et le propose au téléchargement en ayant remplacé le fichier innocent par sa version malveillante. La signature SHA-1 générée n’aura pas changé.
Détection d'une attaque qui laisse des traces
Pour GitHub, la force brute reste considérée comme bien trop onéreuse pour SHA-1. Par contre, le modèle d’attaque utilisé par les chercheurs suit une ligne définie et « laisse des traces dans les octets », que l’on peut donc détecter si on en connait la signification. Le service s’occupe de cette étape dans tout calcul SHA-1 opéré. Le code de détection utilisé est open source et a notamment été développé par Marc Stevens, l’un des chercheurs à la base de l’attaque SHAttered.
GitHub indique qu’actuellement, aucune attaque de ce type n’a été détectée. L’éditeur rappelle à ce sujet que même si la théorie est tout à fait valide et qu’il est possible de réaliser de telles opérations, elles sont particulièrement coûteuses en l’état : « des centaines de milliers de dollars de calculs ».
Première étape avant l'intégration dans Git
Par ailleurs, la détection mise en place n’est qu’une première étape. Un travail est en cours avec Git pour l’intégrer directement au cœur du système. Les prochaines versions de Git seront donc à même de détecter les collisions et de rejeter toute opération impliquant des paires de fichiers « collisionnés », et ce pour l’ensemble des opérations, que l’on parle d’application de patchs, génération d’objets ou récupération de données depuis d’autres sites.
Surtout, Git réfléchit actuellement à une transition pour sortir de SHA-1 et basculer sur un algorithme plus sécurisé, par exemple SHA-256. Rien n’a encore été décidé à ce stade, mais GitHub précise qu’il suivra le mouvement quand le projet « aura mûri ».
