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/

Attention au Flash

Ces derniers mois, on retrouve régulièrement le même schéma d’infection sur les systèmes d’information des entreprises avec la visite d’un site Internet infecté qui renvoie vers le téléchargement d’un virus.

Ceci donne du fil à retordre à certaines équipes techniques pour désinfecter les postes alors que d’autres ne rencontrent pas ces problèmes car elles ne sont pas infectés pour des raisons plutôt simples : elles n’ont pas de vecteur de compromission sur leur parc.

Un scénario de compromission

Nous constatons régulièrement des infections de machines à la suite de visites de sites Web injectés par du code malveillant.

Le scénario que l’on retrouve le plus souvent, fait suite à la visite d’un site légitime par un utilisateur.

Ce site légitime et de confiance sur lequel se rend l’utilisateur peut avoir été compromis et utilisé pour propager des logiciels malveillants.

En général, la navigation de l’utilisateur est redirigée à son insu vers un autre site dans le but de télécharger un virus.

Avant d’effectuer cette redirection malveillante, il est possible qu’il y ait une vérification de la configuration de la machine de l’utilisateur.

Cette vérification inclut le navigateur utilisé mais également certains logiciels annexes comme Adobe Flash Player ou encore Java de l’éditeur Oracle.

Il y a quelques temps, les attaquants s’intéressaient beaucoup à Java. De nombreuses vulnérabilités étaient régulièrement découvertes et exploitées pour ce logiciel.

Depuis plusieurs mois, l’intérêt se porte sur Adobe Flash Player. Ce logiciel permettant la lecture de contenus multimédias sur Internet est très présent sur le parc informatique des entreprises.

Aujourd’hui, Adobe Flash Player est le vecteur de compromission n°1.

Lorsqu’on regarde le nombre de vulnérabilités découvertes, on comprend pourquoi…

 

Graph_CERT_java_flash

Source tableau : CERT CYBERPROTECT

 

Mais pourquoi ces logiciels sont-ils plébiscités ?

La raison est simple, ils sont présents sur de nombreux équipements informatiques et sont multiplateformes.

