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. »