Vulnérabilité de type « backdoor » dans les firewalls Juniper SSG/NS

Nous vous informons que deux vulnérabilités de type « backdoor » viennent d’être rendues publiques dans les firewalls Juniper SSG/NS.

Deux pour le prix d’une …

Deux vulnérabilités différentes affectent ces produits :

  • La première concerne l’accès SSH d’administration
  • La seconde concerne les tunnels VPN IPsec

La première vulnérabilité SSH a déjà vu un exploit mis en ligne, et doit donc être urgemment patchée. Vous pouvez consulter les détails techniques sur le blog de Rapid7 :
CVE-2015-7755: Juniper ScreenOS Authentication Backdoor

https://community.rapid7.com/community/infosec/blog/2015/12/20/cve-2015-7755-juniper-screenos-authentication-backdoor

Alerte Juniper

Deux vulnérabilités ont donc été découvertes et rendues publiques dans ScreenOS. Un premier bulletin a été émis : Out of Cycle Security Bulletin: ScreenOS: Multiple Security issues with ScreenOS (CVE-2015-7755)

Vous pouvez consulter les informations en utilisant les liens suivants :

Les versions affectées sont ScreenOS 6.2.0r15 jusqu’à 6.2.0r18, ainsi que 6.3.0r12 jusqu’à 6.3.0r20.

Patch

Les clients concernés par ces vulnérabilités doivent mettre à jour absolument leurs firewalls avec les versions minimales :

  • ScreenOS 6.2.0r19
  • ScreenOS 6.3.0r21

Conclusion

Vous devez maintenir à jour vos équipements de sécurité. Les produits SSG et NS de Juniper sont obsolètes. Nous conseillons à nos clients de migrer rapidement vers les produits FortiGate de FORTINET, qui disposent de plus de fonctionnalités et d’un suivi par l’éditeur.

Il faut disposer d’équipements à jour en version, afin de maintenir un dispositif de sécurité efficace et pertinent. Pour cela, vous pouvez compter sur nos équipes pour assurer conseil et support.

Vulnérabilités installées par Lenovo et Dell

Deux vulnérabilités viennent d’être, à quelques semaines d’intervalle, imputées à deux constructeurs majeurs d’ordinateurs : Lenovo et Dell.
La nouveauté tient au fait que ces vulnérabilités ont été délibérément installées par ces constructeurs, dans les masters Windows fournis préinstallés sur les ordinateurs vendus. Malgré le mea culpa des fautifs, la question de la confiance numérique revient sur le devant de la scène.

Lenovo – superfish

Mis sous pression par les experts en sécurité IT, Lenovo a reconnu avoir préchargé, sur certains de ses PC portables, un logiciel espion baptisé Superfish.

Après avoir tenté de minimiser l’affaire, le constructeur chinois a finalement avoué : il a émis une alerte et proposé la désinstallation de programme développé par la société américaine Superfish. En effet, des utilisateurs de notebooks Lenovo sous Windows se plaignaient de la présence de ce logiciel publicitaire qui surveille le trafic Web et injecte des recommandations produits dans les résultats de recherche.

Superfish agit aussi lorsque les connexions sont chiffrées via le protocole SSL (Secure Sockets Layer).
Comment ? En installant son propre certificat racine dans le gestionnaire de certificats Windows. Il fonctionne alors comme un proxy et implante sa propre signature dans tous les certificats présentés par des sites HTTPS, trompant ainsi les navigateurs Web. Les systèmes sur lesquels l’adware est installé sont donc vulnérables aux attaques de type « Man-in-the-middle » et donc au vol de données personnelles.

Dell

Le problème avec Dell est assez similaire, du moins dans ses conséquences. Ici, point de logiciel espion installé, mais des certificats de sécurité auto-signés par Dell, et préinstallés en standard dans les ordinateurs équipés de Windows.

eDellRoot

Le premier, baptisé eDellRoot – est classé par de nombreux logiciels comme étant « de confiance ». Ce qui lui permet de signer, avec sa clé privée, un certain nombre d’autres certificats via leurs clés publiques. Par exemple dans les navigateurs Web, pour vérifier les identités lors d’une connexion sécurisée (HTTPS) à un domaine. Problème : eDellRoot et sa clé privée peuvent être récupérés par des tiers via des outils largement diffusés, comme Jailbreak de NCC Group. Quiconque parvient à l’extraire et à en créer une copie peut l’utiliser pour signer un logiciel malveillant ou pour l’associer à un site Web frauduleux qui déchiffre l’ensemble des données envoyées par les internautes.