C’est-à-dire qu’on les retrouve aussi bien sur une machine Windows, MAC, Linux et même sur d’autres plateforme comme les TV connectés (voir https://securelist.com/blog/73229/malware-on-the-smart-tv/).

Ce qui fait, qu’avec une vulnérabilité présente sur le logiciel Adobe Flash Player, cela rend l’équipement sur lequel il est installé vulnérable…

A noter, que certains sites comme Youtube ou Facebook abandonnent Flash au profit du HTML 5.

Des solutions ?

Pour se mettre à l’abri d’une compromission par ce vecteur, il y a deux solutions :

  • Maintenir à jour les logiciels
  • Désinstaller les logiciels.

La première solution est la seule solution dans la mesure où les logiciels en question sont nécessaires dans le cadre professionnel. C’est souvent le cas pour Java, qui est utilisé dans beaucoup d’application métier.

La seconde solution est la plus efficace car il faut savoir qu’outre le fait de maintenir les logiciels à jour demande des ressources, surtout lorsque les mises à jour sont fréquentes, des vulnérabilités de type « 0-day » peuvent exister et être exploitées.

Ces vulnérabilités dites « 0-day » peuvent être définies comme des vulnérabilités non corrigées par l’éditeur car ce dernier ne connait pas encore la vulnérabilité ou est en train de créer un correctif.

Entre le moment où une vulnérabilité est exploitée et que l’application d’un correctif est effectuée, il peut se passer un laps de temps important qui peut avoir des conséquences graves pour les entreprises en cas de compromission.

Et là on ne parle que du cas où l’on est conscient de la vulnérabilité, imaginez lorsqu’une vulnérabilité non connu est exploitée !

 

Daniel DIAZ – Analyste Cybersécurité – CERT Cyberprotect

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

Une vulnérabilité critique dans le client OpenSSH a été rendue publique (CVE-2016-0777).

Un pirate qui aurait compromis un serveur peut récupérer toutes les clés nécessaires pour se connecter à d’autres serveurs que possèderaient le client OpenSSH.

La vulnérabilité concerne les versions OpenSSH 5.4 et supérieures

Nous vous invitons à mettre à jour OpenSSH vers sa version la plus récente (après avoir vérifié la compatibilité avec les applications utilisées) –>  http://www.openssh.com/

Il est également possible d’appliquer la modification suivante sur vos machines pour remédier à la vulnérabilité :

dans le fichier ‘/etc/ssh/ssh_config

ajoutez la ligne suivante :

UseRoaming no

L’option existe mais n’est pas documenté.

ATTENTION, ne pas placer cette option dans la configuration du serveur (sshd_config).

Pensez à redémarrer le service SSH.

Plus d’informations sur http://seclists.org/oss-sec/2016/q1/97

[Bulletin d’alerte Cyberprotect] Faille critique Ghost sur systèmes GNU/Linux

Une faille critique touchant un grand nombre de systèmes GNU/Linux vient d’être rendue publique. Elle concerne l’exploitation d’une vulnérabilité dans Glibc (GNU C Library)

Glibc une bibliothèque standard permettant d’implémenter des opérations courantes programmées dans le langage C

Le fait que la majorité des systèmes utilise Glibc rend cette vulnérabilité particulièrement critique, notamment les serveurs Web et toutes autres machines exposées à l’Internet.

Cette faille de Glibc permet d’exécuter n’importe quelle commande sur les machines vulnérables avec pour conséquences la prise de contrôle de la machine, et ce, sans besoin d’authentification

Cette faille semble être facilement exploitable depuis l’extérieur puisqu’il semblerait que l’on puisse prendre la main sur un serveur de messagerie simplement en envoyant un courriel.

La vulnérabilité a pour référence :

CVE-2015-0235 –> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235

Des correctifs de sécurité corrigeant la vulnérabilité sont disponibles auprès des éditeurs des différentes distributions GNU/Linux.

Nous vous invitons à mettre à jour vos systèmes en vous focalisant en priorité sur les machines accessibles depuis l’extérieur de votre réseau (serveur de messagerie, serveur Web,…)

N’hésitez pas à diffuser ce message à vos contacts.

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]

[Bulletin d’alerte Cyberprotect] Faille critique Bash sur systèmes Unix/Linux

Une faille critique touchant un grand nombre de systèmes Linux et Mac OS X vient d’être rendue publique. Elle concerne l’exploitation d’une vulnérabilité dans Bash.

Bash est un environnement console disponible sur les systèmes afin d’exécuter des commandes.

Le fait que la majorité des systèmes utilise Bash rend cette vulnérabilité particulièrement critique, notamment les serveurs Web qui, eux, sont exposés à l’Internet.

Cette faille de Bash permet d’exécuter n’importe quelle commande sur les machines vulnérables avec pour conséquences la prise de contrôle de la machine. Cette faille est exploitable à distance.

Nous constatons déjà des scans de vulnérabilités sur Internet visant à découvrir les machines vulnérables, l’exploitation de cette vulnérabilité est donc déjà en cours.

Il est facile de vérifier si votre machine est vulnérable, il suffit d’exécuter la commande suivante :

 

 

si la commande retourne

vous etes vulnerable
ceci est un test

Et bien c’est que votre système est vulnérable !

Un premier correctif de sécurité a été publié mais une variante de la vulnérabilité a été découverte.

Vous pouvez vérifiez si votre machine est vulnérable, en exécutant la commande suivante :


si la commande retourne quelque chose comme

