Sécurité sérieuse : le bogue de connexion Samba causé par une crypto obsolète

Samba, en termes simples, est une réimplémentation open source super utile et méga populaire des protocoles de réseau utilisés dans Microsoft Windows, et son importance historique dans l'interconnexion de réseaux (connexion de deux types de réseaux différents) ne peut être sous-estimée.

À la fin des années 1990, la mise en réseau de Microsoft a perdu sa nature opaque et propriétaire et est devenue une norme ouverte connue sous le nom de CIFS, abréviation de système de fichiers Internet commun.

Mais il n'y avait rien de "commun" ou "d'ouvert" à ce sujet au début des années 1990, lorsque l'universitaire australien Andrew Tridgell a entrepris de corriger cela en mettant en place un système compatible qui lui permettrait de connecter son ordinateur Unix à un réseau Windows, et vice versa.

À l'époque, le protocole était officiellement appelé SMB, abréviation de bloc de messages du serveur (un nom que vous entendez encore beaucoup plus souvent que CIFS), donc Tridge, comme Andrew Tridgell est connu, a naturellement appelé son projet "SMBserver", parce que c'était ce qu'il était.

Mais un produit commercial de ce nom existait déjà, donc un nouveau surnom était nécessaire.

C'est alors que le projet est devenu connu sous le nom de Samba, un nom délicieusement mémorable qui résulte d'une recherche dans le dictionnaire de mots de la forme S?M?B?.

Ainsi, samba est toujours le premier mot sorti de la porte par ordre alphabétique dans le dict fichier couramment trouvé sur les ordinateurs Unix, suivi du mot plutôt mal adapté scramble et le tout à fait inapproprié scumbag:

Certains bugs que vous faites, mais certains bugs que vous obtenez

Au fil des ans, le projet Samba a non seulement introduit et corrigé ses propres bogues uniques, comme le fait généralement tout projet logiciel complexe, mais a également hérité de bogues et de lacunes dans le protocole sous-jacent, étant donné que son objectif a toujours été de fonctionner de manière transparente avec les réseaux Windows.

(Malheureusement, soi-disant compatibilité des bogues est souvent une partie inévitable de la construction d'un nouveau système qui fonctionne avec un système existant.)

Fin 2022, l'une de ces «vulnérabilités héritées» a été découverte et signalée à Microsoft, compte tenu de l'identifiant CVE-2022-38023, et corrigé dans la mise à jour Patch Tuesday de novembre 2022.

Ce bogue aurait pu permettre à un attaquant de modifier le contenu de certains paquets de données réseau sans être détecté, malgré l'utilisation de MAC cryptographiques (codes d'authentification des messages) destiné à empêcher l'usurpation d'identité et la falsification.

Notamment, en manipulant les données au moment de la connexion, des cybercriminels rusés pourraient réaliser une attaque par élévation de privilèges (EoP).

Ils pourraient, en théorie du moins, tromper un serveur en lui faisant croire qu'ils ont passé la question « avez-vous des informations d'identification d'administrateur ? » test, même s'ils n'avaient pas ces informations d'identification et que leurs fausses données auraient dû échouer à leur vérification cryptographique.

Agilité cryptographique

Nous avons décidé d'écrire sur ce bogue plutôt ésotérique non pas parce que nous pensons que vous êtes terriblement susceptible d'être exploité par celui-ci (bien qu'en matière de cybersécurité, nous adoptons l'attitude ne jamais dire jamais), mais parce que c'est un encore un autre rappel de pourquoi l'agilité cryptographique est importante.

---

---

Collectivement, nous avons besoin à la fois des compétences et de la volonté d'abandonner définitivement les anciens algorithmes dès qu'ils s'avèrent défectueux, et de ne pas les laisser traîner indéfiniment jusqu'à ce qu'ils deviennent le problème de quelqu'un d'autre. (Ce "quelqu'un d'autre" pourrait bien s'avérer être nous, dans dix ans.)

Étonnamment, la vulnérabilité CVE-2022-38023 existait en premier lieu parce que Windows et Samba prenaient toujours en charge un style de protection de l'intégrité basé sur l'algorithme de hachage MD5, obsolète depuis longtemps.

En termes simples, l'authentification réseau à l'aide de la version Microsoft du protocole Kerberos permettait toujours de protéger l'intégrité des données (ou somme de contrôle, pour utiliser le terme de jargon courant mais pas strictement précis) en utilisant une cryptographie défectueuse.