En l’état actuel, Dell a présenté ses excuses et propose des instructions pour supprimer eDellRoot. Un exécutable est également disponible pour automatiser le processus. Ce n’est pas suffisant pour protéger les utilisateurs : il faut aussi éliminer Dell Foundation Services, à défaut d’autres solutions pour le moment.

DSDTestProvider

Un deuxième certificat vient d’être découvert dans la foulée du premier. Des chercheurs annoncent avoir constaté la présence de DSDTestProvider sur un nouveau portable de la firme. Ce certificat est également auto-signé et contient une clé privée. Une configuration propre à permettre à des intrus d’intercepter des communications chiffrées depuis un PC Dell.

Si le rôle de DSDTestProvider a visiblement un lien avec le site web de support du constructeur, pour le moment, la présence du certificat reste obscure. De son côté, un porte-parole a assuré que Dell a ouvert une enquête pour expliquer la présence de ce nouveau certificat douteux et son rôle. Et proposer un moyen de le supprimer.

Quelles actions mener ?

Pour le déploiement des systèmes Windows sur vos postes de travail et serveurs, il est donc primordial de ne pas laisser les systèmes préinstallés par les constructeurs. Ils sont souvent truffés de logiciels inutiles, voire dangereux.

Les bonnes pratiques dans ce domaine sont connues :

  1. il faut recréer des masters à partir des images de Microsoft,
  2. et les personnaliser avec vos outils (antivirus, gestion de parc et inventaire, bureautique). Il existe de nombreux outils aujourd’hui pour réaliser et déployer ces masters à grande échelle.
  3. Par ailleurs, il est important aussi de protéger vos utilisateurs lorsqu’ils accèdent à Internet, par des mécanismes de filtrage (proxy) avancé, qui contrôle la présence de malwares et qui vérifient la sécurité des flux SSL, en se basant sur leur propre magasin de certificats sûrs.

Vulnérabilité sévère dans GLIBC sur Linux

Découverte de la vulnérabilité « GHOST »

Qualys publie un bulletin de sécurité pour la vulnérabilité « GHOST » découverte sur les systèmes Linux. Cette vulnérabilité sévère détectée dans la bibliothèque C de GNU/Linux donne le contrôle aux attaquants sans nécessiter d’identifiants système.

Explications

Le 27 janvier 2015, Qualys annonce que son équipe chargée de la recherche en sécurité a découvert dans la bibliothèque C de GNU/Linux (glibc) une vulnérabilité critique qui permet aux pirates de prendre le contrôle à distance de tout un système en se passant totalement des identifiants système. Qualys a travaillé de manière étroite et coordonnée avec les fournisseurs de distributions Linux pour proposer un patch pour toutes les distributions de systèmes Linux touchés. Ce patch est disponible dès aujourd’hui auprès des fournisseurs correspondants.

Baptisée GHOST (CVE-2015-0235) parce qu’elle peut être déclenchée par les fonctions http://www.gnu.org/software/libc/manual/html_node/Host-Names.html cette vulnérabilité touche de nombreux systèmes sous Linux à partir de la version glibc-2.2 publiée le 10 novembre 2000. Les chercheurs Qualys ont par ailleurs détecté plusieurs facteurs qui atténuent l’impact de cette vulnérabilité parmi lesquels un correctif publié le 21 mai 2013 entre les versions glibc-2.17 et glibc-2.18. Malheureusement, ce correctif n’ayant pas été classé comme bulletin de sécurité, la plupart des distributions stables et bénéficiant d’un support à long terme ont été exposées, dont Debian 7 (« Wheezy »), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7 et Ubuntu 12.04.

Compte tenu du nombre de systèmes basés sur glibc, nous considérons qu’il s’agit d’une vulnérabilité sévère qui doit être corrigée immédiatement. La meilleure marche à suivre pour atténuer le risque est d’appliquer un patch fourni par votre fournisseur de distributions Linux.

Comment se protéger

LINUX DEBIAN

