Heartbleed OpenSSL : Explication et Exploit
HeartBleed apparue en 2014 est l’une des failles les plus dangereuses de nos jours. Ce post va vous permettre de tester la vulnérabilité de votre serveur grâce à un outil mis en place par HTTPCS.
Sommaire:
1.HeartBleed
1.2. Est-elle une faille aussi dangereuse que ça ?
1.2.1. L’exploit du bug est-il détectable par les IDS ?
1.2.2. Origine
1.2.3. Qui l’a découverte ?
1.2.4. Pourquoi ce nom bizarre ?
1.3. Identification de la faille
1.3.1. Est-ce la fin précoce de SSL ?
1.3.2. Quelles sont les versions OpenSSL affectées ?
1.4. Comment savoir que mon serveur en est vulnérable ?
1.4.1. Y a -t-il un outil pour tester si mon serveur est vulnérable ?
1.4.2. Je n’utilise ni Apache ni Nginx: suis-je en sécurité ?
1.5. Mon serveur est affecté: que devrais-je faire ?
2. Détails techniques
2.1. Introduction aux protocoles SSL & TLS
2.1.1. Fonctionnement du protocole SSL/TLS
2.2. L’extension HeartBeat
2.2.1. Le format de Heartbeat Hello
2.2.2. Le protocole Heartbeat
2.2.3. Les messages Heartbeat
3. Preuve de concept
3.1. Organisation du code
3.2 Résultats obtenus
3.2.1 Remarque sur la performance
3.3. Conclusion
Par son développement constant, Internet est non seulement la convoitise des utilisateurs malveillants de tout bord mais, il est également devenu la victime de son propre progrès, comme nous allons le voir avec Heartbleed OpenSSL.
Dangereuse, incroyable, très importante … tels sont les qualificatifs donnés par les experts de la sécurité informatique à la faille HeartBleed qui vient d’être publiée ce 07 avril 2014. [1]
Au delà des soubresauts médiatiques, nous tentons de clarifier les tenants et les aboutissants de cette faille. Toutefois, nous allons également répondre aux questions que les clients de notre produit HTTPCS pourraient se poser sans trouver nécessairement de réponse dédiée à ce sujet. Ce sera donc le contenu de cette première partie. Ensuite, nous passerons aux détails techniques qui entourent ce bug. Pour finir, nous terminerons avec une mise en place d’une preuve de concept qui sensibilisera nos clients HTTPCS sur la nécessité d’installer le patch remédiant à cette faille.
1.2. Est-ce une faille aussi dangereuse que ça ?
Théoriquement, on pourrait récupérer tout de la mémoire du serveur qui en est vulnérable, y compris des données aussi sensibles que les certificats X.509, et ce sans avoir recours à des privilèges particuliers.[2]
1.2.1. L’exploit du bug est-il détectable par les IDS ?
Non. D’ailleurs c’est l’une des raisons pour laquelle HeartBleed est qualifiée comme l’une des plus dangereuses failles par les experts en sécurité.
1.2.2. Origine
La faille HeartBleed fut introduite par Stephen Henson juste une heure avant le réveillon de la Saint-Sylvestre de l’an 2011. Pour être plus précis, c’était Robin Seggelmann, alors étudiant à l’université de Duisburg-Essen qui, a conçu l’extension HeartBeat pour OpenSSL (déjà spécifiée dans le standard SSL2.0). Celui-ci l’a suggéré au développeur en chef du projet OpenSSL Stephen Henson qui n’a pas détecté la faille dans le code qu’il venait de recevoir. Voilà donc pour la petite histoire.
1.2.3. Qui l’a découverte ?
La faille est découverte le 07 avril, 2014 par Neel Mehta qui travaillait pour le groupe Google Sécurity. Celui-ci a recommandé la rectification du bug ainsi que la mise à jour de la version OpenSSl en cours [1]. Deux de ses collègues ont procédé à la correction.
1.2.4. Pourquoi ce nom bizarre ?
C’est la question des curieux. Afin de comprendre pourquoi le coeur (heart) d’un serveur saigne (bleed), il suffit de patienter un peu jusqu’à ce que nous arriverons au Chapitre 2 qui suit.
1.3. Identification de la faille d’Heartbleed OpenSSL
Si vous êtes développeur, cette section est faite pour vous. Sur le site de Github vous pouvez chercher le dépôt du code source du projet OpenSSL et vous pointer sur ce fichier:
- openssl -> openssl -> blob -> master -> ssl -> t1_lib.c
Tout comme vous pouvez cliquer directement sur ce lien, où vous pouvez voir où se situe la faille en vous positionnant sur la ligne 1480 où vous pouvez lire ce bout de code:
- buffer = OPENSSL_malloc(1 + 2 + payload + padding);
C’est cette ligne qui est à l’origine de la faille car elle permet de lire des zones mémoires aléatoires du serveur du moment où aucun contrôle n’a été effectué avant d’allouer la zone mémoire indiquée par la variable buffer.
1.3.1. Est-ce la fin précoce de SSL ?
Non. Il faut comprendre que SSL n’est qu’un protocole. Ce n’est pas ce standard qui pose problème mais ses (car il en existe plusieurs) implémentations . Plus précisément, seule OpenSSL, qui en est une variante opensource se trouve affectée par notre fameuse faille HeartBleed.
1.3.2. Quelles sont les versions OpenSSL affectées ?
Sont affectées les versions allant de :
- 1.0.1 (14 mars 2012) à 1.0.2 (24 février 2014 (beta))
Evidemment, il faut compter la liste de versions existantes entre les deux que nous venons de mentionner. Autrement dit, il faut ajouter à cela toutes les versions OpenSSL 1.0.1ω , où ω ∈ {a, b, c, d, e, f}.
1.4. Comment savoir que mon serveur en est vulnérable ?
Si vous utilisez, comme la majorité, les serveurs web Apache ou Nginx, forte est la probabilité que votre machine en soit atteinte. En effet, une étude a montré que 70% des machines font appels à ces deux serveurs web qui utilisent OpenSSL: [3]
Selon une étude récente, 17.5% des sites faisant appel au protocole SSL ont configuré l’extension HeartBeat avant la découverte de la faille HeartBleed [4]. Nous le rappelons quand même, si votre machine utilise le protocole SSL il n’y a aucune raison de vous inquiéter si OpenSSL n’y est pas déployée dans votre réseau. Par exemple le serveur IIS (Internet Information Services) de MicroSoft utilise sa propre implémentation du protocole SSL qui est SChannel, de ce fait celui-ci n’intègre pas l’extension HeartBeat de la même façon qu’OpenSSL le fait.
1.4.1. Y a -t-il un outil pour tester si mon serveur est vulnérable ?
Des logiciels et des applications en ligne sont déjà mis en place pour tester la vulnérabilité ou non de votre serveur à la faille HeartBleed. HTTPCS a développé son propre outils simple d’utilisation et efficace. Nous vous invitons à l’utiliser.
1.4.2. Je n’utilise ni Apache ni Nginx : suis-je en sécurité ?
Pas nécessairement. Il faut bien vérifier l’architecture de votre réseaux. Prenons un bon exemple pour clarifier la situation : l’organisme qui héberge le fameux site StackOverFlow possède un réseaux où toutes les applications .NET sont hébergées sur des serveurs IIS [5] alors que la répartition des charges est assurée par HAProxy et la terminaison SSL est léguée pour Nginx. En résumé, comme nous l’avons dit, il faut bien vérifier l’architecture réseau que vous avez déployé même si au premier abord il vous semble que vous n’utilisez pas Apache ou Nginx.
1.5. Mon serveur est affecté : que devrais-je faire ?
Il vous faut logiquement mettre à jour la version d’OpenSSL que vous utilisez à la version 1.0.1g. Sur une machine Linux vous pouvez exécuter cette commande:
- sudo apt -get install openssl -server
Au cas où vous ne souhaitez pas passer à une nouvelle version pour une raison ou une autre, vous pouvez simplement corriger le bug vous-même et compiler votre outil OpenSSL.
Il ne faut surtout pas oublier de modifier vos mots de passe.
2.1. Introduction aux protocoles SSL & TLS
Le protocole SSL a été introduit en 1994 par la société NetScape sous sa version 2.0 afin de sécuriser les opérations de payement en ligne [6]. Vu les failles de sécurité détectées, la version SSL3.0 a vite été mise en place. Au cours de la même année (1999), le protocole TLS a vu le jour et a été implanté sous sa première version TLS1.0. Ce dernier n’est autre qu’une mise à jour de la version SSL3.0 elle-même.
2.1.1. Fonctionnement du protocole SSL/TLS
Le protocole SSL/TLS assure le cryptage, l’authentification ainsi que l’intégrité des données échangées.
La procédure SSL/TLS-handshake est précédée par TCP-handshake qui se trouve suivie d’un ensemble d’opérations plus ou moins compliquées, certains éléments importants y sont négociés: négociation des types de chiffrement, authentification, échange de clés et établissement d’une session. Vu que la réalisation de ce procédé est lourde, au lieu de l’effectuer pour chaque nouvelle requête, une technique a été mise en place pour les protocoles HTTP et TCP; elle est appelée keep-alive. Celle-ci permet le maintien de la session et, d’effectuer une chaîne de requête évitant ainsi la création d’un canal de communication avec réinitialisation de la connexion pour chaque requête. Le protocole SSL/TLS a mis en place une technique similaire mais plus performante, et ce grâce à l’extension HeartBeat.
2.2. L’extention Heartbleed OpenSSL:
HeartBeat est une extension ajoutée au protocole SSL/TLS afin de maintenir une session de communication entre deux machines en vie pour la durée du temps requis. Elle sert également à détecter si un destinataire n’est pas en panne avant que l’émetteur ne lui envoie des données.
2.2.1. Le format de Heartbeat Hello
Une machine peut déclarer qu’elle supporte l’extension HeartBeat et, si elle souhaite ou non recevoir des réponses à ses requêtes du type de cette extension grâce à cette structure de données:
enum {
peer_allowed_to_send (1),
peer_not_allowed_to_send (2),
(255)
} HeartbeatMode;struct {
HeartbeatMode mode;
} HeartbeatExtension;
Le champ peer_allowed_to_send est mis sur ON si la machine souhaite recevoir des réponses quant à ses requêtes HeartBeat. Ce qui devra ensuite être souligné par le mode en mettant HeartBeatMode à 1 ou 2, selon le cas.
2.2.2. Le protocole Heartbeat
Le protocole HeartBeat est défini suivant ces 2 messages:
enum {
heartbeat_request(1),
heartbeat_response (2),
(255)
} HeartbeatMessageType
La longueur totale du message HeartbeatMessage ne doit pas dépasser 64 ko, c’est à dire la taille de max_fragment_length [7]. Le contenu plus en détails de ce message est listé dans la sous-section suivante.
2.2.3. Les messages HeartBeat :
struct {
HeartbeatMessageType type;
uint16 payload_length;
opaque payload[HeartbeatMessage.payload_length];
opaque padding[padding_length];
} HeartbeatMessage;
Où:
Type: heartbeat_request/heartbeat_response, il est toujours de longueur d’un (1) octet.
Payload: contenu arbitraire, il est toujours de longueur 2 octets.
Padding: contenu arbitraire toujours ignoré par le récepteur.
padding_length=TLSPlaintext.length – payload_length – 3 pour TLS
et
DTLSPlaintext.length- payload_length – 3 pour DTLS.
padding_length>=16. [8]
3.1. Organisation du code
3.2. Résultats obtenus
Après l’exécution du programme:
… nous avons obtenu les résultats suivants ( en voici un échantillon):
3.2.1. Remarque sur la performance
Afin de tirer une meilleure performance du code, nous pouvons l’automatiser de façon à pouvoir l’exécuter pendant plusieurs heures, et balayer ainsi une large zone mémoire du serveur ciblé et augmenter la chance de récupérer des données plus ou moins sensibles. Pour des raisons d’éthique et juridiques, nous nous sommes contentés d’une seule attaque.
3.3. Conclusion d’Heartbleed OpenSSL
Il est remarquable que cette faille qui date depuis la fin de l’année 2011, n’a pu être communiquée qu’en avril 2014, et ce malgré son envergure et sa dangerosité. Dans un sens, c’est encore plus décevant pour un logiciel opensource supposé être plus fiable qu’un logiciel propriétaire vu la communauté de développeurs dont il est censé bénéficier. Comment se fait-il que nous en sommes arrivés là ?
Justement, une explication partielle réside dans le fait que le développement d’OpenSSL est pris en charge par deux développeurs uniquement, pour ne pas dire un puisque seul Stephan Henson y travaille à plein temps. La révision du code ne peut pas être efficace dans ces conditions.
Nous disons que l’explication est partielle car vu la nature libre de ce logiciel, mais aussi son domaine d’application, il est censé être suivi de près par les développeurs en sécurité, sauf que ce n’est pas le cas. Plus que jamais, cette faille montre la nécessité de ne faire confiance qu’aux logiciels opensource ayant bénéficiés d’une large communauté d’informaticiens ; de même, l’organisme faisant usage de tels types de logiciels doit en réviser le code (ce qui est un luxe que ne possède que peu d’entreprises).
Ceux qui ont été victimes de cette faille durant ces 2 dernières années n’ont, pourtant, fait que suivre les bonnes pratiques en vigueur, à savoir la mise à jour de leur version précédente à 1.0.1. Une question se pose alors: si vous mettez à jour votre version d’OpenSSL: êtes-vous à l’abri d’un drâme ? Si oui, jusqu’à quand ?
Bibliographie
[1]: OpenSSL Security Advisory Neel MEHTA, https://www.openssl.org/news/secadv/20140407.txt, April 7th , 2014
[2]: The Heartbleed Bug, Codenomicon, http://heartbleed.com/ , April 7th , 2014
[3]: April 2014 Web Server Survey, NetCraft, http://news.netcraft.com/archives/2014/04/02/april-2014-web-server-survey.html , April , 2014
[4]: Half a million widely trusted websites vulnerable to Heartbleed bug, NetCraft, http://news.netcraft.com/archives/2014/04/08/half-a-million-widely-trusted-websites-vulnerable-to-heartbleed-bug.html , April, 2014
[5]: Stackoverflow.com: the road to SSL, Nick Craver, http://nickcraver.com/blog/2013/04/23/stackoverflow-com-the-road-to-ssl/, April 23rd , 2013
[6]: History of SSL, IBM, http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzain%2Frzainhistory.htm
[7]: RFC 6066: Transport Layer Security (TLS) Extensions: Extension Definitions IETF, http://tools.ietf.org/html/rfc6066, Page 8, January, 2011
[8]: RFC 6520: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension IETF, http://tools.ietf.org/html/rfc6520, Page 5, February, 2012
[9]: RFC 6101: The Secure Sockets Layer (SSL) Protocol Version 3.0, http://tools.ietf.org/html/rfc6101, August 2011
