Résumé de la sécurité de janvier 2020

Bonne année SSL.com ! Bienvenue dans cette édition du Security Roundup de SSL.com, qui présente une sélection des développements de janvier en matière de SSL/TLS, les certificats numériques et la sécurité du réseau. Dans cette édition, nous couvrirons :

SHA-1 : collision avec préfixe choisi

Ce n'est pas une nouvelle que l'algorithme de hachage cryptographique SHA-1 est vulnérable. Il y a environ trois ans, les chercheurs de Google ont généré un collision avec préfixe fixe avec l'algorithme, l'envoyant dans une mort au ralenti pour une utilisation cryptographique sérieuse. Par conséquent, il a été à peu près abandonné au profit du SHA-2 moins vulnérable. Ce mois-ci, les choses ont empiré avec un préfixe-choisi collision, tel que rapporté par Ars Technica:

La nouvelle collision offre aux attaquants plus d'options et de flexibilité qu'avec la technique précédente. Cela permet de créer des clés de chiffrement PGP qui, lorsqu'elles sont signées numériquement à l'aide de l'algorithme SHA1, empruntent l'identité d'une cible choisie. Plus généralement, il produit le même hachage pour deux ou plusieurs entrées choisies par l'attaquant en ajoutant des données à chacune d'elles. L'attaque dévoilée mardi coûte également aussi peu que 45,000 2017 $ à mener. L'attaque divulguée en 110,000, en revanche, n'autorisait pas les contrefaçons sur des préfixes de documents prédéterminés spécifiques et a été évaluée à un coût de 560,000 XNUMX $ à XNUMX XNUMX $ sur la plate-forme de services Web d'Amazon, selon la rapidité avec laquelle les adversaires voulaient l'exécuter.

