Faille Heartbleed : la check-list pour s'en sortir

Depuis le 7 avril, un nom et un logo, jusqu'alors inconnus, ont fait le tour du Web : Heartbleed, un cour qui saigne. L'importance de cette faille de sécurité affectant la librairie de chiffrement SSL/TLS OpenSSL explique cet embrasement sur le sujet. Si les acteurs du Web ont très rapidement mis à  jour leur librairie (vers la version 1.0.1g expurgée de Heartbleed), le problème est loin - très loin même - d'avoir été réglé. Et il ne se limite pas aux seuls acteurs du Web : toutes les DSI sont, de près ou de loin, concernées par Heartbleed en raison de l'emploi très courant de la librairie OpenSSL dans des logiciels et matériels du marché.

En 5 points, Silicon.fr vous livre une première check-list pour évaluer les risques et prendre les premières contre-mesures.

1) Mesurer les risques

C'est évidemment la première question qui se pose aux DSI : quelles sont les informations que Heartbleed a pu permettre de dérober ? La réponse est simple : on n'en sait rien. Et c'est bien tout le problème. « A ce jour, on n'a aucune idée des dommages réels que va causer Heartbleed. Il est impossible de savoir quelles sont les données qui ont été exposées, surtout à  posteriori, et qui les a récupérées. D'o๠les questions qui se posent sur son éventuelle utilisation par la NSA », remarque Renaud Bidou, le directeur technique de l'éditeur DenyAll. Concrètement, Heartbleed est un bogue (un classique problème d'allocation de mémoire) dans l'implémentation d'un protocole appelé Heartbeat, ajouté à  OpenSSL en février 2012 afin d'améliorer les performances. La faille permet de récupérer 64 000 octets de mémoire. « Et cela concerne toutes les implémentations des versions infectées de OpenSSL : serveurs Web, VPN, reverse proxy. Dans ces 64 000 octets peuvent figurer des login et mots de passe mais aussi la clef privée du serveur, présente notamment lors d'un redémarrage de la machine », ajoute Renaud Bidou.

Bref, beaucoup d'informations extrêmement intéressantes pour des cybercriminels. Les couples login/mots de passe leur permettent d'effectuer des opérations illégitimes. La récupération de la clef privée ouvre encore davantage le champ des possibles. « C'est extrêmement sérieux : car, une fois en possession de ce sésame, un assaillant peut se faire passer pour le serveur légitime, via une attaque de type Man-in-the-middle », note Arnaud Soullié, auditeur sénior chez Solucom. « Nous sommes dans une phase de gestion de crise, après ce qu'il faut bien qualifier de dysfonctionnement majeur », résume Marc Cierpisz, manager du centre d'excellence Team Risk & Security de Devoteam. Gourou de la cybersécurité, Bruce Schneier avait d'ailleurs réagi en assurant que, sur une échelle de 1 à  10, Heartbleed valait un 11.

2) Comment réagir

D'abord, il faut souligner que la réaction de la communauté du Web a été extrêmement rapide. Selon des chiffres cités par DenyAll, le 8 avril, plus de 80 % des 100 000 plus grands sites de la planète étaient concernés par la faille. Le 9, ce taux était tombé sous les 5 %, après mise à  disposition de la nouvelle version de OpenSSL. « Si, pour une raison ou une autre, on ne peut pas passer à  cette mouture 1.0.1g de la librairie, il suffit d'effectuer une recompilation sans Heartbeat », ajoute Renaud Bidou. Une ligne de commandes suffit. Mais l'erreur serait de croire que le problème s'arrête là . Notamment dans les DSI â?~traditionnelles' ne gérant pas ou peu de sites Web transactionnels avec communications chiffrées. « La difficulté ici est que la faille touche tant le monde du développement et des applications Web, pour lequel des solutions existent - patches ou recompilation -, que des éléments physiques », remarque Marc Cierpisz.

## « La première priorité pour une DSI consiste à  réaliser un inventaire de tous les systèmes pouvant embarquer OpenSSL, ajoute Arnaud Soullié. Bien entendu, certains éléments, comme les serveurs Web Apache par exemple, s'imposent d'emblée. Mais il faut aussi penser à  tous les logiciels et matériels embarquant la librairie OpenSSL incriminée. Or, dans les DSI, cette information n'est pas centralisée. A ce jour, il n'existe pas d'outils permettant de réaliser un inventaire global sur un environnement informatique, même si des éditeurs d'outils de scan comme Qualys ou Nessus proposent des plug-ins pour réaliser un audit spécifique pour Heartbleed. Il faut donc répertorier tous les équipements utilisant des communications chiffrées, car dès que le protocole HTTPS est employé, il y a des probabilités importantes que la vulnérabilité soit présente ». Même si les OS Windows n'utilisent pas OpenSLL ou que d'autres librairies (comme PolarSSL) ou versions de OpenSSL ne sont pas concernées par le bogue, « sur un parc de DSI classique, il y aura forcément un équipement touché ». Logique quand on sait que des acteurs majeurs comme VMware, Cisco, Juniper ou encore Oracle ont publié des bulletins de sécurité confirmant que certains de leurs produits étaient affectés. En la matière, une production informatique n'a d'autres solutions que de suivre les alertes de sécurité publiées par ses fournisseurs et d'appliquer les patches qu'ils proposent. Sans oublier de contacter ceux qui ne proposeraient rien !

