Vulnérabilité Heartbleed : Ce qu'il faut savoir

Le 7 avril 2014, une grave vulnérabilité appelée "Heartbleed" a été annoncée. Heartbleed est une vulnérabilité dans la série OpenSSL 1.0.1 software qui est décrite dans l'annonce NIST CVE-2014-0160. En bref, cette vulnérabilité permet aux pirates d'accéder à des parties de la mémoire d'un système vulnérable, ce qui peut entraîner l'exposition de mots de passe, de données sensibles et de clés privées de certificats sur les systèmes concernés. Heartbleed y parvient en exploitant une faiblesse dans "TLS Heartbeat Extension", exposant ainsi la mémoire du serveur. Pire encore, cette attaque par battement de cœur peut être répétée à l'insu de la victime, et chaque itération révèle à l'attaquant un nouvel instantané de 64k de la mémoire. Cette vulnérabilité très grave expose les données les plus sensibles des systèmes affectés.

The good news: the vulnerability has a patch. However, the widespread adoption of the OpenSSL 1.0.1 series software, coupled with the two years that this vulnerability has existed, means that the risks attributable to Heartbleed are enormous. Current estimates predict that over 500,000 systems may be vulnerable. Specifically, the Heartbleed vulnerability affects those systems that use OpenSSL 1.0.1 (a-f). Unfortunately, since this software is so widely implemented, many popular OS platforms are affected and thus vulnerable. I would suggest visiting the CERT Web Site for a more list of affected platforms. It is worth mentioning that this is a developing story, and as such, the list of affected platforms is likely to change.

Il est important de comprendre que cette vulnérabilité ne se limite pas aux serveurs web. Compte tenu de la popularité d'OpenSSL, de la tendance actuelle à l'"Internet des objets" et du fait que de nombreux appareils modernes sont désormais dotés d'interfaces de configuration web protégées par SSL , le nombre d'appareils potentiellement vulnérables est immense. Tout, des routeurs de réseau aux systèmes de contrôle industriel, peut être vulnérable.

Déterminer l'étendue de votre exposition à cette vulnérabilité peut être un défi non trivial pour une grande organisation. La détermination de la vulnérabilité comprendra sans aucun doute un examen des plates-formes de l'entreprise qui sont touchées et un examen des versions d'OpenSSL utilisées sur ces systèmes. En outre, si vous utilisez la dernière version d'OpenSSL, il existe des méthodes de script qui peuvent être utilisées pour interroger interactivement un système afin de déterminer sa vulnérabilité, comme la ligne command ci-dessous :

echo -e "quit\n" | openssl s_client -connect 192.168.1.1:443 -tlsextdebug 2>&1 | grep 'server extension "heartbeat" (id=15)' || echo safe

Enfin, il existe des sites en ligne qui, à partir d'un hôte et d'un port DNS , peuvent vérifier la présence de la vulnérabilité Heartbleed.

Si l'on détermine que son site ou son serveur est vulnérable, que faire ? Quel est le meilleur plan d'action ?

If a server is determined to be vulnerable, then to be completely safe, one must assume that all sensitive data that may have ever been in the memory of that system has been compromised. It’s important to remember that this vulnerability has been a part of the OpenSSL code base for over 2 years. And given the untraceable nature of this exposure, there is no sure way to determine the extent of any attack, therefore all data on affected systems should be suspect.

• Les mots de passe de tous les comptes concernés doivent être réinitialisés.
• Tous les certificats de systèmes vulnérables dont les clés privées ne sont pas protégées par un HSM ou un système cryptographique ( hardware ) doivent être révoqués et remplacés par des certificats contenant de nouvelles clés.
• Toute donnée sensible devra faire l'objet d'une évaluation quant à sa compromission.

It’s also important to understand that this is not a compromise of PKI, SSL, TLS or X.509 certificates. Heartbleed is more of an exploit of the systems that use PKI. And as such, any new certificates that are required to re-key vulnerable systems, would be subject to the original certificate requirements that were used to create the original certificates. That said, CSS always suggests that during any certificate re-keying or re-enrollment event, an analysis of the key size, hash algorithm, and chaining requirements be performed as a part the overall certificate enrollment process.Another Heartbleed read.Contact us.