Articles

[Bulletin d’Alerte Cyberprotect] Vulnérabilité critique sur OpenSSL

De nouvelles vulnérabilités concernant OpenSSL ont été rendues publiques (CVE-2016-0701 et CVE-2015-3197).

La première vulnérabilité (CVE-2016-0701) permet à un attaquant de pouvoir récupérer des informations essentielles au décryptage de la clé de chiffrement en utilisant des nombres premiers dit « non sûr » dans l’algorithme de Deffie-Hellman.

Les versions affectées par cette vulnérabilité sont toutes les versions 1.0.2. Les versions en 1.0.1 ne sont pas affectées par cette vulnérabilité.

Un correctif a été apporté dans la version 1.0.2f.

La deuxième vulnérabilité (CVE-2015-3197) permet à une personne malveillante de négocier avec le chiffrement SSLv2 et de compléter la jonction SSLv2 même si la méthode de chiffrement SSLv2 a été désactivée sur le serveur.
Le protocole SSLv2 ne doit pas être désactivé via le paramètre SSL_OP_NO_SSLv2 pour que la vulnérabilité soit exploitée.
L’attaquant peut alors intercepter les communications.

Les versions affectées par cette vulnérabilité sont toutes les versions 1.0.1 et 1.0.2.
Solution :
•    mettre à jour vers 1.0.1r pour les utilisateurs de la version 1.0.1
•    mettre à jour vers 1.0.2f pour les utilisateurs de la version 1.0.2

Le CERT Cyberprotect recommande à tous les utilisateurs de OpenSSL de mettre à jour leur version de OpenSSL en version 1.0.1r ou 1.0.2f.

Références :
https://www.openssl.org/news/secadv/20160128.txt
https://www.kb.cert.org/vuls/id/257823

Répertoire de téléchargement des dernières versions de OpenSSL :
https://www.openssl.org/source/

Vulnérabilité « Poodle » sur protocole SSLv3, attention à vos connexions HTTPS !

Google a annoncé avoir découvert une vulnérabilité (CVE 2014-3566) dans le protocole SSLv3. Cette vulnérabilité peut permettre à un attaquant de décrypter les données contenues dans une connexion chiffrée.

SSL (Secure Sockets Layers) est un protocole de sécurisation utilisé dans les échanges sur Internet.

Par exemple, lorsqu’on se connecte à un service bancaire en ligne (https://mabanque.fr) et que l’on saisit son couple identifiant /mot de passe, ce dernier est chiffré et transmis au site Internet de la banque. En cas d’interception, votre couple identifiant / mot de passe n’apparaitra pas en clair mais dans le cas de cette vulnérabilité, on pourra récupérer ces informations.

La version SSLv3, aujourd’hui en cause, est obsolète mais encore utilisée par de nombreux services Internet. Il est toutefois maintenu en production afin d’assurer une certaine compatibilité avec les anciens navigateurs qui ne prennent pas en charge les protocoles actuelles (TLSv1.1 et TLSv1.2).

L’exploitation de la vulnérabilité est difficile à mettre en place mais reste néanmoins possible.

Il faut réunir trois éléments pour exploiter la vulnérabilité :

1) Le serveur contacté doit supporter le protocole SSLv3
2) Le client (navigateur de l’utilisateur) doit supporter le protocole SSLv3
3) L’attaquant doit pouvoir intercepter le trafic entre l’utilisateur et le serveur

Par défaut, le navigateur utilisera la version du protocole la plus récente, mais s’il n’est pas à jour, il peut utiliser le protocole SSLv3 si le serveur qu’il contacte l’utilise.

Que dois-je faire ?

Coté administrateur : Désactiver l’utilisation du protocole SSLv3 sur vos serveurs (cela peut avoir un impact si des utilisateurs utilisent un navigateur obsolète ou des versions anciennes de Java)

Coté utilisateur : S’assurer d’utiliser un navigateur à jour et désactiver l’utilisation du protocole SSLv3 si cela est possible. Vous pouvez vérifier la vulnérabilité de votre navigateur en faisant un test sur ce site https://www.poodletest.com/

 

Source [ici]

OpenSSL, ce que l’on peut dire sur la faille Heartbleed

Ces dernières 48h ont mis en émoi la communauté de la cybersécurité suite à la découverte d’une faille dans OpenSSL.

Nous souhaitons faire un point, à froid, sur ce qu’il en est de cette faille baptisée “Heartbleed”.

OpenSSL est une bibliothèque logicielle qui permet d’implémenter des fonctions cryptographiques. C’est ce qui se retrouve dans le processus de chiffrement des communications SSL/TLS (avec le fameux HTTPS).