Vous ne devriez plus utiliser MD5 car il est considéré comme défectueux : un attaquant déterminé peut facilement trouver deux entrées différentes qui aboutissent au même hachage MD5.

Comme vous le savez probablement déjà, cependant, l'une des exigences de tout hachage qui revendique la qualité cryptographique est que cela ne devrait tout simplement pas être possible.

Dans le jargon, deux entrées qui ont le même hachage sont appelées un collision, et il n'est pas censé y avoir d'astuces ou de raccourcis programmatiques pour vous aider à en trouver un rapidement.

Il ne devrait y avoir aucun moyen de trouver une collision qui soit meilleure que la simple bonne chance - en essayant encore et encore avec des fichiers d'entrée en constante évolution jusqu'à ce que vous touchiez le jackpot.

Le vrai coût d'une collision

En supposant un algorithme fiable, sans faiblesses exploitables, vous vous attendez à ce qu'un hachage avec X bits de sortie nécessite environ 2^X-1 essaie de trouver une deuxième entrée qui est entrée en collision avec le hachage d'un fichier existant.

Même si tout ce que vous vouliez faire était de trouver deux entrées (deux entrées arbitraires, indépendamment du contenu, de la taille ou de la structure) qui avaient le même hachage, vous vous attendriez à avoir besoin d'un peu plus de 2^{X / 2} essaie avant de tomber sur une collision.

Tout algorithme de hachage qui peut être "craqué" de manière fiable plus rapidement que cela n'est pas cryptographiquement sûr, car vous avez montré que son processus interne pour déchiqueter-hacher-et-agiter les données qui y sont introduites ne produit pas un résultat vraiment pseudo-aléatoire du tout.

Notez que toute procédure de craquage meilleure que le hasard, même si elle n'accélère que légèrement le processus de génération de collisions et ne serait donc pas actuellement un risque exploitable dans la vie réelle, détruit la confiance dans l'algorithme cryptographique sous-jacent en sapant ses revendications d'exactitude cryptographique .

S'il y a 2^X différentes sorties de hachage possibles, vous espérez atteindre une chance de 50:50 de trouver une entrée avec un hachage spécifique et prédéterminé après environ la moitié du nombre d'essais, et 2^X/ 2 = 2^X-1. Il est plus facile de trouver deux fichiers qui entrent en collision, car chaque fois que vous essayez une nouvelle entrée, vous gagnez si votre nouveau hachage entre en collision avec tous des entrées précédentes que vous avez déjà essayées, car n'importe quelle paire d'entrées est autorisée. Pour une collision du type "deux fichiers quelconques dans ce seau géant feront l'affaire", vous atteignez les chances de succès de 50:50 à un peu plus que la racine carrée du nombre de hachages possibles, et √2^X = 2^{X / 2}. Ainsi, pour un hachage 128 bits tel que MD5, vous vous attendez, en moyenne, à hacher environ 2¹²⁷ blocs pour correspondre à une valeur de sortie spécifique, et 2⁶⁴ blocs pour trouver n'importe quelle paire d'entrées en collision.

Collisions MD5 rapides simplifiées

En fait, vous ne pouvez pas facilement générer deux entrées pseudo-aléatoires complètement différentes, sans rapport, qui ont le même hachage MD5.

Et vous ne pouvez pas facilement revenir en arrière à partir d'un hachage MD5 pour découvrir quoi que ce soit sur l'entrée spécifique qui l'a produit, ce qui est une autre promesse cryptographique qu'un hachage fiable doit tenir.

Mais si vous commencez avec deux entrées identiques et que vous insérez soigneusement une paire délibérément calculée de blocs de « création de collisions » au même point dans chaque flux d'entrée, vous pouvez créer de manière fiable des collisions MD5 en quelques secondes, même sur un ordinateur portable modeste.

Par exemple, voici un programme Lua que nous avons écrit et qui peut être découpé en trois sections distinctes, chacune de 128 octets de long.

