HeartBleed, la faille qui touche au coeur la suite OpenSSL

OpenSSL est sous pression ces derniers temps. Après la faille surnommée « GotoFail », une nouvelle faille critique impactant le logiciel vient d’être divulguée.

Mais, au fait, que sont OpenSSL et HeartBeat ?

OpenSSL est une librairie permettant entre autres de protéger les communications sur Internet à l’aide des protocoles SSL et TLS. HeartBeat est une extension des protocoles TLS (et DTLS) implémentée au sein d’OpenSSL. Celle-ci correspond à la RFC6520.

OpenSSL est utilisé dans de nombreux serveurs tels que les serveurs Web (à commencer par Apache) pour mettre en œuvre le célèbre protocole HTTPS. Cette librairie est cependant utilisée dans de nombreux autres logiciels : des serveurs IMAPS, FTPS, POP3S, mais aussi des clients tels que cURL.

La faille concerne-t-elle OpenSSL dans son ensemble ?

Non, la vulnérabilité référencée CVE-2014-0160 impacte uniquement l’extension « HeartBeat », implémentée au sein de certaines versions d’OpenSSL. Cela signifie que les versions d’OpenSSL compilées sans le support de cette extension (option -DOPENSSL_NO_HEARTBEATS utilisé lors de la compilation), et les versions dans lesquelles cette extension n’avait pas encore été introduite (versions antérieures à OpenSSL 1.0.1 : 0.9, 0.8…) ne sont pas concernées.

De même, les serveurs (Apache, Nginx…) tirant parti d’OpenSSL, mais permettant de désactiver l’utilisation de TLS ne sont pas vulnérables.

Et concrètement, quelle est la faille, et que permet-elle de faire ?

La faille est liée à un manque de validation des informations contenues dans le message de HeartBeat. Il en résulte qu’un pirate est en mesure de provoquer une faille de type « buffer over-read », afin d’accéder à des données présentes en mémoire, dans la limite de 64 kB.

L’exploitation de cette vulnérabilité permet de lire le contenu d’une partie de la mémoire d’un système vulnérable. Pour cela, il suffit « simplement » d’établir une session SSL, puis d’envoyer un message « Heartbeat ».

De plus en répétant cette opération, il est possible d’obtenir de nouvelles informations issues de la mémoire.

Cela permet donc potentiellement d’accéder à de nombreuses informations sensibles, telles que des clefs privées associées aux certificats SSL utilisés pour chiffrer le trafic, des identifiants de connexion appartenant aux visiteurs d’un site, ou encore les en-têtes HTTP comprenant notamment les cookies de sessions ou l’authentification Basic permettant d’usurper l’identité d’un internaute.

Quand et comment cette faille a-t-elle été découverte ?

La vulnérabilité Heartbleed a été divulguée lundi 7 avril au soir. Elle a été découverte par plusieurs chercheurs de manière simultanée, alors même que ces derniers travaillaient de manière isolée. Les chercheurs en question sont Neel Mehta, qui travaille pour Google, ainsi qu’une équipe de la société Codenomicon, constituée des chercheurs Riku, Antti et Matti.

Alors que Google avait contacté les développeurs d’OpenSSL pour les alerter de l’existence de la faille, et proposer un correctif de sécurité, les chercheurs de Codenomicon ont préféré contacter le CERT Finlandais NCSC-FI pour lui déléguer la tâche de coordination.

Au final, même si cette faille a été rapportée de manière responsable à OpenSSL qui a finalement révélé son existence en publiant le correctif de sécurité, il a résulté de cette double découverte un certain cafouillage. En effet, tous les acteurs concernés par le déploiement rapide d’un correctif (éditeurs de distribution Linux, géants de l’Internet tels que Amazon (ou encore là), Cloudflare et autre CDN) n’ont pas eu le même niveau d’information au même moment. Les développeurs d’OpenSSL ont donc été obligés de publier leur correctif prématurément avec un jour d’avance sur le planning initialement prévu.

L’exploitation de cette faille laisse-t-elle des traces ?

Non, l’exploitation de la faille ne peut être identifiée a posteriori. En effet, seule l’analyse « en direct », à l’aide d’un sniffer et de règles de détection appropriées permettrait d’identifier si la faille est exploitée.

Existe-t-il des codes d’exploitations disponibles publiquement ?

Oui, plusieurs codes d’exploitation ont été publiés sur Internet.

Le premier (lien) a été divulgué dans les heures qui ont suivi la présentation de la vulnérabilité. Il prend la forme d’un script en Python. Il permet d’envoyer deux messages afin d’établir la connexion SSL : un paquet « hello », puis un paquet « heartbeat ». Dans le cas ou l’exploitation réussie, le contenu de la mémoire du serveur est présenté à la manière d’un dump « hexdump ».

[1]
[2]

Une seconde version de ce script permettant de tester les serveurs STARTTLS a ensuite fait son apparition sur Internet.

Enfin, un code d’exploitation a été publié au sein du Framework Metasploit