Les distributions Debian 6 (Squeeze), Debian 7 (Wheezy) et Debian 8 (Jessie) sont vulnérables.

  • La version 6 (oldstable) n’est plus activement maintenue, sauf en utilisant le canal LTS (Long Term Support).
  • La version 7 (stable) est maintenue, il suffit de mettre à jour les paquets (apt)
  • La version 8 (testing) est maintenue, il suffit de mettre à jour les paquets (apt)

Plus d’informations : https://security-tracker.debian.org/tracker/CVE-2015-0235

LINUX REDHAT / CENTOS

Les distributions RHEL 5, RHEL 6 et RHEL 7 sont vulnérables.

  • Red Hat Enterprise Linux version 5 (glibc) RHSA-2015:0090
  • Red Hat Enterprise Linux version 6 (glibc) RHSA-2015:0092
  • Red Hat Enterprise Linux version 7 (glibc) RHSA-2015:0092

Plus d’informations :

Conclusion

Vous devez mettre à jour de manière urgente tous vos systèmes Linux. Pour les systèmes RedHat et CentOS, le produit de gestion de parc RedHat Satellite, et son équivalent opensource Fedora Spacewalk, sont un atout précieux pour automatiser et déployer des mises à jour.

 

Recrudescence d’attaques de sites web annoncée pour le 15/01/2015

Multiplication des attaques

L’actualité récente de l’assassinat de salariés de Charlie Hebdo a vu plusieurs contre-effets. Un immense élan populaire de solidarité d’un côté. De l’autre, dans l’espace numérique, des actions et réactions. Différents groupes liés aux Anonymous ont commencé des représailles visant des activistes islamistes. En réaction, des activistes islamistes ont entrepris d’attaquer des sites web, en France notamment.

 

Annonce d’attaques de site web pour le 15/01/2015

Des opérations d’attaques informatiques ont été annoncées pour la journée du 15 janvier 2015, par des groupes de pirates informatiques. Pour l’essentiel, il s’agirait d’attaques de type « defacement », qui visent à remplacer la page d’accueil du site par un message revendicatif.

Exemple :

exemple defacement

Bien que ce type d’attaques soit relativement courant, l’évènement tient à l’annonce d’un nombre important de cibles sur un délai court. En prémices, sur la journée du 12 janvier 2015, plus de 1000 sites institutionnels de collectivités locales ont été défacées.

Des attaques de type « déni de service distribué » (DDoS) sont aussi susceptibles de se produire, pour rendre les sites injoignables. Les serveurs croulant sous des requêtes factices. Ce type d’attaque semble plutôt cibler les systèmes de l’Etat (ministères, services centraux).

Comment se protéger ?

Préalable

Il faut tout d’abord bien cartographier ses applications. Connaitre quels logiciels sont exécutés sur quels systèmes est primordial. Il va vous permettre de déterminer la criticité de chaque application et le niveau de risque encouru.

Ensuite, vous y associez les informations suivantes :

  • Quelles conséquences en cas d’indisponibilité de l’application ?
  • Quelles conséquences en cas de perte ou vol des données ?
  • Quelles conséquences en cas d’altération des données ?

Actions

La première des précautions, qui est valable toute l’année, est de maintenir à jour les systèmes concernés. Disposer d’un système de dernière génération, sur lequel sont appliqués tous lespatchs de sécurité et correctifs de bugs fournis par l’éditeur.

Si vous utilisez des logiciels applicatifs, comme des CMS (Joomla, WordPress, Drupal), vous devez aussi (et surtout) les maintenir à jour. La majorité des attaques de type « defacement » exploitent des failles de ces logiciels très courants.

Vous devez disposer de sauvegardes viables pour parer à toute éventualité.

Enfin, deux niveaux de protection complémentaires sont efficaces contre ces menaces :

–          Un pare-feu (firewall) qui publie un service web fournit des protections contre les attaques réseaux, via des fonctionnalités IPS (Intrusion Prevention System). Sur les firewalls FortiGate, il suffit d’appliquer le profil « protect_http_server » sur la règle d’accès pour protéger la ressource.

–          Un reverse proxy (waf) permet d’apporter de la sécurité applicative à vos sites. Il embarque des signatures d’attaques et d’exploit référencés quotidiennement, pour empêcher les robots de s’introduire et de corrompre le site. Sur les appliances FortiWeb, ces signatures sont incluses. De plus, une fonctionnalité « Anti-Defacement » permet automatiquement de réparer le site en cas de defacement qui aurait abouti.