Par exemple, lorsqu’on se connecte à un service bancaire en ligne (https://mabanque.fr) et que l’on saisit ses identifiant et mot de passe, ces derniers sont chiffrés et transmis au site Internet de la banque. En cas d’interception, votre mot de passe n’apparaitra pas en clair.

La faille découverte permet d’aller lire dans la mémoire du serveur utilisant OpenSSL, les informations qu’il est en train de traiter. Ces informations apparaissent en clair !

OpenSSL est utilisé sur une grande partie des services Web.

Ainsi, bien que votre mot de passe ait été chiffré lorsque vous l’avez saisi, il peut potentiellement être lu par un tiers.

Cela signifie que si vous avez saisi votre mot de passe sur un site utilisant le protocole SSL/TLS, il a potentiellement pu être dérobé.

Par mesure de précaution, nous vous recommandons donc de changer tous vos mots de passe.

Aussi, si vous administrez des serveurs utilisant OpenSSL ou si vos équipements l’utilisent, vous êtes concerné par la mise à jour vers la dernière version qui corrige cette faille (version corrigée 1.0.1g disponible sur https://www.openssl.org/).

Les clés de chiffrement ont pu être dérobées, il est donc recommandé de regénérer les clés et renouveler les certificats.

Seules les versions OpenSSL 1.0.1 et la version OpenSSL 1.0.2-beta1 sont vulnérables.

La version OpenSSL 1.0.0l n’est pas concernée.

Le support Cyberprotect se tient à votre disposition pour tout complément d’information.

 

Plus d’information sur https://openssl.org/

Les services Web : une cible privilégiée

Depuis que Akamai procède à l’analyse des attaques, c’est la première fois en 5 ans qu’il est constaté que le port le plus scanné n’est plus le port 445 (Service de partage de fichiers Windows). Le port 445 rétrograde même à la 3ème place.

Les attaquants se sont réorientés vers les ports 80 (HTTP) et 443 (HTTPS), c’est-à-dire de manière globale : les services Web. Il est d’ailleurs étonnant que cette tendance soit nouvelle.

En effet, la grande majorité des interactions qui se font sur Internet se font à travers les services Web, il est donc logique de privilégier cette voie. Ce sont également les ports les plus ouverts sur l’extérieur.

Compromission de sites Internet, intrusion dans les systèmes d’information, connexion à des services de messagerie… La sécurisation est généralement mise en second plan, on privilégie surtout le coté pratique pour les utilisateurs. Les services Web sont donc la porte d’entrée entrouverte qui permet le plus facilement d’entrer dans les systèmes d’information.

Autre changement notable dans le rapport du second trimestre 2013, l’Indonésie remplace la Chine à la tête des pays d’où les attaques sont originaires.

[Source]

DoS avec une requête HTTP de 100Ko

Il y a quelques mois, le groupe THC (The Hacker’s Choice) mettait à disposition un outil exploitant une faille dans le protocole SSL et qui permettait de procéder à un déni de service sur un serveur avec une connexion internet et un ordinateur classique.

Aujourd’hui une nouvelle attaque de type DoS est possible avec une connexion ADSL  modeste et une seule machine en attaque. Le problème qui existe dans la plupart des serveurs web est en train d’être patché par différents éditeurs.

Les chercheurs qui ont présenté leurs conclusions lors du CCC (Chaos Communication Congress) à Berlin, mettent en cause la manipulation des tables de hachage. Ces tables sont utilisées pour stocker et récupérer rapidement des données.

Il arrive qu’il y ait des collisions de hachage lorsqu’il y a beaucoup de données, ce qui génère le même hash. Chaque collision génère un traitement important de la part du serveur. L’attaque consiste donc à calculer les données qui vont déclencher un grand nombre de collisions puis envoyer ces données dans une simple requête HTTP.

Microsoft a confirmé qu’une seule requête HTTP de 100Ko envoyé à un serveur ASP peut faire utiliser le CPU à 100% pendant 90 secondes.

Gemnet : une affaire Diginotar bis ?

L’autorité de certification hollandaise Gemnet, filiale de KPN, a été victime d’une intrusion dans son réseau.

Le hacker a pénétré dans le système d’information de l’entreprise en exploitant une faille présente dans phpMyAdmin. Il aurait pu avoir accès à des documents confidentiels concernant les réseaux de communication et les accords avec les autorités publiques.

Pour l’instant, il n’est pas question de vol de certificat SSL. C’est en tout cas le discours officiel de KPN qui craint, à l’instar de son ex-compatriote Diginotar, une perte de confiance de la part des partenaires.

Rappelons que Diginotar a dû mettre la clé sous la porte en Septembre dernier suite à la compromission de ses certificats.

Google souhaite améliorer le processus des certificats SSL

Les chercheurs en Sécurité de Google ont proposé une révision pour améliorer l’efficacité du protocole de chiffrement SSL utilisé par des millions de sites Web pour protéger les communications.

Les modifications visent à fixer un défaut structurel qui permet, à l’un des 600 organismes autorisés à délivrer des certificats numériques, de générer un certificat d’un site sans l’autorisation du détenteur du nom de domaine sous-jacent. Les conséquences désastreuses de certificats émis frauduleusement ont été soulignées fin Août lorsque des pirates ont percé les défenses de la société Diginotar et émis de faux certificats.

Toutes les autorités de confiance seraient contraintes de publier les détails de chaque certificat de chiffrement dans un journal rendu public et qui sera signé électroniquement afin de garantir son intégrité. Ce procédé rendra impossible (ou plutôt beaucoup plus difficile) la possibilité de délivrer des attestations sans autorisation du titulaire du nom de domaine.

Google en mode SSL

Google annonce le chiffrement, par défaut, des recherches effectuées par ses utilisateurs. Dans un premier temps, ceci est réservé aux possesseurs d’un comte Google. La généralisation interviendra plus tard.

L’utilisation du protocole SSL est particulièrement appréciée à l’heure où les connexions sur des réseaux publics sont monnaies courantes avec la multiplication des terminaux mobiles. Les termes de recherche et les pages de résultats sont donc protégés.

Tout le monde peut déjà faire une recherche chiffrée via l’adresse suivante https://encrypted.google.com/

Retour sur Septembre : Diginotar ou comment une cyber-attaque peut mettre en faillite une entreprise

Le tiers de confiance Néerlandais Diginotar, qui délivre des certificats SSL, a été la cible du hacker qui attaqua Comodo en Mars dernier. Au-delà du fait qu’un spécialiste de la sécurité se fasse pirater, c’est l’ensemble de la chaîne des tiers de confiance qui est remis en doute. Plusieurs dysfonctionnements dans la sécurité mise en place ont été pointé du doigt, peut-on faire confiance aux autres tiers ? C’est ce que Mozilla semble demander en souhaitant que les entités de certification soient auditées. C’est ainsi qu’on a appris que les mots de passe administrateur étaient trop faibles, des antivirus étaient absents des serveurs internes et que les logiciels n’étaient pas forcément à jour.

Dès l’annonce de l’attaque, les principaux navigateurs ont réagis en bloquant les certificats signés Diginotar. C’est ainsi que les internautes se voient refuser l’accès à des sites publics. Le gouvernement hollandais conseille même à ses administrés de délaisser les communications par internet pour revenir à un usage papier. On découvre ici une attaque ayant une cible mais impactant l’ensemble d’un pays. C’est ainsi que le gouvernement néerlandais a, par exemple, décidé de prolonger la date de déclaration d’impôt en ligne.

Devant le manque de perspective d’avenir, Diginotar  a été obligé de mettre la clé sous la porte. La mise en faillite par la société mère, Vasco, a été évoquée dès les premières semaines. Les conséquences financières sont catastrophiques pour Vasco qui a acquis Diginotar neuf mois auparavant pour 13.1M $, le prix des actions a chuté de plus de 30% en quelques semaines. L’estimation des pertes par Vasco sont entre 3.3M et 4.8M $. Ces dernières ne prennent pas en compte des réclamations potentielles que pourraient faire les organisations ayant subies des dommages collatéraux.

L’Institut Ponemon, dans son rapport annuel, annonce que le coût moyen dû à des pertes de données par un organisme est de 7.2M $. La cause principale étant la dégradation de l’image de l’entreprise. C’est précisément la cause de la faillite de Diginotar, il faut bien comprendre qu’un tiers de confiance est là pour assurer, entre deux parties, la légitimité d’un échange de données. Le tiers de confiance peut-être assimilé à un notaire qui garantie l’authenticité des échanges informatiques.

Notons qu’il s’agit de l’un des impacts économiques les plus importants suite à une attaque informatique. L’entreprise ne s’était pas préparée à une telle situation, pourtant, plus que n’importe quel autre organisme, les tiers de confiance doivent assurer leur prestation sans faux pas.

La bête se réveille

Les deux chercheurs ayant découvert une faille  mettant en périple le chiffrement SSL/TLS qui est largement utilisé pour garantir la confidentialité et l’intégralité des données échangées sur internet, ont mis le doigt sur une vulnérabilité veille de plus de six ans.

Thai Duong et Juliano Rizzo ont démontré la fiabilité de leur exploit lors de la conférence sur la sécurité, Black Hat Ekoparty.

La version 1.1 du protocole de chiffrement n’est a priori pas concernée par l’exploit, mais la majorité des sites web, VPN et services de messagerie instantanée utilisent encore la version 1.0 en raison de sa forte inter-compatibilité.

La Bête, BEAST en anglais pour Browser Exploit Against SSL/TLS, décrypte les requêtes http sécurisées entre le navigateur et le serveur. L’exploit est un script Java qui utilise une faille lorsque le chiffrement se fait par blocs plutôt que par flux.

Jusqu’à présent, les responsables d’infrastructures ne souhaitaient par utiliser la dernière version du protocole. Par soucis de compatibilité…oui mais si toutes les organisations évoluaient ensembles, il n’y aurait pas de problème d’incompatibilité. La version 1.0 est la plus répandue alors qu’une autre version, non concernée par la faille déjà identifiée en 2004 mais avec un risque jugé faible, est déjà sortie depuis longtemps.

Windows annonce déjà être en train de travailler sur patch correctif.