Il y a un préfixe de code qui se termine par une ligne de texte qui commence un commentaire Lua (la chaîne commençant --[== à la ligne 8), alors il y a 128 octets de texte de commentaire qui peuvent être remplacés par tout ce que nous voulons, car il est ignoré lorsque le fichier s'exécute (lignes 9 à 11), et il y a un suffixe de code de 128 octets qui ferme le commentaire (le chaîne commençant --]== à la ligne 12) et termine le programme.

Même si vous n'êtes pas programmeur, vous pouvez probablement voir que le code actif lit dans le contenu [ligne 14] du fichier de code source lui-même (en Lua, la valeur arg[0] à la ligne 5 est le nom du fichier de script que vous exécutez actuellement), puis l'imprime sous forme de vidage hexadécimal [ligne 15] , suivi de son hachage MD5 [ligne 17] :

L'exécution du fichier est essentiellement auto-descriptive et rend évidents les trois blocs de 128 octets :

Utilisation d'un MD5 outil de recherche appelé md5_fastcoll, créé à l'origine par le mathématicien Marc Steven dans le cadre de sa maîtrise en cryptographie en 2007, nous avons rapidement produit deux morceaux de 128 octets «MD5 collision-building» que nous avons utilisés pour remplacer le texte de commentaire affiché dans le fichier ci-dessus.

Cela a créé deux fichiers qui fonctionnent toujours comme avant, car les modifications sont limitées au commentaire, ce qui n'affecte pas le code exécutable dans l'un ou l'autre fichier.

Mais ils sont visiblement différents sur plusieurs octets, et devraient donc avoir des valeurs de hachage complètement différentes, comme le code suivant diff (jargon pour vidage des différences détectées) révèle.

Nous avons converti les blocs de 128 octets créant des collisions, qui n'ont pas de sens en tant que texte imprimable, en hexadécimal pour plus de clarté :

Cependant, les exécuter tous les deux montre clairement qu'ils représentent une collision de hachage, car ils s'avèrent avoir la même sortie MD5 :

Complexité des collisions explorée

MD5 est un hachage de 128 bits, comme le montrent clairement les chaînes de sortie ci-dessus.

Donc, comme mentionné précédemment, nous nous attendons à avoir besoin d'environ 2^128/2Ou 2⁶⁴ essaie en moyenne afin de produire une collision MD5 de toute sorte.

Cela signifie traiter un minimum d'environ 18 quintillions de blocs de hachage MD5, car 2⁶⁴ = 18,446,744,073,709,551,616.

À un taux de hachage MD5 estimé à environ 50,000,000 10,000 10,000 blocs/seconde sur notre ordinateur portable, cela signifie que nous devrions attendre plus de 100,000 XNUMX ans, et bien que des attaquants bien financés puissent facilement aller XNUMX XNUMX à XNUMX XNUMX fois plus vite que cela, même eux attendre des semaines ou des mois juste pour qu'une seule collision aléatoire (et pas nécessairement utile) se présente.

Pourtant, la paire de fichiers Lua à deux faces ci-dessus, qui ont exactement le même hachage MD5 bien qu'ils ne soient clairement pas identiques, ne nous a pris que quelques secondes à préparer.

En effet, générer 10 collisions différentes pour 10 fichiers, en utilisant 10 préfixes de départ différents que nous avons choisis nous-mêmes, nous a pris : 14.9sec, 4.7sec, 2.6sec, 2.1sec, 10.5sec, 2.4sec, 2.0sec, 0.14sec, 8.4sec, et 0.43 s.

De toute évidence, la promesse cryptographique de MD5 de fournir ce qu'on appelle résistance aux collisions est fondamentalement brisé…

… apparemment par un facteur d'au moins 25 milliards, basé sur la division du temps moyen que nous nous attendons à attendre pour trouver une collision (des milliers d'années, comme estimé ci-dessus) par le pire temps que nous avons réellement mesuré (14.9 secondes) tout en produisant dix collisions différentes rien que pour cet article.

La faille d'authentification expliquée

Mais qu'en est-il de l'utilisation non sécurisée de MD5 dans CVE-2022-38023 ?

Dans le pseudo-code de style Lua, le code d'authentification de message défectueux utilisé lors des connexions était calculé comme ça:

Pour expliquer : le code d'authentification utilisé est calculé par le hmac.md5() appel de fonction à la ligne 15, en utilisant ce qu'on appelle un hachage à clé, dans ce cas HMAC-MD5.

Le nom HMAC est l'abréviation de construction cryptographique pour générer des codes d'authentification de message basés sur le hachage, et le suffixe -MD5 indique l'algorithme de hachage qu'il utilise en interne.