Conclusion : mise à jour urgente de vos systèmes et applications web.

Vous devez mettre à jour de manière urgente vos systèmes et applications web. Vous devez vérifier que vous disposez de sauvegardes viables en cas d’incident avéré.

Si vous disposez d’équipements firewall et reverse proxy filtrant (waf), vous serez bien préparés. Surveillez les incidents qui pourraient se produire (logs). Si vous ne disposez pas des deux, vos applications sont exposées.

Ce type d’actions, orchestrées et mis à exécution par des dizaines de postes contrôlés (zombies), va se développer et s’intensifier à l’avenir. La technique est facilitée aujourd’hui par des outils à disposition des pirates, et des failles de sécurité publiées toujours plus vite. Laissant aux éditeurs peu de temps pour corriger leurs logiciels, et ensuite, aux utilisateurs pour les appliquer.

 

Alerte de vulnérabilité DNS – Déni de service par récursion infinie

Une sérieuse faille de sécurité du DNS a été publiée aujourd’hui. Elle affecte essentiellement les résolveurs, et touche plusieurs logiciels (au moins BIND, Unbound et PowerDNS). Elle permet de faire des dénis de service simplement, ce qui représente un risque avéré en termes d’exploitation.

Explications sur cette faille de sécurité du DNS

L’ANSSI (Agence nationale de la sécurité des systèmes d’information) a publié une analyse détaillée de la vulnérabilité. Cette vulnérabilité peut être exploitée pour effectuer des dénis de service des infrastructures DNS elles-mêmes, ainsi qu’être employée pour effectuer des attaques en dénis de service distribuées contre des tiers, avec une amplification de paquets significative.

L’article publié par l’ANSSI est disponible en ligne : http://www.ssi.gouv.fr/fr/menu/actualites/vulnerabilite-dns-critique-attaque-en-deni-de-service-par-recursion-infinie.html

La résolution DNS (noms vers IP, ou IP vers noms) est à la base de tous les services réseaux. C’est un composant d’infrastructure primordial à préserver, tant en termes de performance que de résilience.

Implémentations

Implémentations libres

 Implémentations propriétaires

Le service DNS inclus dans Windows Server n’est pas vulnérable. Il implémente déjà un mécanisme d’abandon d’une requête au bout d’un temps donné (timeout).

Les explications techniques sont détaillées dans un article TechNet :
http://blogs.technet.com/b/networking/archive/2014/12/15/handling-endless-delegation-chains-in-windows-dns-server.aspx

Conclusion – actions à mettre en oeuvre

Vous devez mettre à jour de manière urgente vos serveurs DNS sur votre infrastructure. Il est d’ailleurs préférable d’utiliser des résolveurs-cache locaux, plutôt que les serveurs de votre fournisseur d’accès internet, pour les raisons suivantes :

  • Délais de résolution plus courts (navigation web plus fluide)
  • Meilleure maîtrise des problématiques de sécurité
  • Implémentation de la non-répudiation des réponses (DNSSEC)

Le déchiffrement HTTPS

Le protocole HTTPS correspond à une enveloppe de communication pour les applications Web, sécurisée par les protocoles cryptographiques SSL ou TLS (SSL étant à proscrire au profit de TLS).

Utilisé avec le protocole HTTP, TLS permet de garantir la confidentialité et l’intégrité des échanges entre un client et un serveur Web, de garantir l’identité du serveur Web, et dans certaines implémentations, l’authentification du client (pour cela, l’utilisation d’un certificat client est nécessaire).

Le but de cet article n’est pas d’expliquer en détail le fonctionnement du protocole HTTPS, mais bien de mettre en avant les enjeux liés à la nécessité de mettre en place le déchiffrement HTTPS sur les flux sortant (le déchiffrement HTTPS est aussi réalisé pour le traitement des flux entrant).

Le fonctionnement TLS

Cependant, pour bien comprendre les enjeux de l’usage du protocole HTTPS et des implémentations nécessitant un déchiffrement HTTPS, rappelons ses grands principes de fonctionnement.

 