« La problématique d'applications des patches est aujourd'hui bien gérée par les entreprises », assure Marc Cierpisz. Mais, du fait du nombre d'éléments concernés, les entreprises piloteront probablement ce chantier par les risques, en démarrant par les infrastructures les plus critiques (ce qu'elles ont commencé à  faire avec les serveurs Web HTTPS). « Car l'installation de toutes ces mises à  jour va soulever des questions en matière de tests et de validation », souligne le responsable de Devoteam.

Pour Arnaud Soullié, s'il faut patcher au plus vite les éléments les plus critiques, « la question des librairies embarquées dans des équipements tiers reste devant nous. On risque de retrouver très longtemps des failles de ce type lors de nos audits, d'autant que ces équipements ne sont pas intégrés dans les cycles classiques de mises à  jour de sécurité ». Et de citer en exemples des modules permettant l'administration à  distance de serveurs (comme les interfaces iLO de HP sur lesquelles les tests de vulnérabilité Heartbleed entraînent une indisponibilité), mais aussi des équipements spécialisés M2M ou des webcam sur IP (c'est par exemple le cas de certaines caméras grand public D-Link touchées par Heartbleed).

« Pronostiquer le temps que prendra la remédiation totale est très difficile. La remise à  niveau de OpenSSL est très rapide. Mais il faut compter avec les effets de bord, liés aux certificats qu'il faut potentiellement réémettre, aux autres protocoles qui exploitent OpenSLL (comme POP, IMAP, SMTP ou VPN SSL). Le bogue impacte beaucoup d'éléments. Tout dépendra de la réaction des acteurs du marché. Mais, au global, il faudra sûrement quelques mois », pronostique Marc Cierpisz.

Quelques mois et le respect d'un ordre très strict d'actions, faute de quoi les premiers efforts seront potentiellement vains, rappelle Renaud Bidou. L'ordre de mises en place des contre-mesures est en effet très important. Il faut commencer par patcher en urgence tous les éléments concernés. A commencer par les serveurs Web et les VPN. Puis théoriquement renouveler les clefs de chiffrement, en faisant réémettre les certificats par une autorité de certification. Enfin, demander aux utilisateurs de changer leurs mots de passe sur les services touchés par Heartbleed. Un processus qui donne la mesure des efforts qui restent à  accomplir.

3) Changer les certificats. ou pas ?

La question du renouvellement des certificats donne précisément lieu à  des différences d'interprétation. Si, pour certains, comme Renaud Bidou, cette réémission semble incontournable, d'autres pensent qu'il faut l'étudier au cas par cas. « Les découvreurs de Heartbleed ont dans un premier temps expliqué que les certificats n'étaient pas concernés par la faille. Mais, sur un environnement de test, deux assaillants sont parvenus à  reconstituer la clef privée du serveur. Par mesure de précaution, il faut donc renouveler le certificat et régénérer une nouvelle clef privée. Ceci peut s'avérer complexe et coûteux si l'entreprise fait appel à  un prestataire externe, même si certains d'entre eux ont déjà  annoncé offrir de nouveaux certificats ou accorder des promotions à  leurs clients », assure Arnaud Soullie, de Solucom. Et l'auditeur de préciser : « Si cette étape est nécessaire, elle n'est pas suffisante. En effet, tous les équipements ne vérifient pas si tel ou tel certificat a été révoqué ou pas. C'est par exemple le cas du navigateur Chrome dans sa configuration par défaut. Le risque existe donc que des attaques perdurent même une fois les certificats renouvelés. »

« Il n'est pas encore sûr qu'il faille réémettre tous les certificats. La faille Heartbleed rend possible la lecture de la clef privée d'un serveur, mais c'est loin d'être systématique. La décision devra être prise en fonction des informations qui émergeront sur les attaques découlant de Heartbleed. Ce sont ces éléments qui permettront d'établir une politique claire en la matière », tempère pour sa part Marc Cierpisz. Par ailleurs, signalons que certaines infrastructures de sécurité permettent de protéger les clefs privées de chiffrement, même quand le serveur Web est affecté par Heartbleed. C'est le cas d'entreprises utilisant des HSM (des matériels dédiés produits notamment par Thales ou Bull) pour le chiffrement, signale Renaud Bidou. La plupart des banques ont recours à  ces matériels dédiés.

4) Redoubler de vigilance