Cette attaque est importante. Bien que beaucoup aient abandonné l'algorithme SHA-1, il n'est pas encore complètement obsolète (par exemple, il reste utilisé pour certifier les clés PGP dans l'ancienne branche 1.4 de GnuPG). Cela fait de cette violation une affaire sérieuse, et les experts réitèrent leurs appels à l'abandon de l'utilisation de SHA-1 pour les certificats ou l'authentification.

À retenir de SSL.com: SHA1 n'est pas sécurisé depuis longtemps et des autorités de certification réputées (SSL.com incluses) n'ont pas émis de certificats SHA-1 depuis plusieurs années. Cette collision marque un nouveau creux inquiétant dans l'insécurité de SHA-1, et nous sommes d'accord avec les chercheurs lorsqu'ils déclarent qu'ils « conseillent vivement aux utilisateurs de supprimer la prise en charge de SHA1 pour éviter attaques de rétrogradation. »

Le fournisseur de matériel gère mal les clés privées

As découvert par Nick Starke et Tom Pohl et rapporté par Shaun Nichols dans Le registre, Netgear a récemment subi une faille de sécurité plutôt embarrassante. Des certificats valides et signés, ainsi que des clés privées, ont été intégrés au micrologiciel du routeur disponible en téléchargement public et livrés avec les appareils. Ce sont des informations qui pourraient être utilisées pour détourner les connexions HTTPS des utilisateurs à leurs routeurs, et semblent avoir été une tentative de faciliter les choses pour leurs clients, au détriment de la sécurité. Tel que rapporté par Shaun Nichols :

L'erreur est le résultat de l'approche de Netgear en matière de sécurité et de confort d'utilisation. Lors de la configuration de leur kit, les propriétaires d'équipements Netgear doivent visiter https://routerlogin.net ou https://routerlogin.com. Le routeur du réseau essaie de s'assurer que ces noms de domaine correspondent à l'adresse IP de l'appareil sur le réseau local… Pour établir une connexion HTTPS et éviter les plaintes des navigateurs concernant l'utilisation de HTTP non sécurisé et de certificats non fiables, le routeur doit produire un certificat HTTPS valide pour routerlogin .net ou routerlogin.com auquel les navigateurs font confiance. Pour prouver cryptographiquement que le certificat est légitime lorsqu'une connexion est établie, le routeur doit utiliser la clé privée du certificat. Cette clé est stockée non sécurisée dans le micrologiciel, permettant à quiconque de l'extraire et d'en abuser.

À ce stade, l'entreprise a quelques solutions à sa disposition qui sont, bien sûr, actuellement débattu en ligne.

À retenir de SSL.com: Les fournisseurs de matériel doivent stocker leurs clés privées ailleurs que dans le micrologiciel téléchargeable (et nous pouvons aider avec ça). En attendant, ces certificats devront être révoqués.

La NSA découvre une vulnérabilité cryptographique critique dans Windows 10

La National Security Agency a découvert ce qu'elle appelle une « vulnérabilité critique » dans Windows 10 qui affecte ses fonctionnalités cryptographiques. Plus précisément, la vulnérabilité affecte les connexions HTTPS, les fichiers et e-mails signés et certains codes signés. En conséquence, l'agence conseille aux utilisateurs d'atténuer cette vulnérabilité en installant tous les correctifs Patch Tuesday de janvier 2020 dès que possible. Vous pouvez en savoir plus sur la NSA sur leur site web.

La vulnérabilité, qui a été décrite comme « large », a déstabilisé les chercheurs. Comme Dan Goodin à Ars Technica Explique, la vulnérabilité exploite une faille qui brise la chaîne de confiance :

La faille concerne la manière dont les nouvelles versions de Windows vérifient la validité des certificats utilisant la cryptographie à courbe elliptique. Alors que les versions vulnérables de Windows vérifient trois paramètres ECC, elles ne parviennent pas à en vérifier un quatrième, crucial, appelé générateur de points de base et souvent représenté dans les algorithmes par « G ». Cet échec est le résultat de la mise en œuvre d'ECC par Microsoft plutôt que d'une faille ou d'une faiblesse des algorithmes ECC eux-mêmes.

Les attaquants peuvent exploiter la faille en extrayant la clé publique d'un certificat racine fourni par défaut dans Windows. Ces certificats sont décrits comme racine car ils appartiennent à de grandes autorités de certification qui émettent leurs propres TLS certificats ou valider les autorités de certification intermédiaires qui vendent des certificats au nom de l'autorité de certification racine. Tout certificat racine fonctionnera, tant qu'il est signé avec un algorithme ECC… L'attaquant examine l'algorithme ECC spécifique utilisé pour générer la clé publique du certificat racine et procède à la création d'une clé privée qui copie tous les paramètres de certificat pour cet algorithme, à l'exception pour le générateur de points. Étant donné que les versions Windows vulnérables ne parviennent pas à vérifier ce paramètre, elles acceptent la clé privée comme valide. Avec cela, l'attaquant a usurpé un certificat racine de confiance Windows qui peut être utilisé pour créer tout certificat individuel utilisé pour l'authentification de sites Web, de logiciels et d'autres propriétés sensibles.

En bref, ce bogue peut être exploité par des personnes malveillantes pour donner l'impression que les exécutables malveillants proviennent de sources fiables et vérifiées et de faux certificats numériques. Préoccupé? voici un lien pour tester si vous êtes vulnérable à l'attaque.

À retenir de SSL.com: C'est une excellente occasion de suivre les conseils de la NSA et d'installer Microsoft pièce cela résoudra le problème. Comme ils le notent, « l'adoption rapide du correctif est la seule atténuation connue à l'heure actuelle et devrait être l'objectif principal de tous les propriétaires de réseau ». Nous sommes d'accord avec Catalin Cimpanu de ZD Net que celui-ci est "aussi mauvais que possible". Voici un lien vers le correctif.
Merci d'avoir choisi SSL.com! Si vous avez des questions, veuillez nous contacter par e-mail à Support@SSL.com, appel 1-877-SSL-SECUREou cliquez simplement sur le lien de discussion en bas à droite de cette page.


Abonnez-vous à la newsletter SSL.com

Ne manquez pas les nouveaux articles et mises à jour de SSL.com

Nous aimerions recevoir vos commentaires

Répondez à notre enquête et faites-nous part de votre avis sur votre récent achat.