Voilà maintenant une semaine a été révélée la faille Heartbleed touchant certaines versions récentes de la bibliothèque OpenSSL. OpenSSL est un Logiciel Libre notamment utilisé pour les protocoles sécurisés HTTPS ou IMAPS. Cette faille a été surmédiatisée et plusieurs clients nous ont interrogé à ce sujet. Même si cela date un peu, il s’avère plus pratique et plus transparent de mettre nos réponses sur ce blog.
Qu’est-ce que la faille Heartbleed ?
Il s’agit d’une faille de sécurité touchant OpenSSL permettant d’accéder à une partie (64 Ko) quasi-aléatoire de la mémoire d’une application via le protocole SSL/TLS. Cela concerne évidemment les services utilisant SSL/TLS accessibles publiquement comme HTTPS, IMAPS, POPS, SMTPS ou encore SMTP over TLS. Cela peut aussi concerner les logiciels client faisant des requêtes via SSL/TLS sur des serveurs malicieux.
La partie de la mémoire dévoilée étant plus ou moins aléatoire, on peut considérer que de multiples requêtes permettent de révéler l’ensemble de la mémoire de l’application concernée. Cela concerne évidemment la clé privée SSL utilisée mais les autres données système et applicative chargée en mémoire par l’application (mot de passe d’une base de données, contenu de /etc/passwd, contenu d’une base de données, etc.). Certains experts affirment même que l’ensemble de la mémoire d’une machine impactée pourrait être accessible.
Mon serveur infogéré par Evolix a-t-il été concerné ?
Nous gérons des serveurs avec le système Debian GNU/Linux. Les serveurs utilisant Squeeze (Debian 6) ne sont pas impactés. Les serveurs utilisant Wheezy (Debian 7) sont directement concernés si ils ont un service HTTPS ou POPS/IMAPS ou SMTP publiquement accessibles, et indirectement si ils peuvent faire de nombreuses requêtes SSL/TLS vers des serveurs non sûrs situés à l’extérieur.
Mon serveur infogéré par Evolix a été concerné, que dois-je faire ?
La faille a été révélée lundi 7 avril 2014 vers 21h. Nous nous sommes penchés sur cette faille à partir de 00h15 (bug signalé sur notre IRC privé, merci Arnaud) et nous avons mis à jour tous les serveurs directement concernés dans les heures qui ont suivi et le lendemain. Votre serveur n’est donc plus vulnérable. Mais il a pu l’être pendant au moins quelques heures. Une analyse du trafic réseau et des logs suspects (connexions STARTTLS via SMTP, requêtes HTTPS sans contenu, etc.) nous laissent penser qu’il n’y a pas eu d’attaque sur ce laps de temps. Cela étant dit, par principe de précaution et car dans tous les cas cela doit être fait régulièrement, nous conseillons tout de même de renouveler toutes les informations secrètes sur les serveurs directement impactés (mots de passe, clés privées, etc.). Vous devez également relancer toutes les applications qui utilisent libssl (démons en Python ou Ruby, etc.).
Et sur mon poste de travail, que dois-je faire ?
Vous devez mettre-à-jour vos postes de travail immédiatement. Avant de vous connecter à un site en HTTPS, vous pouvez vérifier qu’il n’est plus vulnérable. Il est également conseillé de renouveler vos mots de passe sur les différents services en ligne (notamment Google, Github, Facebook, Twitter, Amazon…) : de toutes façons vous devez le faire régulièrement, c’est donc une bonne occasion de le faire !
Des conclusions à tirer de cette affaire ?
Il n’y a rien de vraiment nouveau, si ce n’est qu’il est désormais difficile d’ignorer que :
– l’application régulière des mises-à-jour de sécurité est essentielle, vous ne pouvez pas vous contenter d’installer un serveur et ne pas vous en occuper, surtout si il est accessible publiquement ;
– vous devez exposer publiquement le moins de choses possibles : cela passe par un firewall qui va restreindre un maximum de services par adresse IP, et par la désactivation de tous les fonctionnalités inutiles (avez-vous vraiment besoin d’Apache/SSL si votre site web ne tourne pas en HTTPS ? l’activation de STARTTLS sur votre Postfix est-elle vraiment nécessaire ?) ;
– toutes les informations secrètes doivent être changés régulièrement (clés privés, mots de passe, certificats, etc.) et changeables rapidement en cas de besoin… l’utilisation d’un gestionnaire de mot de passe étant indispensable.