Utiliser le protocole HTTPS nécessite donc l’utilisation d’un certificat électronique sur vos serveurs Web (ou sur vos passerelles dans le cas du déchiffrement HTTPS). Ce certificat correspond à la carte d’identité électronique du serveur web, et contient notamment une clé publique qui sera envoyée vers le client lors de l’établissement de la session HTTPS. Cette clé sera utilisée par le client pour envoyer de façon sécurisée au serveur web ce qu’on appelle un « pré-secret », qui sera donc uniquement connue du client et du serveur.

A partir de ce pré-secret, le client et le serveur seront à même de définir un « secret maître » permettant, par dérivation de ce dernier, de générer des clés de session utilisées pour protéger l’échange des données dans HTTPS. Par ce procédé, on se rend bien compte que la sécurité de l’établissement d’une session HTTPS repose principalement sur la sécurisation de la clé privée du serveur Web. En effet, si cette dernière était compromise, alors un pirate ayant intercepté la phase d’échange présentée sur le schéma ci-dessus ainsi que la clé privée, serait alors à même de déchiffrer l’ensemble des échanges, car pourrait prendre connaissance des algorithmes échangés ainsi que le pré-secret lui permettant de reproduire les clés de sessions. Pour cela, il est fortement recommandé d’utiliser la propriété PFS (Perfect Forward Secrecy) afin que la confidentialité d’échange du pré-secret ne repose pas sur la clé privée du serveur Web, mais sur un échange de type Diffie-Hellman.

Dans cette implémentation, le certificat du serveur Web est utilisé uniquement pour garantir l’identité du serveur. Malgré tout, une compromission de la clé privée du serveur Web permettrait à un assaillant de prendre l’identité de votre serveur Web, et de rediriger les Internautes vers un faux serveur Web de votre organisation.

Le certificat

Afin que le client puisse avoir confiance dans le certificat fourni par le serveur Web, ce dernier devra présenter un certificat digne de confiance, c’est-à-dire émanant d’une autorité de certification de confiance. La confiance apportée à un certificat réside dans sa faculté à s’assurer de l’intégrité de ce dernier, par la validation de la signature électronique du certificat.

La signature électronique d’un certificat correspond à un ensemble de champs du certificat qui sont chiffrés par la clé privée de l’autorité de certification ayant émis le certificat. Ainsi, tout client disposant de la clé publique de l’Autorité de certification sera à même de valider la signature électronique du certificat, et ainsi avoir confiance dans ledit certificat.

Outre la confiance apportée dans un certificat, il est impératif pour un usage de confiance que le certificat ait une durée de validée non-périmée, que le nom du certificat (ou un de ses noms dans le cas d’usage de certificats avec des champs SAN) corresponde bien au nom de la requête HTTPS, et que le certificat ne soit pas révoqué.

Les avantages du déchiffrement HTTPS

L’usage du protocole HTTPS devrait être systématique dès lors qu’un site Web propose des champs de saisis de données confidentielles, comme un numéro de carte bleu, un mot de passe, ou encore des données confidentielles ou dont l’intégrité ne doit pas être remise en cause.

Vous aurez certainement remarqué que certains acteurs du monde Internet, comme Google, militent pour un Internet sécurisé. D’ailleurs, Google utilise le protocole HTTPS pour son moteur de recherche et l’ensemble de ses applications. Google incite aussi le monde de l’Internet à utiliser HTTPS en privilégiant les sites sécurisé pour un meilleur référencement.

La grande majorité des entreprises et collectivités utilisent des solutions de filtrage d’URL ou de contenu, pour répondre aux périmètres suivants :

  • Protection légale de la navigation Internet ;
  • Protection sécuritaire vis-à-vis des menaces véhiculées par le Web ;
  • Traçabilité des accès Internet ;
  • Réduction de la baisse de productivité liée au surf Internet ;
  • Maitrise de la bande passante ;
  • Mise en cache de contenu Web pour accélérer la navigation Internet ;
  • Protection contre l’exfiltration de données.

Tous ces besoins peuvent être adressés car les relais Web sortant sont capables d’analyser le contenu des requêtes HTTP, et ainsi appliquer l’action voulue. Or, dans le cas de HTTPS, les flux étant chiffrés, il est impossible d’apporter à ces derniers le même niveau de protection que pour les flux HTTP.