bash: X: line 1: syntax error near unexpected token `=’
bash: X: line 1: `’
bash: error importing function definition for `X’
Thu Sep 24 22:19:25 CEST 2014

avec la date affichée à la fin, c’est que votre système est vulnérable !

Les deux vulnérabilités ont pour référence :

CVE-2014-6271 –> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271

et

CVE-2014-67169 –> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169

Des correctifs de sécurité commencent à être publiés par les éditeurs corrigeant les deux variantes de la vulnérabilité. Dans le cas où les tests se sont révélés positifs, merci de vérifier régulièrement, si des correctifs sont disponibles. Une fois les correctifs de sécurité appliqués sur vos systèmes, réessayez les deux commandes précédentes afin de vous assurer de l’efficacité des correctifs.

N’hésitez pas à diffuser ce message à vos contacts.

 

Informations complémentaires  sur le bulletin du CERT-FR –> http://www.cert.ssi.gouv.fr/site/CERTFR-2014-ALE-006/CERTFR-2014-ALE-006.html

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/

[MaJ] Vulnérabilité Java 1.7 = les recommandations du Labo Cyberprotect

Mise à jour 31/08/2012

 

Oracle a sorti, en urgence, un correctif pour la vulnérabilité Java des versions 1.7

Une mise à jour pour Java 1.6 est également disponible.

 

Vous trouverez Java 1.6.0_35 [ici] et Java 1.7.0_07 [ici]

 

*******************************************************************************

Une faille dans les versions de java 7 (1.7.0_xx) est actuellement en cours d’exploitation par des malwares.

Cette faille ne possède pas, à l’heure actuelle, de correctif de sécurité.
Il est fortement recommandé de désactiver Java 7 (1.7.0_xx) lorsque cette version est installée.

Si l’utilisation de java vous est indispensable, nous vous recommandons la désinstallation de la version « 1.7.0_xx » pour l’installation de la version « 1.6.0_34 » que vous trouverez [ici]

Les version inférieures à « 1.6.0_34 »  sont vulnérables à de nombreux exploits.

Procédure de désactivation pour les utilisateurs d’ « Internet Explorer »

Cliquez dans « Outils » puis « Options Internet »
Dans l’onglet « Sécurité » , cliquez sur « Personnaliser le niveau »
Faites dérouler jusqu’à « Script des applets Java » et Choisissez « Demander » ou « Désactivé »
(Si java est nécessaire une application métier, cochez « Demander » et n’autorisez Java que pour cette application.
Dans le cas inverse, nous vous recommandons « Désactivé » en attendant la mise à dispostion d’un correctif de sécurité.)
Puis cliquez sur « Ok »

Procédure de désactivation pour les utilisateurs de « Google Chrome »

Cliquez sur le bouton « Configurer et personnaliser Chrome » qui est réprésenté par une clé (en haut à droite du navigateur)
Cliquez sur « Paramètres »
Dans la partie « Confidentialité » (Il peut être nécessaire de cliquer sur « Afficher les paramètres avancés… » pour voir apparaitre la partie « Confidentialité »)
Cliquez sur le bouton « Paramètres du contenu … »
Puis descendez jusqu’à la partie « Plug-in »
Cliquez sur « Désactiver les plug-ins individuels… »
Descendez jusqu’au plug-in « Java »
Si ce plug-in indique que sa version commence par « 1.7 », cliquez sur désactiver (le liens se nommera alors « Activer »)
Si la version de java commence par «1.6.34 » votre version est à jour, sinon il est nécessaire de la mettre à jour.
(http://java.com/fr/download/manual_v6.jsp)

Procédure de désactivation pour les utilisateurs de « Mozilla Firefox »

Dans « Outils » puis choisissez « Modules complémentaires »
Cliquez sur le bouton « Désactiver » en face des modules Java

Procédure de désactivation pour les utilisateurs de « Safari »

Allez dans « Préférences » puis dans « Sécurité »
Décochez « Activer Java »

Sources :

http://www.certa.ssi.gouv.fr/site/CERTA-2012-ALE-005/index.html

http://www.kb.cert.org/vuls/id/636312

http://www.us-cert.gov/cas/techalerts/TA12-240A.html