Comment savoir si mon système est vulnérable ou pas ?

Nous avons intégré une nouvelle fonctionnalité au sein de notre service de Cyber-surveillance afin d’évaluer si la vulnérabilité impacte les ressources de nos clients, de façon automatique, sur des périmètres étendus exposés sur Internet.

Plusieurs outils ont également été mis à votre disposition pour cela :

Est-il possible de s’en protéger ?

Pour commencer, il est nécessaire de savoir quels sont les systèmes impactés par cette faille. Comme nous l’expliquions auparavant, seuls les serveurs utilisant une version d’OpenSSL 1.0.1 (antérieure à 1.0.1g) sont vulnérables[3].

La commande suivante vous permet de connaître la version installée sur votre système :

$ openssl version OpenSSL 0.9.8y 5 Feb 2013

Attention tout de même à ne pas tomber dans deux pièges :

  • OpenSSL peut être compilé en statique au sein d’un logiciel, auquel cas, la commande précédente ne retourne pas forcément la bonne information.
  • L’ensemble des serveurs s’appuyant sur OpenSSL est vulnérable, pas uniquement les serveurs Web (HTTPS). Les serveurs IMAPS, FTPS, ou encore POP3S sont aussi concernés.

Dans le cas où une version vulnérable est utilisée, plusieurs possibilités s’offrent à vous :

  • Appliquer le correctif ;
  • Ou, mettre en œuvre des solutions de contournement.

Plusieurs distributions Linux ont mis à disposition un correctif de sécurité dès la divulgation de la faille :

Quelles sont les solutions de contournement ?

Il en existe plusieurs. Dans tous les cas, il doit s’agir de solution temporaire, en l’attente du déploiement du correctif.

La première consiste à recompiler OpenSSL avec l’option « -DOPENSSL_NO_HEARTBEATS » pour désactiver le support de l’extension HeartBeat.

La deuxième consiste à modifier la configuration d’un serveur afin de désactiver le support de TLS. Pour cela, on peut utiliser une règle similaire à la suivante (au sein d’Apache) :

SSLProtocol -all +SSLv3

Attention tout de même, l’utilisation de SSLv3 n’est cependant pas recommandée…

La troisième consiste à bloquer les paquets suspects au niveau du Firewall. Des règles Iptables ont été proposées pour cela sur Internet. Ces règles IPTables n’ont cependant pas été testées par le CERT-XMCO. Par ailleurs, ces règles ne permettent de protéger qu’un serveur web (–dport 443). Attention à ne pas oublier les autres services vulnérables !

# Log rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT" # Block rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j DROP

Enfin, une dernière solution de contournement a été proposée aux utilisateurs de l’IDS/IPS Suricata. Celle-ci est disponible à l’adresse suivante : http://blog.inliniac.net/2014/04/08/detecting-openssl-heartbleed-with-suricata/

Des règles similaires existent pour l’IDS Snort de SourceFire (SIDs compris entre 30510 et 30517). http://vrt-blog.snort.org/2014/04/heartbleed-memory-disclosure-upgrade.html

Quelles sont les recommandations du CERT-XMCO ?

Sur une échelle de 1 à 10, on peut donc catégoriser cette vulnérabilité à 11, indiquait Bruce Schneier. Après les récents déboires de GnuTLS ou du GotoFail d’Apple, SSL est clairement sous pression.

D’après des chercheurs, environ 17% des serveurs web utilisant des certificats SSL seraient vulnérables. Ce chiffre peut paraître faible, mais il est compréhensible pour deux raisons :

  • seuls les serveurs utilisant le TLS/DTLS sont vulnérables ;
  • seules les versions 1.0.1 à 1.0.1f et 1.0.2beta sont vulnérables ; or cette version n’a été adoptée que très récemment.

Cependant, il n’en reste pas moins que pour le CERT-XMCO, il faut considérer que toutes les informations sensibles ayant transité sur des serveurs vulnérables ont potentiellement été compromises.

La révocation des anciens certificats SSL, et leur remplacement sont donc des mesures à envisager, avant de procéder au renouvellement des mots de passe des utilisateurs.

Et la suite ?

Des chercheurs ont montré, il y a quelques heures, que les serveurs n’étaient pas les seuls composants vulnérables. Les clients utilisant OpenSSL le sont aussi. Un exploit a d’ailleurs été publié.

Suite à l’ensemble des révélations d’Edward Snowden, on peut s’interroger sur cette vulnérabilité. Des éléments pointés du doigt par l’EFF laissent penser que cette vulnérabilité a été exploitée en novembre 2013.

http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

Notes

[1] https://twitter.com/1njected/status/453797877672706048

[2] https://twitter.com/moyix/status/453760960671383552/photo/1

[3] En réalité, la version d’OpenSSL 1.0.2 (antérieure à 1.0.2-beta1) est aussi vulnérable, mais s’agissant d’une version en cours de développement, elle ne devrait pas être utilisée en production.

CERT-XMCO

Découvrir d'autres articles

En savoir plus En savoir plus