Très peu de proxy mandataires sont à ce jour configurés pour analyser les flux HTTPS. Les pirates le savent bien, c’est pour cela que de nombreuses attaques sont de nos jours encapsulées dans le protocole HTTPS, pour déjouer tous les filtres et passerelles que vous avez pu mettre en place.

Il est estimé qu’en 2015, presque 80 % de l’Internet sera sous la protection de HTTPS. Par cette statistique, on se rend compte que les solutions de protection actuelles ne permettront plus de répondre aux besoins initiaux (protection, politique d’accès Internet, traçabilité etc.).

Il est donc important de réaliser sur vos passerelles un déchiffrement HTTPS, afin d’apporter le même niveau de protection sur les flux chiffrés que ceux en clairs.

Fonctionnement du déchiffrement HTTPS

Pour cela, il est nécessaire que votre relais mandataire intègre un serveur TLS. En effet, lors de la mise en œuvre du déchiffrement HTTPS, 2 sessions HTTPS sont mises en œuvre, une première entre le client Web et le relais mandataire, une seconde entre le relais mandataire et le serveur Web.

Dans ce mode de fonctionnement, le proxy mandataire peut déchiffrer le flux TLS, l’inspecter, avant de le chiffrer de nouveau vers le serveur Web ou le client Web (pour le sens retour de la communication).

Le client Web est donc client TLS du relais mandataire, ce dernier étant lui client TLS du serveur Web. C’est donc de la responsabilité du relais mandataire de faire toutes les vérifications nécessaires vis-à-vis du certificat présenté par le serveur Web. Le client Web doit « uniquement » avoir confiance dans le certificat présenté par son relais mandataire. Il est donc important dans une telle mise en œuvre de déployer le certificat d’Autorité de certificationutilisé par le relais mandataire sur l’ensemble des postes et serveurs soumis au déchiffrement HTTPS.

Le relais mandataire doit disposer non pas d’un certificat de type serveur Web, mais d’un certificat jouant le rôle « Autorité de certification » utilisé pour usurper l’identité du serveur Web. En effet, lorsqu’un client Web se connecte à une URL, il demande un nom FQDN. Lors de la connexion TLS, le client va vérifier que le certificat qui lui est présenté est digne de confiance, qu’il n’est pas révoqué, que sa période de validité est correcte, mais aussi va valider que le nom du certificat correspond bien au site demandé. Or le client Web n’établit jamais de connexion HTTPS vers le serveur Web, mais uniquement vers son relais mandataire. Pour cela, ce dernier va construire à la volée le certificat nécessaire au client, en donnant comme nom au certificat le FQDN demandé par le client Web (usurpation de l’identité du serveur Web). Ce certificat ainsi créé sera signé par la clé privée associé au certificat de type autorité de certification défini dans l’implémentation du déchiffrement HTTPS du relais mandataire.

Mise en garde

Malgré les avantages indéniables de mettre en place le déchiffrement HTTPS, il n’en demeure pas moins quelques inconvénients à connaitre avant sa mise en œuvre :

  • Etant donné que la validation du certificat du serveur Web est de la responsabilité du relais mandataire, les certificats de type EV (barre verte dans le navigateur) perdent de leur intérêt. De plus, la responsabilité du choix des suites cryptographiques utilisées pour chiffrer le canal HTTPS appartient au relais mandataire. Le client Web n’est plus en mesure de s’assurer qu’une suite renforcé est utilisée.
  • L’authentification par certificat client vers un serveur Web n’est plus possible. La solution est donc de mettre en place du « bypass » pour les sites concernés.
  • Le relais mandataire ne doit pas être compromis sous peine d’exposition des informations protégées par HTTPS.
  • Bien que la plupart des relais mandataires proposent un certificat de déchiffrement HTTPS,il est préférable d’utiliser un certificat provenant de votre propre autorité de certification, évitant ainsi l’usage d’un certificat générique utilisée sur toutes les plateformes de votre éditeur de proxy.
  • Le déchiffrement HTTPS est consommateur de ressource, assurez-vous de posséder de passerelles capables de supporter cette charge supplémentaire.

Vie privée et déchiffrement HTTPS

Au cours de nos nombreuses missions de mise en œuvre de proxy mandataire, vous êtes nombreux à nos faire part de vos craintes quant à la légalité de déchiffrer le trafic HTTPS.