HMAC utilise une clé secrète, combinée à deux invocations du hachage sous-jacent, au lieu d'une seule, pour produire son code d'authentification de message :

La clé a certains de ses bits inversés en premier et est ajoutée aux données fournies avant le début du premier hachage.

Cela réduit considérablement le contrôle que les pirates cryptographiques ont, lorsqu'ils tentent de provoquer une collision ou un autre comportement non aléatoire dans le processus de hachage, sur l'état interne de la fonction de hachage lorsque les premiers octets des données d'entrée sont atteints.

Notamment, la clé secrète empêche les attaquants de commencer par un préfixe de message de leur choix, comme nous l'avons fait dans le twohash.lua exemple ci-dessus.

Ensuite, une fois le premier hachage calculé, la clé a un ensemble différent de bits inversés, est ajoutée à cette première valeur de hachage et ces nouvelles données d'entrée sont hachées une seconde fois.

Cela empêche également les attaquants de manipuler la dernière partie du calcul HMAC, les empêchant notamment d'ajouter un suffixe de leur choix à la dernière étape du processus de hachage.

En effet, même si vous ne devriez pas du tout utiliser MD5, nous n'avons connaissance d'aucune attaque actuelle susceptible de casser l'algorithme lorsqu'il est utilisé sous forme HMAC-MD5 avec une clé choisie au hasard.

Le trou est au milieu

Le trou exploitable dans le pseudo-code ci-dessus n'est donc dans aucune des lignes où le hmac.md5() fonction est utilisée.

Au lieu de cela, le cœur du bogue est la ligne 11, où les données que vous souhaitez authentifier sont compressées dans une chaîne de longueur fixe…

.. en le poussant à travers une seule invocation de l'ancien MD5.

En d'autres termes, quelle que soit la fonction HMAC que vous choisissez à la ligne 15, et quelle que soit la force et la résistance aux collisions de cette étape finale, vous avez néanmoins une chance de provoquer une collision de hachage à la ligne 11.

Autrement dit, si vous connaissez les données qui sont censées entrer dans le chksum() fonction à authentifier, et vous pouvez utiliser un générateur de collision pour trouver un autre bloc de données avec le même hachage MD5…

… la ligne 11 signifie que vous finirez par avec exactement la même valeur d'entrée (la variable signdat dans le pseudocode) poussé dans l'étape finale HMAC aussi sécurisée que vous le souhaitez.

Par conséquent, même si vous utilisez une fonction de résumé de message à clé forte à la fin, vous pouvez néanmoins authentifier un hachage MD5 dérivé de données d'imposteur.

Moins aurait été plus

Comme Samba bulletin de sécurité décrit de manière compacte le problème :

La faiblesse […] est que la somme de contrôle sécurisée est calculée comme HMAC-MD5(MD5(DATA),KEY), ce qui signifie qu'un attaquant actif connaissant les données en clair pourrait créer un autre DATA, avec la même somme de contrôle MD5, et remplacez-la dans le flux de données sans être détectée.

Ironiquement, en laissant de côté le MD5(DATA) une partie de la formule HMAC ci-dessus, qui semble à première vue augmenter le processus global de "mélange", améliorerait la résistance aux collisions.

Sans cette compression MD5 au milieu, vous auriez besoin de trouver une collision dans HMAC-MD5 lui-même, ce qui n'est probablement pas possible en 2023, même avec un financement gouvernemental presque illimité, du moins pas pendant la durée de vie de la session réseau que vous essayiez à faire des compromis.

Qu'est-ce qui a pris si longtemps?

À présent, vous vous demandez probablement, comme nous, pourquoi ce bogue n'a pas été découvert, ou du moins n'a pas été corrigé, pendant si longtemps.