Révélée le 7 avril, la faille est aujourd'hui comblée. Mais ce patch n'est pas forcément déployé partout et, surtout, de nombreux autres logiciels et matériels embarquant OpenSSL n'ont pas encore été mis à  jour. Parmi les plus réactifs, VMware promet de livrer l'ensemble de ses patches avant la fin du week-end de Pà¢ques. Des délais qui surprennent un peu Renaud Bidou, de DenyAll : « réaliser un patch pour nos produits nous a demandé deux heures : on a simplement changé de version de librairie. C'est donc très simple à  condition que les éditeurs soient réactifs ».

Il n'en reste pas moins pas moins qu'une fenêtre de vulnérabilité s'ouvre, une période particulièrement dangereuse pour les entreprises. D'autant que les codes permettant d'exploiter la faille sont eux librement disponibles sur le Web (par exemple sur Metasploit). Remarquons qu'au Canada, c'est un jeune homme de 19 ans qui est ainsi soupçonné d'avoir piraté le fisc local. Il a été arrêté dans le courant de la semaine. « Une fenêtre s'est ouverte pour des personnes malveillantes. Des pirates opportunistes vont aussi vouloir s'amuser et tester leurs capacités, assure Marc Cierpisz. D'o๠la décision de certains de ne pas communiquer sur leur exposition à  Heartbleed. Mais cette politique peut être à  double tranchant. » Et de remarquer le grand silence des organisations françaises sur le sujet : « on est dans le déni complet », raille-t-il.

« Aujourd'hui que la faille est connue, on peut toutefois détecter une attaque l'exploitant, rassure Renaud Bidou. Tous les accès aux données sensibles sur des serveurs encore vulnérables doivent être surveillés ». L'auditeur Arnaud Soullié précise les stratégies à  privilégier : « Comme l'ont montré des tests sur un serveur vulnérable, une exploitation de Heartbleed afin de récupérer la clef privée d'un serveur se traduit par des centaines de milliers ou des millions de requêtes émanant de quelques adresses IP. Mais la récupération de couples login / mots de passe peut, elle, se faire via quelques requêtes seulement. La détection doit donc plutôt se focaliser sur le volume de données échangées que sur le nombre de requêtes, car les requêtes pour exploiter la faille n'apparaissent pas dans les logs. Signalons également que certains fournisseurs de sondes de détection d'intrusion (IPS ou IDS) fournissent désormais des signatures permettant d'identifier les attaques s'appuyant sur la vulnérabilité. »

5) Tirer les leçons de Heartbleed

Si la saga Heartbleed est loin de se refermer, ses premiers développements sont déjà  riches d'enseignements. Sur certaines faiblesses du développement open source d'abord. « On prend ainsi conscience qu'une large part du chiffrement dans le monde dépend de quelques développeurs à  temps partiel, remarque Arnaud Bidou. Le code incriminé a été validé et enregistré le 31 décembre 2011. à  23 heures ! Et les équipes de OpenSSL se sont affranchies des vérifications de conditions d'allocation mémoire (la source du bogue, NDLR). La fondation OpenSSL a expliqué avoir besoin de 6 personnes à  plein temps pour travailler plus sereinement. Aujourd'hui, leur équipe est bien plus restreinte. Il serait peut-être temps de se pencher sur le financement d'une des principales infrastructures de sécurité du Web ».

Le dévoilement de la faille est lui aussi riche d'enseignement. Alors que Google - premier à  avoir isolé la faille (à  moins que des services secrets comme la NSA ne l'ait devancé.) - travaillait dans l'ombre et attendait que le patch soit largement déployé avant de rendre publique la vulnérabilité, Codenomicon, société spécialisée dans l'analyse de code, a redécouvert cette faiblesse et n'a pas hésité à  s'en servir pour se faire de la pub. « Codenomicon a littéralement marketé cette faille, avec un nom de domaine et un logo dédiés », s'énerve Renaud Bidou.

Le directeur technique de DenyAll remarque enfin le rôle que joue la multiplication des sécurités en cas de faille majeure, comme dans le cas présent. « Heartbleed montre la valeur de la sécurité en profondeur. Prenons l'exemple des banques, qui, pour la plupart, ont mis en place des mesures comme des mots de passe ou codes éphémères envoyés par SMS pour accéder aux opérations les plus sensibles comme les virements vers des comptes externes. » Des mesures qui permettent de limiter l'impact d'une vulnérabilité centrale dans les infrastructures Web. Mais qui ne suffisent pas à  ignorer le problème.

En complément :

Heartbleed : 2 sites Web sur 3 touchés par la faille OpenSSL ?

La faille Heartbleed fait ses premières victimes, dont le fisc canadien

Heartbleed : la faille qui met OpenSSL, et la NSA, sur la sellette

Heartbleed : VMware touché, Hyper-V épargné

Faille Heartbleed : le patch d'Akamai était vérolé

Réseau : les matériels Cisco et Juniper touchés par la faille Heartbleed