L’ANSSI (Agence Nationale de la sécurité des systèmes d’informations) a publié le 9 octobre 2014 une note technique portant sur les recommandations de sécurité concernant l’analyse des flux HTTPS.

Dans cette note sont notamment stipulées les recommandations suivantes portant sur la vie privée :

  • « R22 : Ne pas procéder au déchiffrement de certains types de sites web identifiés comme étant destinés à un usage strictement personnel (certains sites bancaires par exemple).
  • R23 : La journalisation des flux déchiffrés doit être équivalente à celle configurée pour les flux http standards traité par le proxy. Elle ne doit pas permettre d’enregistrer davantage d’informations.
  • R24 : Si le proxy transmet à d’autres équipements le contenu déchiffré des flux HTTPS, les liens sur lesquels transitent ces informations doivent être protégés logiquement et physiquement pour éviter tout accès illégitime aux données. »

Poodle : vulnérabilité critique dans le protocole SSLv3

Poodle est une faille de sécurité dans le protocole SSL v3, publiée le 14 octobre 2014, permettant à un attaquant actif de découvrir des données chiffrées.

Que permet cette faille ?

Poodle est une faille de sécurité dans le protocole SSL v3, publiée le 14 octobre 2014, permettant à un attaquant actif de découvrir des données chiffrées.

Exploitation et conséquences

Poodle est référencé sous le nom CVE 2014-3566. Pour attaquer avec Poodle, il faut un client et un serveur TLS (pas forcément HTTPS, mais tout protocole avec chiffrement : IMAPS, POP3S, SMTPS, …) qui acceptent SSL v3 (la grande majorité) et les forcer à utiliser ce vieux protocole (en imposant un repli vers SSLv3, au lieu d’utiliser les protocoles TLS récents).

Mesures à prendre

Il faut impérativement désactiver SSL v3 (comme recommandé par le RGS de l’ANSSI). SSLv2 devant déjà être banni. Il faut donc n’utiliser que le protocole TLS, en version 1.0 et supérieure. Le cas le plus urgent est celui des serveurs HTTPS. On peut tester si un serveur accepte SSL v3 avec SSLlabs : https://www.ssllabs.com/ssltest/

Côté serveurs

Il faut désactiver le support de SSLv3 sur tous les serveurs exposés. Ceci inclut notamment :

  • Les solutions de VPN SSL (Juniper, Fortinet)
  • Les relais de messagerie (Websense, Trend Micro, Fortinet, Postfix)
  • Les proxys web (Websense, Trend Micro)
  • Les serveurs web (Apache, Nginx)
  • Les serveurs de messagerie (Exchange, Courier, Dovecot)

Côté clients

Il faut désactiver le support de SSLv3 sur tous les navigateurs, et notamment :

  • Internet Explorer
  • Mozilla Firefox
  • Google Chrome

Références

ShellShock : vulnérabilité critique dans l’interpréteur Bash sur Linux

Que permet cette faille ?

Cette faille permet d’exécuter du code arbitraire à distance sur votre système, permettant à un pirate d’en prendre le contrôle.

Comment fonctionne cette faille ?

Bash, ou Bourne-Again Shell, correspond au programme qui exécute les commandes que vous saisissez dans la console. Bash et le système d’exploitation conservent un ensemble de variables dites d’environnement, qui décrivent le contexte dans lequel vous évoluez : où se trouvent les programmes que vous pouvez utiliser, votre session… Grâce à cette faille, un pirate peut exploiter ces variables d’environnement pour exécuter du code malveillant.

Vecteurs d’attaques

Pour le moment, la faille est avant tout utilisée sur des serveurs utilisant CGI (Common Gateway Interface), via des entêtes HTTP piégées. CGI est le mécanisme d’exécution de beaucoup de langages de pages dynamiques (PHP, Perl, Python, Ruby…)

En effet, ces entêtes HTTP sont mappés par CGI et permettent d’exécuter le script Bash malveillant sur le serveur distant.

Versions vulnérables

Toutes les versions de Bash existant à ce jour (jusqu’à la 4.3) sont vulnérables. Des correctifs de sécurité ont été publiés par les principales distributions (Redhat, CentOS, Debian, Ubuntu).

Autres solutions vulnérables

Plusieurs éditeurs utilisent ce logiciel dans leurs solutions. Par incidence, il faut donc les mettre à jour aussi :

Références