Après tout, RFC 6151, qui remonte à 2011, et porte le titre significatif Mise à jour des considérations de sécurité pour les algorithmes MD5 Message-Digest et HMAC-MD5, conseille ce qui suit (nous soulignons, plus d'une décennie plus tard):

Les attaques sur HMAC-MD5 ne semblent pas indiquer une vulnérabilité pratique lorsqu'il est utilisé comme code d'authentification de message. Par conséquent, il n'est peut-être pas urgent de supprimer HMAC-MD5 des protocoles existants. Cependant, depuis MD5 ne doit pas être utilisé pour les signatures numériques, pour une nouvelle conception de protocole, une suite de chiffrement avec HMAC-MD5 ne doit pas être incluse.

Il semble cependant que, comme la grande majorité des plates-formes de serveurs SMB récentes ont désactivé l'authentification HMAC-MD5 lorsque les utilisateurs tentent de se connecter, les clients SMB prenant toujours en charge ce mode non sécurisé ne l'ont généralement jamais utilisé (et auraient de toute façon échoué s'ils avaient a tenté).

Les clients semblaient implicitement être « protégés » et le code non sécurisé semblait être aussi bon qu'inoffensif, car l'authentification faible n'était ni nécessaire ni utilisée.

Ainsi, le problème potentiel n'a tout simplement jamais reçu l'attention qu'il méritait.

Malheureusement, ce type de "sécurité par hypothèse" échoue complètement si vous rencontrez (ou êtes attiré vers) un serveur qui accepte cette insécurité. chksum() algorithme lors de la connexion.

Ce type de "problème de rétrogradation" n'est pas nouveau : en 2015, des chercheurs ont imaginé le fameux FREAK ainsi que le Embouteillage attaques, qui ont délibérément amené les clients du réseau à utiliser des chiffrements dits EXPORT, qui étaient les modes de cryptage délibérément affaiblis sur lesquels le gouvernement américain a bizarrement insisté par la loi au siècle dernier.

Comme nous l'écrivions à l'époque :

Les longueurs de clé EXPORT ont été choisies pour être à peu près craquables dans les années 1990, mais jamais étendues pour suivre les progrès de la vitesse du processeur.

C'est parce que les chiffrements d'exportation ont été abandonnés par les États-Unis vers 2000.

C'était une idée stupide dès le départ : les entreprises américaines se contentaient d'importer des logiciels cryptographiques qui n'avaient aucune restriction à l'exportation et nuisaient à leur propre industrie du logiciel.

Bien sûr, une fois que les législateurs ont cédé, les suites de chiffrement EXPORT sont devenues superflues, alors tout le monde a cessé de les utiliser.

Malheureusement, de nombreuses boîtes à outils cryptographiques, y compris OpenSSL et SChannel de Microsoft, ont conservé le code pour les prendre en charge, de sorte que vous (ou, plus inquiétant, des escrocs bien informés) n'avez pas été empêché de les utiliser.

Cette fois, le principal coupable parmi les serveurs qui utilisent encore ce processus MD5-plus-HMAC-MD5 cassé semble être la gamme NetApp, dans laquelle certains produits continuent apparemment (ou l'ont fait jusqu'à récemment) à s'appuyer sur cet algorithme risqué.

Par conséquent, vous pouvez encore parfois passer par un processus de connexion réseau vulnérable et être exposé au risque de CVE-2022-38023, peut-être même sans vous en rendre compte.

Que faire?

Ce bug a finalement été traité, au moins par défaut, dans la dernière version de Samba.

En termes simples, Version 4.17.5 de Samba force maintenant les deux options reject md5 clients = yes ainsi que le reject md5 servers = yes.

Cela signifie que tous les composants cryptographiques des différents protocoles de réseau SMB qui impliquent l'algorithme MD5 (même s'ils sont théoriquement sûrs, comme HMAC-MD5), sont interdit par défaut.

Si vous en avez vraiment besoin, vous pouvez les réactiver pour accéder à des serveurs spécifiques de votre réseau.

Assurez-vous simplement que si vous créez des exceptions que les normes Internet déconseillent déjà officiellement depuis plus d'une décennie…

… que vous vous fixiez une date à laquelle vous retirerez enfin ces options non par défaut pour toujours !

Les attaques cryptographiques ne font que devenir plus intelligentes et plus rapides, alors ne vous fiez jamais à des protocoles et algorithmes obsolètes simplement « qui ne sont plus utilisés ».

Supprimez-les complètement de votre code, car s'ils n'y sont pas du tout, vous NE POUVEZ PAS les utiliser, et vous ne pouvez pas être amené à les utiliser par quelqu'un qui essaie de vous attirer dans l'insécurité.

---

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• Platoblockchain. Intelligence métaverse Web3. Connaissance Amplifiée. Accéder ici.
• La source: https://nakedsecurity.sophos.com/2023/01/30/serious-security-the-samba-logon-bug-caused-by-outdated-crypto/